Recap

There is a somewhat widespread misconception that criticizing the waterfall method is akin to beating a dead horse, or one that never really lived. Contrary to popular belief, waterfall is alive and well, so to speak, and continuing to undermine projects today. The software development world is moving away from it much more slowly than we would like to believe.

In his project management book, Walker Royce points out that his father, Win Royce, intended for waterfall to be used much more iteratively than it came to be used. So clearly there is confusion even on this point.

Rather than focus on what's bad about waterfall, I think it's much more constructive to focus on what's right about iterative:

• Focus on architecture

• Learn early, and then produce more later

• Progressively and incrementally grow the system with each iteration

• Measure progress by working code, not documents

• Integrate, build, and test on each iteration

• Progressively reduce risk by attacking hard problems first

• Adjust the plan by carefully reviewing the results of the previous iteration

If you remain unconvinced about iterative development, the only thing I suggest is to find a manager who has done it both ways and have a chat with him. The rest of this book assumes you accept the iterative way of doing software development, and lots of other concepts I will discuss tie into it. For instance, I'll talk about "high trust" work environments, which are essential to the effective use of iterative development. Another related concept is a stable, underlying "software architecture," which allows iterative development technique to keep a complex project on course. The best way to express and communicate this architecture is through the use of a model. So I'll attack the subject of modeling in the next chapter.