- If You Build It, They Will Come
- In the Beginning, There Was the Sandbox
- Why Should the Product Build Be Hard, Anyway?
- What About Iterative Development?
- Recap
This chapter is from the book
This chapter is from the book
This chapter is from the book
What About Iterative Development?
Iterative development sidesteps one of the great dangers of the waterfall approach: leaving system integration to the last minute. One of the reasons so many waterfall projects fail is that, very late in the game, developers are trying to assemble their product for the very first time. In addition to finding many bugs, mostly in the interfaces, they grapple with the normal logistical and organizational problems of putting together a build chain for the first time. Often, things that pass for bugs are nothing more than the artifacts of broken builds. But the organization is in such chaos at this point—running out of time, nothing working, people frazzled—that it is hard to separate the sugar from the salt. It is also a very bad time to be trying to solve political and process problems.
By contrast, iterative development requires that you construct your build chain to accomplish the deliverable for Iteration 1—a working program. So you begin to debug this process early in the project, not at the end. By the time you get to Iteration 3 or 4, the build process is actually starting to work pretty well. For the last iteration, the one that will deliver the final bits, the build should be working like a finely lubricated Swiss watch.
As with pretty much everything else in software development, there are a small number of ways to get this right and almost an infinite number of ways to get it wrong. If you view the build as a detail that will "just happen," then the odds are against you. Make sure you attack the build process as a conscious effort that is critical to your success, and devote the time, energy, and resources to it that it demands. To do any less is sheer folly.