Waterfall Model - Criticism

Criticism

Advocates of Agile software development argue the waterfall model is a bad idea in practice—believing it impossible for any non-trivial project to finish a phase of a software product's lifecycle perfectly before moving to the next phases and learning from them.

For example, clients may not know exactly what requirements they need before reviewing a working prototype and commenting on it. They may change their requirements constantly. Designers and programmers may have little control over this. If clients change their requirements after the design is finalized, the design must be modified to accommodate the new requirements. This effectively means invalidating a good deal of working hours, which means increased cost, especially if a large amount of the project's resources has already been invested in Big Design Up Front.

Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. In this case, it is better to revise the design than persist in a design based on faulty predictions, and that does not account for the newly discovered problems.

In Code Complete (a book that criticizes widespread use of the waterfall model), Steve McConnell refers to design as a "wicked problem"—a problem whose requirements and limitations cannot be entirely known before completion. The implication of this is that it is impossible to perfect one phase of software development, thus it is impossible if using the waterfall model to move on to the next phase.

David Parnas, in A Rational Design Process: How and Why to Fake It, writes:

“Many of the details only become known to us as we progress in the implementation. Some of the things that we learn invalidate our design and we must backtrack.”

Expanding the concept above, the project stakeholders (non-IT personnel) may not be fully aware of the capabilities of the technology being implemented. This can lead to what they "think is possible" defining expectations and requirements. This can lead to a design that does not use the full potential of what the new technology can deliver, or simply replicates the existing application or process with the new technology. This can cause substantial changes to the implementation requirements once the stakeholders become more aware of the functionality available from the new technology. An example is where an organization migrates from a paper-based process to an electronic process. While key deliverables of the paper process must be maintained, benefits of real-time data input validation, traceability, and automated decision point routing may not be anticipated at the early planning stages of the project.

The idea behind the waterfall model may be "measure twice; cut once," and those opposed to the waterfall model argue that this idea tends to fall apart when the problem constantly changes due to requirement modifications and new realizations about the problem itself. A potential solution is for an experienced developer to spend time up front on refactoring to consolidate the software, and to prepare it for a possible update, no matter if such is planned already. Another approach is to use a design targeting modularity with interfaces to increase the flexibility of the software with respect to the design.

Due to the types of criticisms discussed above, some organizations, such as the US Department of Defense, now have a preference against waterfall type methodologies, starting with MIL-STD-498 "clearly encouraging evolutionary acquisition and IID".

The current DoD Standard 5000.2, released in 2000, states a clear preference against waterfall: "There are two approaches, evolutionary and single step, to full capability. An evolutionary approach is preferred. … approach, the ultimate capability delivered to the user is divided into two or more blocks, with increasing increments of capability...software development shall follow an iterative spiral development process in which continually expanding software versions are based on learning from earlier development."