The Waterfall Misconception: What Dr. Royce Really Said in 1970

The Waterfall Misconception: What Dr Royce Really Said in 1970
Introduction
The “waterfall” method is one of the most referenced and misunderstood models in the history of software engineering. For decades, it has been depicted as a rigid, linear process—a step-by-step approach where each phase must be completed before moving to the next. This model is often attributed to Dr Winston W. Royce’s seminal 1970 paper, “Managing the Development of Large Software Systems.” However, a close reading of Royce’s original work reveals that the common depiction of the waterfall is not only a misinterpretation but, ironically, the very approach Royce warned against. In this blog post, we’ll unpack the myth, analyse the source, and explore the real lessons for modern software development.
1. The Birth of the Waterfall Model
The Context of 1970
In the late 1960s and early 1970s, software engineering was a young discipline. Large-scale projects, especially in aerospace and defence, were failing at alarming rates due to poor requirements, weak communication, and a lack of systematic processes. Dr Royce, working at Lockheed, set out to address these challenges.
Royce’s Diagram
On page 2 of Royce’s 1970 paper, a diagram appears showing a sequential development process with steps like:

• System Requirements
• Software Requirements
• Analysis
• Program Design
• Coding
• Testing
• Operations

This diagram, with its top-down flow, would become the icon of the “waterfall” model. Yet, beneath the surface, the story is more complex.
2. What Royce Actually Said
A Caution, Not a Prescription
Royce did not advocate the strictly sequential process that is now called the waterfall method. In fact, he offered the diagram as a critique:
“I believe in this concept, but the implementation described above is risky and invites failure.” (Royce, 1970)
He immediately points out the dangers of discovering issues late in the cycle, when changes are expensive and disruptive.
The Perils of Linear Development
Royce warned that testing at the end of the process is the first time the system’s actual behaviour is observed:
“Far too often the software is found to be unacceptable only after the project is near completion.”
He saw this as a fundamental flaw—not a best practice.
3. The Real Message: Feedback and Iteration
Feedback Loops
Royce’s true recommendation was to introduce feedback loops between phases. His revised diagrams in the paper show iterations, with arrows pointing back from later to earlier steps. He advocated for:

• Revisiting requirements after design or testing
• Reevaluating design after coding discoveries
• Iteratively refining the system as new information emerges

Prototyping and Verification
Royce also recommended building prototypes and conducting rigorous reviews at every stage. These practices are now common in Agile and modern iterative methods.
“The development process should include the construction of a pilot model for each major phase of the software project.” (Royce, 1970)
He emphasised that validation and verification must happen throughout, not just at the end.
4. How the Waterfall Myth Spread
Oversimplification in Practice
Despite Royce’s warnings, the initial sequential diagram was easy to understand and teach. Managers and educators began to present it as a prescriptive process, omitting the context and feedback loops.
Institutionalization
Government agencies and contractors, seeking structure and predictability, mandated the “waterfall” approach in contracts and standards. Textbooks cemented the model, and soon, “waterfall” became shorthand for a process Royce himself criticised.
5. The Cost of the Misconception
By locking teams into rigid phases, organisations experienced the very problems Royce anticipated: late discovery of requirements issues, inflexible designs, and costly overhauls late in the project.
Modern Agile and iterative approaches echo Royce’s real message: embrace feedback, iterate, and validate early and often. The success of these methods underscores the dangers of the misunderstood waterfall model.
6. Revisiting Royce: Lessons for Today
Read the Source
Software professionals should read Royce’s paper directly. His nuanced approach is relevant today:

• Iterate: Plan for multiple passes through the phases.
• Validate: Test early and often, not just at the end.
• Prototype: Use models to clarify requirements and design.
• Communicate: Foster ongoing dialogue among stakeholders.

Avoid Dogma
No single process fits all projects. Royce’s real legacy is the idea that processes must adapt to complexity and uncertainty.

7. Conclusion
The waterfall model, as commonly depicted, is a myth born from misreading Dr Royce’s 1970 paper. Far from promoting rigid linearity, Royce cautioned against it and recommended iteration, feedback, and early validation. To build successful systems, teams must move beyond simplistic models and embrace the adaptive, learning-oriented approach Royce truly envisioned.
References:

• Royce, W. W. (1970). Managing the Development of Large Software Systems.