Waterfall is a sequential software development methodology in which each phase — requirements, design, implementation, testing, deployment — must be completed before the next begins, the output of each phase flows downward to the next like water over a cliff, and the possibility of going back upstream is treated as a theoretical concern that a sufficiently detailed requirements document will prevent.
Waterfall works perfectly under the following conditions:
- You know all the requirements in advance
- The requirements will not change
- The design is correct on the first attempt
- The implementation matches the design
- The users want what you specified eighteen months ago
In practice, none of these conditions have been observed simultaneously in the wild. Waterfall persists anyway, because the alternative — admitting that you do not know what you are building until you start building it — is uncomfortable for organisations that have already committed to a budget, a timeline, and a Gantt chart.
“Waterfall is the belief that you can design a bridge, build a bridge, and test a bridge in strict sequence. Software is not a bridge. Software is a bridge that changes shape while you’re driving on it, built over a river that moves.”
— The Lizard, who has never needed a methodology
The Royce Misunderstanding
The most remarkable thing about waterfall is that the man credited with inventing it was arguing against it.
In 1970, Winston W. Royce published “Managing the Development of Large Software Systems,” a paper that described the sequential, phase-gated model of software development — requirements, design, code, test, deploy — as a recognisable industry practice. He then spent the rest of the paper explaining why this model was “risky and invites failure.” He proposed iterative cycles, feedback loops, and prototyping — concepts that would later be called, with great ceremony, “Agile.”
The industry read the diagram on page 2. The industry did not read the rest of the paper. The diagram showed water flowing downward through phases. It was clear, simple, and wrong. It was adopted as a methodology by organisations that preferred clear and simple to correct, which was most of them.
Royce’s diagram became the most influential illustration in software engineering — more widely reproduced than understood, more widely practiced than defended, the architectural drawing for a building its own architect said should not be built.
The Phases
Requirements
The first and most dangerous phase. A team of analysts interviews stakeholders, documents every feature the system must have, every business rule it must enforce, every edge case it must handle, and produces a Requirements Specification Document that is — at the moment of its completion — the most accurate and most obsolete document in the organisation.
The document is accurate because it precisely captures what the stakeholders wanted on the day they were asked. It is obsolete because the stakeholders have since changed their minds, the market has shifted, the competitor has launched a feature nobody anticipated, and the regulatory environment has introduced a new compliance requirement.
The document is signed off anyway, because the Gantt chart requires a signed-off requirements document before design can begin, and the Gantt chart is the project.
Design
The system is designed from the requirements. The architecture is chosen. The database schema is defined. The integration points are documented. The design is complete, comprehensive, and based entirely on requirements that are already drifting from reality.
Implementation
Developers write code. The code implements the design. The design implements the requirements. The requirements describe a system that the users no longer want but cannot change because the requirements were signed off, and changing signed-off requirements requires a Change Request, and a Change Request requires a Change Advisory Board, and the Change Advisory Board meets monthly, and by the time the change is approved the implementation phase is over.
Testing
Testers test the software against the requirements. The software matches the requirements. The requirements do not match what the users need. The testers report that the software is correct. The users report that the software is useless. Both are right.
Deployment
The software is deployed. The users use it. The users discover what they actually needed, which is different from what they specified, which is different from what was designed, which is different from what was built, which is nevertheless what was tested and approved.
Maintenance
The phase that was supposed to be a small effort and ends up consuming 80% of the total cost, because the software must now be changed to do what it should have done in the first place, which could not have been known in the first place, which is the entire argument against waterfall, which is on page 3 of Royce’s paper, which nobody read.
Why It Persists
Waterfall persists for three reasons, and none of them are technical:
Budgets are waterfall. Finance departments allocate budgets annually, approve capital expenditure for defined deliverables, and expect a fixed scope for a fixed price. This is waterfall economics. Agile economics — “we don’t know what we’ll build, but we’ll build the most valuable thing we can in the time available” — does not fit in a procurement spreadsheet.
Contracts are waterfall. Enterprise software contracts specify deliverables, milestones, and acceptance criteria. You cannot sign a contract that says “we will iterate.” You sign a contract that says “we will deliver X by Y for Z.” This is a waterfall commitment wearing a legal signature.
Fear is waterfall. Acknowledging uncertainty is frightening. A Gantt chart with phases and milestones and a green line progressing left to right is comforting. The green line is a lie — it measures time elapsed, not value delivered — but it is a comforting lie, and organisations prefer comforting lies to uncomfortable truths.
“Waterfall is the methodology that assumes the future is knowable. Agile is the methodology that assumes it isn’t. Enterprise is the condition that uses Agile vocabulary to practice Waterfall because the Gantt chart has already been approved.”
— The Caffeinated Squirrel, in a rare moment of clarity
Measured Characteristics
Inventor: Winston Royce (1970, arguing against it)
Pages of the paper read by industry: 1 (the diagram)
Pages of the paper written: 11
Phases: 5 (Requirements, Design, Implementation, Testing, Deployment)
Phases that go back upstream: 0 (in theory)
Phases that should go back upstream: all of them (in practice)
Requirements accuracy at sign-off: high
Requirements accuracy at deployment: archaeological
Gantt charts produced: millions
Gantt charts that reflected reality: unconfirmed sightings
Cost of maintenance vs development: 80% vs 20%
Royce's recommendation: iterate
Industry's response: the diagram was clearer
See Also
- Water-Scrum-Fall — Waterfall wearing Agile vocabulary. The five-week “sprint.” The ceremony without the change.
- Agile — The response. Four values on a napkin. Then twenty-five years of adding process to the napkin.
- Scrum — The framework that was supposed to replace waterfall. Then became the ceremonies that fill the gaps between waterfall phases.
- SAFe — What if waterfall, but with trains? And certifications?
- Enterprise — The condition in which waterfall persists, because budgets, contracts, and fear are waterfall.
