Building iteratively for the win!

Posted Apr 29, 2008 // 1 comments

Ask any Agile software professional how they approach development, and they’ll likely tell you they

“build iteratively.” Building iteratively isn’t earth-shaking unless you’re familiar with the way software used to be built. So let’s take a walk down memory lane, and explore the ancient ways of the Waterfall-ists.

*The Big Bang Effect

• In the old days,

software was built like buildings. People got in a room, came to a conclusion about the type of software they wanted, then they proceeded to arduously write everything they needed down on paper. These were called Software Requirements Specifications (SRS).

Once all the stakeholders were in agreement that the SRS was

perfect (and sometimes this could take years for big systems), this document would be “frozen” and system architecture would begin. Again, more documentation would be drawn up, describing the proposed system architecture against the requirements. Engineers would argue about the suitability of their architecture against the requirements, whether it would perform adequately, was it overkill or not enough, etc.

After months of haggling, this document would be declared perfect and frozen, and the “real” work of system development would begin. Sometimes prototypes were defined, and sometimes screen mock-ups were created, but other times stakeholders simply waited with anticipation for their software.

Finally, the “Big Bang” would happen. The software was completed using the system architecture developed and using the requirements that were just perfectly described. The stakeholders loved the software, there were very few bugs, the budget estimate matched the actual cost perfectly, and every requirement was fulfilled. Everyone was happy.

*Reality Bites *

Unfortunately, this outcome was usually a fantasy. In the time it took to develop the software, the stakeholder changed their minds. The business environment shifted underneath the project, forcing requirements changes. Or, it turned out that the stakeholders weren’t as single-minded as they once appeared about how the system would act. Things that people thought were features turned out to be bugs. Finally, it turned out that the requirements and architecture processes just took too dang long, and the project went over budget. Unfortunately, there was no time to adjust, because the software was unveiled so late in the game.

*Agilists Unite *

This scenario went on for years, until a wise person finally said, “Why do we need to wait so long to figure out whether we’re satisfying customer needs?” Then another wise person said, “Maybe we should build our software more often – maybe every week or two – and then show it to the customer, and let them test it!” “Great idea!” someone else shouted – “and let’s call it Iterative Development!”.

And it’s as simple as that. Using modern development tools and techniques (like Object-Oriented) that more easily allow shifts in direction, Agile methodologies all prioritize real working software over documentation that inevitably comes to mean less and and less as the projects moves forward. Each “build” of working software is called an iteration, and project managers use iterations to plan and organize their project’s features, and to gather feedback from customers that is invaluable to the success of the effort.

So now you know – build iteratively for the win!