How software development misremembered Winston Royce and then made the misunderstanding real
I recently read Winston W. Royce’s 1970 paper, Managing the Development of Large Software Systems which many say defined the start of the Waterfall method for software development. Like many project professionals, I knew the paper mainly through summaries, diagrams and repeated claims that it introduced the waterfall model of software development. What I found was not the origin of waterfall as it is commonly described. It was a warning about the risks of treating software development as a single-pass, linear process, followed by practical recommendations for making the process iterative and substantially safer.
This matters because conventional history has shaped a false choice. Predictive development is routinely presented as linear, rigid and resistant to learning, while Agile is presented as the approach that introduced iteration, feedback and customer involvement. Royce’s paper does not support that distinction. His approach remained structured, phase-based and documentation-heavy, but it also depended on feedback loops, prototyping, repeated development and continuing customer participation.
The central conclusion: pure waterfall was not so much invented as retrospectively assembled from a simplified diagram, then made real through contracts, phase gates, baselines and organisational behaviour.
Royce’s paper contains the diagram that later became famous: system requirements flow to software requirements, analysis, program design, coding, testing and operations. He made the diagram to represent what he referred to as a “grandiose approach to software development”. Read in isolation, the diagram appears to prescribe exactly the process that is now called waterfall. The caption, however, merely describes these as the implementation steps required to develop a large computer program for delivery to a customer. Royce did not name the diagram as a methodology, and he did not call it waterfall.
The Diagram Everybody Remembered
Here is the diagram in question:
More importantly, Royce immediately qualified it. In the first sentence after the diagram he wrote that he believed in the underlying concept, but that the implementation shown was “risky and invites failure“. His concern was practical rather than philosophical. If the first genuine encounter with timing, storage, data transfer and operating constraints occurred during final testing, discoveries at that point could require major redesign. That redesign could invalidate the software requirements on which the whole development had been based, returning the project to its origin with a potentially severe cost and schedule overrun.
Royce’s subsequent diagrams therefore added feedback. He first showed iteration between adjacent stages, then recognised that real design discoveries would not remain conveniently confined to the immediately preceding stage. Testing could force a return to program design, and design could force reconsideration of requirements. The neat downward cascade was not his description of how successful development worked. It was the simplified starting point from which he explained why stronger controls and iteration were necessary.
What Royce Actually Proposed
Royce retained the broad progression from requirements through design, coding, testing and use, but he added five features intended to remove most of the development risk. The first was preliminary program design before detailed analysis was treated as settled. This was an early recognition that requirements cannot be developed intelligently without some understanding of the architecture, operating constraints, data structures and practical design choices needed to satisfy them.
The second feature was extensive and current documentation. Royce was managing large, complex and safety-sensitive software efforts involving many people, so he did not see documentation as optional administration. It was part of the technical product and the means by which requirements, design, testing and operations remained connected. This aspect of his approach is plainly not Agile in the contemporary sense, but it does not make the development process non-iterative.
His third recommendation was particularly striking: do the job twice. Where a system involved new or uncertain technical areas, the version delivered for operational use should effectively be the second version. The first pass would perform the whole process in miniature, functioning as a prototype or pilot that exposed design choices, interfaces, operating constraints and weak assumptions before the full investment was committed.
Royce’s final two features were disciplined management of testing and formal, continuing customer involvement. Testing was to be planned, resourced and monitored as a central management concern, not left until the programmers believed they had finished. The customer was to participate at several significant points rather than appear only at the beginning to provide requirements and at the end to accept the product. Taken together, these recommendations describe a structured, risk-driven and iterative development process, although not an incremental product-delivery model of the kind used in modern Agile development but certainly not some sequential, linear process that only moves forward as the Waterfall myth perpetuated.
The diagram, in the same paper, that outlines the approach he advocates looks like this:
How The Process Became ‘Waterfall’
The word waterfall does not appear in Royce’s paper. The earliest known published use of the term in this context is in a 1976 paper by T. E. Bell and T. A. Thayer, Software Requirements: Are They Really a Problem? Referring to Royce, they wrote that he had introduced the concept of the “waterfall of development activities”. The label therefore appears to have been created by Bell and Thayer and then attributed retrospectively to Royce.
Even Bell and Thayer did not present software development as a process in which earlier work could never be reconsidered. Their paper concluded that requirements needed continuing review and revision, and it referred explicitly to iteration through the development cycle. They described a disciplined top-down sequence, but they also understood that design, implementation and testing would reveal requirement problems. The first writers to call the process waterfall were therefore not straightforward advocates of the pure, irreversible model later associated with the term.
The Staged Model Was Older Than Royce
Royce was not the first person to show software development as a series of stages. Herbert D. Benington presented a recognisably similar production process in 1956 when describing development of the software for the SAGE air-defence system. His sequence moved from an operational plan and specifications through coding, parameter testing, assembly testing, shakedown and evaluation. This was a highly disciplined engineering environment, but it was not a process without feedback.
Benington explained that detailed coding uncovered inconsistencies that required revisions to coding specifications and sometimes to operational specifications. He also noted that test specifications could be prepared in parallel with coding and that the system was gradually assembled and tested, first with simulated inputs and then with live data. In the foreword written when the paper was republished in 1983, he disclosed that the team had built a 35,000-instruction experimental prototype before undertaking the main development.
Benington was also explicit about the danger of trying to complete successive specifications before writing any code. He called that attitude misleading and dangerous because detailed analysis, including coding, was needed to understand the performance and trade-offs of the software. Looking back, he believed that an evolving approach would have reduced SAGE’s overall software development costs by approximately 50 per cent. One of the earliest staged software processes therefore also contained prototyping, progressive integration, testing and revision.
Did Anyone Actually Advocate a One-Way Process?
The evidence requires a careful answer. Later textbooks, training materials and organisational methods certainly described a pure waterfall model in which one phase was completed and approved before the next began. Some recommended it for work where requirements were believed to be stable and well understood. Organisations also implemented processes that were functionally close to one-way development, particularly where contracts and governance made it difficult to reopen an approved requirement or design decision.
However, it is difficult to identify a credible foundational software-engineering source that carefully argued for an absolutely irreversible process with no feedback. Three different ideas have been collapsed into the same label. The first is that development activities have a broadly logical order because requirements inform design, design informs implementation, and implementation must exist before the complete system can be tested. The second is that these activities are governed through formal phase gates, approvals and baselines. The third is that no earlier activity can ever be revisited. Most serious sources accepted the first, many institutions enforced the second, but comparatively few defended the third as a realistic account of software development.
How Governance Made the Misunderstanding Real
The United States Department of Defense standard DOD-STD-2167A is often cited as the institutional adoption of waterfall. Yet the 1988 standard expressly stated that it was not intended to specify or discourage any particular software development method. It made the contractor responsible for selecting suitable methods, including rapid prototyping. It also stated that the major development activities could overlap and be applied “iteratively or recursively”.
At the same time, the standard required approved development plans, formal reviews and audits, baselined requirements and designs, extensive deliverable documentation, traceability, configuration control and formal approval of many changes. Those requirements did not prohibit iteration, but they changed its economics. Once a requirement had been approved and incorporated into a contractual baseline, revisiting it could require a formal change proposal, additional documentation, management approval and possibly a contractual negotiation. Feedback remained technically permitted while becoming managerially expensive.
This helps explain how organisations could sincerely claim compliance with an iterative standard while behaving as though development were one-way. The formal milestone structure became the programme schedule, document completion became the visible measure of progress, and changing an earlier decision became evidence of failure rather than evidence that the project had learned something. When DOD-STD-2167A was replaced, the 1996 guidebook for MIL-STD-498 acknowledged that formal reviews could force a waterfall development model. The replacement deliberately reduced time-oriented dependencies and explained how the standard could be applied across multiple builds or iterations.
Agile Was Still Responding to a Real Problem
Correcting the history does not mean that Agile criticised an imaginary problem. By the 1990s, many software organisations were working with large batches of requirements, lengthy design stages, late integration, delayed customer feedback and contractual structures that treated change as an exception. Whether or not the founding papers had prescribed this behaviour, it was real. Agile methods responded to that reality by shortening feedback cycles, delivering working software more frequently and treating emerging knowledge as a normal feature of development.
What the history does undermine is the simplistic claim that predictive development is inherently non-iterative or that Agile invented feedback, prototyping and customer participation. Royce incorporated all three in 1970, and Benington’s account shows comparable practices in the 1950s. The more useful distinction is not between linear waterfall and iterative Agile, but between approaches that make learning early and affordable and those that defer learning or punish the project for acting on it.
What Project Professionals Should Take from This
The first lesson is to be cautious with methodological labels. A diagram can describe the logical relationship between activities without prescribing that they occur once, sequentially and without overlap. Before criticising or adopting a named approach, we should examine what decisions it requires, how it handles new evidence, when customers become involved and how expensive it makes changing an earlier assumption.
The second lesson is that governance design matters as much as lifecycle terminology. An organisation can draw feedback loops on its process map while using approvals, contracts, funding gates and performance measures that penalise every return to an earlier decision. Conversely, a project can retain clear phases, documentation and formal assurance while deliberately using prototypes, reference implementations, progressive elaboration and controlled iteration to reduce uncertainty before irreversible commitments are made.
Finally, iteration is not a substitute for discipline, and discipline does not require pretending that knowledge is complete. Royce’s approach was demanding because he wanted large software developments to expose risk early, document the evolving design, test deliberately and involve the customer throughout. That is a more sophisticated position than either the waterfall caricature or the assumption that every formal control obstructs adaptability.
Conclusion
Pure waterfall has no clear founding manifesto. Royce did not name or advocate it, Bell and Thayer named the waterfall while still recognising iteration, Benington combined staged development with prototyping and revision, and even the defence standard commonly blamed for institutionalising waterfall formally allowed overlapping and recursive work. The rigid model emerged through later simplification and through governance systems that made feedback difficult to act upon.
The profession remembered Royce’s diagram and forgot the warning printed beside it. It then built contracts, gates and reporting systems around the simplified picture until the misunderstanding became an operational reality. Reading the original paper does not eliminate the need for Agile or adaptive development, but it does reveal that the argument was never properly between iteration and structure. The real choice has always been whether a project is organised to learn before uncertainty becomes expensive.
References
Benington, H. D. (1956; republished 1983). Production of Large Computer Programs. Annals of the History of Computing, 5(4), 350-361.
Bell, T. E., and Thayer, T. A. (1976). Software Requirements: Are They Really a Problem? Proceedings of the Second International Conference on Software Engineering, 61-68.
Larman, C., and Basili, V. R. (2003). Iterative and Incremental Development: A Brief History. Computer, 36(6), 47-56.
Royce, W. W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE WESCON.
United States Department of Defense (1988). DOD-STD-2167A: Defense System Software Development.
United States Department of Defense (1996). MIL-STD-498 Application and Reference Guidebook.
