Increase your global team's productivity with working software

Requirements and software development have a strange and sometimes strained relationship. Good requirements are a prerequisite to ensuring you (the buyer) get what you need. But written in a prose style, they rarely offer a complete picture for the developer. Thus, over the years, software developers have made many attempts at improving this situation. One consistent mechanism they have used is actually showing you what you will get—first by writing and sharing prototypes and eventually evolving to developing and demonstrating working software.

This evolution has been an important enabler to the world of distributed development. As teams are dispersed, they need stronger means of communicating, and nothing speaks louder than showing the actual product in action. You now have a much earlier opportunity to shape the software as it is developed. This, in turn, enables global development teams to better deliver what you want.

It started with prototyping
The concept of demonstrating a prototype is nothing new—it has been prevalent for a long time in software development. Fred Brooks wrote about it in his book, The Mythical Man Month (Brooks, 1975). His description of ”rapid prototyping” included simulations of the product that were not bound by hardware constraints and demonstrated mostly “happy path” scenarios. Another main point Brooks made: Be prepared to throw away one of the versions of the software that you develop.

By the 1980s, 60 percent of companies were making use of prototyping—twice as many as in the 1970s (Bardgrave & Wilson, 1994). Much of the focus was on user interfaces. However, the tools available to develop prototypes did not make it easy to integrate these user interfaces into the final product. The software development industry then dedicated a lot of work toward improving integrated development environments (IDEs) to allow faster and easier user interface development. Thanks to those advancements, today we can build the user interface and then develop the supporting business code without throwing away the original work.

Then came Agile Development
Enter the Agile Development movement. Its proliferation was in part made possible by a new breed of tools and frameworks that empowered developers to plan for short development cycles and demonstrate not only the user interface, but even a working version of the software. The Scrum software process codifies this standard by requiring teams to demonstrate working software to their customers at the end of every month of development (Shwaber & Beedle, 2001).

While these tools and frameworks don’t completely eliminate the need for up-front analysis and design, they form a common platform to address infrastructure-level work, such as logging, error handling and “objectification” of database access. This allows developers to focus on business features of the software they are building. So it’s not necessary to “throw one away.” Instead, as long as the code base resides on a stable architectural platform, designs are refactored and new requirements are iteratively and incrementally added to an emerging code base.

Improving communication with working software
These techniques have become the industry standard to use whenever possible, regardless of the formal process in place. In fact, several Coherent Solutions clients have used them successfully. By using desktop-sharing technology, globally dispersed software teams can now offer their internal customers a chance to review the software early, while it is being built. The customers may then guide the software in the right direction—dramatically increasing the chance that the right application will be delivered several months in the future. Thus, working software can actually keep a global development team on the same page and enable effective communication—a critical element for success.

As the current economic environment pushes companies to further reduce costs, more and more global development teams are likely to leverage working software to improve communication and ensure successful software delivery.

References

1. Bardgrave, B. C., & Wilson, R. L. (1994). An investigation of guidlines for selecting a prototyping strategy. Journal of Systems Management , 45 (4), 28-35.
2. Brooks, F. (1975). The Mythical Man Month. Addison-Wesly.
3. Shwaber, K., & Beedle, M. (2001). Agile Software Development with SCRUM. Prentice Hall.