Imagine you're building a bridge. You design it completely, pour the foundations, raise the structure, and then hand it over to the civil engineer who checks it against the original specs. Logical, right?
Now imagine you're building an app that way. Requirements written in January. Developers coding in March. Testing starting in October. And users seeing the result in December — only to tell you: "This isn't what we meant."
That's the Waterfall way. And for software, it's a design for disaster.
Learning Objectives
By the end of this lesson you will be able to:
- Name and describe the five phases of the Waterfall model
- Explain the "late feedback" problem and why it is so costly
- Identify why testing is structurally disadvantaged in a Waterfall project
The Five Phases of Waterfall
The Waterfall model, formally described by Winston Royce in 1970 (who, ironically, presented it as a flawed anti-pattern), organizes software development into strictly sequential phases:
- Requirements — Document everything the system must do, in full detail, before writing a single line of code.
- Design — Architect the technical solution based on the locked requirements.
- Implementation — Developers build what was designed.
- Verification (Testing) — QA checks the built system against the original requirements.
- Maintenance — Fix whatever breaks in production.
Each phase must be completed before the next one starts. The output of one phase is the input of the next. Changes flow in one direction: downward.
The Problem: Late Feedback
Software is not a bridge. A bridge doesn't change its purpose while you're building it. A software product often does.
In Waterfall, requirements are "frozen" at the start. But business needs evolve. Users discover what they actually want only when they see something working. Technology constraints reveal themselves during implementation. None of these realities fit into a process that assumes you can know everything in advance.
The result: by the time anyone catches a requirements mistake, it's already been baked into the design, coded into the implementation, and will cost 10–100x more to fix than it would have in phase 1.
The exponential cost of late discovery: A requirements error fixed in the Requirements phase costs 1x. Fixed in Design: 3–6x. Fixed in Testing: 10–40x. Fixed in Production: 40–1000x.
The QA Time Bomb
In a classic Waterfall project, testing arrives last. The QA engineer joins in phase 4 — with a codebase nobody outside the dev team has seen, requirements that may have shifted since they were written, and a deadline looming.
This creates the "big-bang" testing problem: instead of finding defects early and often, testing becomes a frantic search through a completed product. Every major bug found at this stage means reopening work that was already "done."
Testers in Waterfall projects often face an impossible choice:
- Report all bugs and delay the release.
- Triage ruthlessly and ship with known defects.
- Get blamed for both outcomes.
When Does Waterfall Still Make Sense?
Waterfall isn't inherently evil — it's misapplied to software. It works well when:
- Requirements genuinely don't change: nuclear reactors, medical devices, space systems — where the specification is locked by regulation before development starts.
- The cost of iteration is prohibitive: you can't re-pour a rocket engine nozzle mid-flight.
- The output is physical, not digital: construction, hardware manufacturing.
For most software — especially web apps, mobile products, and internal tools — none of these conditions apply.
Pro Tips
When you see "big-bang testing" in a project, you're seeing Waterfall logic applied to a non-Waterfall product. Regardless of what the team calls their process, if testing only happens at the end, the feedback loop is broken.
"We don't have time to test" translates to: "we've decided to discover defects in production instead of before release." Understanding this framing helps you have a more productive conversation with stakeholders.
Summary
- Waterfall organizes development into five sequential, non-overlapping phases: Requirements → Design → Implementation → Testing → Maintenance.
- The core flaw: requirements are frozen at the start, but software requirements change — always.
- Late feedback is catastrophically expensive: defects found in testing cost 10–40x more to fix than defects found in requirements.
- QA in Waterfall is structurally last — arriving to a completed, fragile codebase with a deadline already in sight.
- Waterfall still works for regulated, physical, or truly fixed-requirement domains. It fails for most software.