The Waterfall Model was a straw man argument from the beginning (2015)

Reality of Waterfall vs Strawman

• Many recall explicit waterfall processes in the 80s–2000s: formal SDLCs, contracts, audits, big-4 consulting “methods,” government and defense standards.
• Others say they never saw “pure” waterfall; what existed was heavily waterfall-ish but with backtracking and quiet iteration.
• Several argue the “pure, no-feedback waterfall” used in Agile sales is itself a caricature, yet the mentality it represents was very real.

Origins and Intent of the Waterfall Model

• The original 1970 paper didn’t use the term “waterfall” and presented the simple diagram as a starting point, then immediately critiqued it.
• The author recommended doing the process twice and adding feedback loops, anticipating spiral/iterative development.
• Later interpretations and standards codified a stricter, more brittle version than the original intent.

Why Waterfall Took Hold

• Borrowed from physical engineering and Taylorist management: big upfront design, strict phase gates, heavy documentation.
• Made sense when compute was expensive, releases were rare, and changes after deployment were extremely costly.
• Government contracts, safety-critical domains, and legal/compliance contexts favored fixed specs and gated processes.

How Waterfall Looked in Practice

• Long requirements phases, rooms of binders, Gantt charts, formal “gates” between requirements, design, implementation, test, acceptance.
• Often “pragmatic waterfall”: feedback existed but was seen as exception or failure of planning, not a core mechanism.
• Many organizations quietly combined official waterfall with informal prototyping and iterative work.

Where Waterfall (or Near It) Works

• Reported as effective for:
  • High-assurance systems (space, aviation, medical devices, defense, core banking, telecom platforms).
  • Rewrites where requirements are already well-understood.
  • Small, well-bounded internal projects with a clear “done” state.

Critiques and Failures of Waterfall

• Common failure pattern: massive upfront specs, late integration, system doesn’t match real needs, expensive rework or abandonment.
• Seen as encouraging the fantasy of complete upfront knowledge and making course corrections politically difficult.
• Some argue strict waterfall virtually guarantees mediocrity or failure on large, evolving systems.

Agile, “Agilefall,” and Process Cargo-Cults

• Many say “Agile” as practiced often degenerates into mini-waterfalls with heavy ceremony (“wagile,” “Agilefall”).
• Debate centers on matching process to domain: frequent feedback and cheap deployment favor agile; expensive changes favor more upfront design.
• Broad agreement: no single methodology fits all; success depends more on competent people, honest feedback, and sane risk management than on labels.