I think the article gave an adequate portrayal of a waterfall methodolgy and accurately describe what proponents see as its advantages. I think, however, the article showed a misunderstanding of the criticisms of the waterfall approach. It is not so much a trade-off between the advantages of waterfall versus the advantages of other approaches as it is a fundamental questioning of whether the advantages of waterfall are actually realize.

First, I would disagree with the assertion that "every phase has a defined start and end point." While it is straight forward to track when effort was started and stopped for a particular phase, the level of completion of effort under the phase is highly subjective. Objective indications only begin to surface in the testing phase and become fully visible after deployment.

Second, I question the assertion that "it's much easier to catch and correct possible flaws at (an earlier) stage than at (a later) stage". It is extremely difficult to identify ommissions and how the system will affect workflow outside of actual usage. It is also no more difficult to enter new operation for a system in a code editor than in a word processor or a diagramming tool. The interactions and constraints are also much easier to analyze and evaluate in a working model than on paper.

Last, I challenge the assumption that the "customers don't really know what they want up-front". The users know how to do their jobs; in fact they are the experts. What is not being communicated is how the system will affect their abilities to do their jobs. The waterfall approach does not adequately communicate this.

The waterfall approach is based on near perfect execution of each phase, but does not provide a mechanism to measure the completeness of a phase. This sets up the classic cost versus quality conundrum. The cost of spending extra time and money on a phase is obvious, the benefit, however, can only be evaluated after completion of all phases. The constant pressure to do just a little bit more without a means to identify the resulting benefit leads to both slipping schedules and increased costs.

The true criticism of waterfall is that it fails to deliver on its advertised benefits. When waterfall was the only alternative to ad hoc chaos, its assumptions went unchallenged. Given the current state of software development, it is now time to review and validate the underlying assumptions of waterfall.