The History of the Waterfall Model

By Victor Hoang · Updated Oct 24, 2026

In June 1956, Herbert Benington of MIT's Lincoln Laboratory gave a paper at a Navy symposium. It described how the Semi-Automatic Ground Environment (SAGE) team built one very large air-defense program.

The waterfall model is the idea that a large project should run through fixed phases in order: requirements, design, build, test, deliver. Its sequence was already in use on the SAGE air-defense software in the mid-1950s. Its famous diagram comes from Winston Royce's 1970 paper. Its name came later, in a 1976 paper by two other authors. The through-line is a misreading. A sequence its own author called risky became a standard that governments required, and was then rejected in the open.

This article follows the sequence from that lab to the Pentagon's rulebooks and then to the Agile Manifesto, and it keeps three things apart that are often blurred: the staged process that came first, the paper that drew the diagram, and the standards that turned the diagram into a contract. For the method itself, see waterfall methodology in project management and agile vs waterfall. For the wider field, see the history of project management.

Timeline at a Glance

Dates here separate a practice from a paper, a paper from a name, and a draft from a release. Where the label and the practice differ, the row says so.

The SAGE Process (1956-1960s)

Air-defense engineers sequence a program the way they sequence hardware

Start with a room full of radar, communications and computer engineers. According to Barry Boehm's 2006 retrospective, the SAGE air-defense system brought them together with a handful of nascent software engineers to detect, track and stop enemy aircraft over the United States and Canada. The hardware engineers set the software process, and Boehm shows their 1956 process as a sequential, waterfall-type model that, rearranged into a V with coding at the bottom, matches the later V-model.

Benington's paper is the record. He presented it in June 1956 at a symposium on advanced programming methods sponsored by the Navy Mathematical Computing Advisory Panel and the Office of Naval Research, and it was reprinted in 1983 in the Annals of the History of Computing. His figure of program production runs from a general operational plan through machine, operational, program and coding specifications, then coding, parameter testing, assembly testing, shakedown and system evaluation. Even in 1956 the sequence was not a one-way street: he notes that detailed coding uncovers inconsistencies that send revisions back into the coding specifications and occasionally the operational ones.

The scale explains the discipline. Benington's 1983 foreword says the effort grew to close to half a million computer instructions, and that only about a quarter of them supported the air-defense mission itself. The rest generated programs, tested systems and produced documentation. The same foreword says the audience of 1956 was chilled to hear the team could not beat $50 per instruction when the common goal was under $1, and that the initial prototype program slipped its schedule by about a year. Why did it work as well as it did? He credits engineering habits: "trained to organize our efforts along engineering lines," with a chief engineer responsible for how the pieces fit.

Here is the precursor in plain terms. SAGE's staged process was a way of organizing a very large job, and Benington's team never called it a waterfall. Importantly, his own hindsight cut against the rigid reading. In the 1983 foreword he warns that writing the top-level specifications before measuring what the software can do is "terribly misleading and dangerous," and says SAGE began only after an experimental prototype of 35,000 instructions that twenty people understood in detail. If he had it to do over, he writes, he would have evolved the system from that base, and he estimates that would have cut costs by about half. That is a 1983 estimate made in hindsight, not a 1956 finding.

What this means for teams today: a phased plan can be sound when people have already built a small working version and understand it. The trouble starts when the phases replace the learning.

Royce's Paper (1970-1975)

A warning against the one-pass plan is drawn as a diagram

Fourteen years later, a spacecraft-software engineer published his personal views. Winston Royce's paper appeared in the August 1970 proceedings of the IEEE WESCON conference, pages 1 to 9, and he opens by saying he had worked mostly on software packages for spacecraft mission planning, commanding and post-flight analysis, with mixed success at finishing on time and within cost.

His argument runs in four moves. First, every program has an analysis step and a coding step, and that alone is enough for a small program that its builders will operate themselves. Second, a larger system needs more: two levels of requirements analysis before, a program design step between, and testing after. His Figure 2 shows seven boxes, from system requirements through operations. Third, he says he believes in this concept but the implementation is risky and invites failure. His reasoning is that testing, at the end, is the first time timing, storage and input and output behavior are experienced rather than analyzed, and a failure there forces a redesign that can mean an overrun of up to 100 percent. Fourth, he adds five features to avoid that outcome.

Those five features are the part of the paper that rarely gets quoted:

1. Program design comes first, before analysis and coding, even at the risk of being wrong.
2. Document the design. He calls the first rule of managing software "ruthless enforcement of documentation requirements," and says a software specification must run far beyond the 30 pages he would expect for a comparable hardware purchase.
3. Do it twice. Arrange for the delivered version to be the second version for critical areas. For a 30-month effort, he suggests a pilot model of about 10 months.
4. Plan, control and monitor testing, using specialists who did not write the code and checking every logic path at least once.
5. Involve the customer at formal points after requirements, so that commitments are made before final delivery.

His summary says each item costs more money, and that in his experience the simpler method had never worked on large software efforts. In other words, the paper's most quoted picture is the thing it argues against. Craig Larman and Victor Basili, writing in IEEE Computer in 2003, say many people incorrectly view Royce's paper as the paragon of single-pass waterfall, and report that Royce's son Walker, a contributor to later iterative methods, described his father as a proponent of iterative, incremental, evolutionary development who saw the sequential form as the simplest description, not one that would work for anything but straightforward projects.

One more correction belongs here. The word "waterfall" does not appear in the Royce paper. The text of the paper uses figures and step names only.

Boehm describes Royce's contribution differently from the myth. In his 2006 retrospective, Boehm says Royce's version added the idea of confining iterations to successive phases and a "build it twice" prototyping activity, and that a later version emphasized verification and validation of each phase's artifacts, drawing on TRW, IBM, GTE and Safeguard data about the cost of finding defects early versus late.

What this means for teams today: read the whole paper before citing the picture. If your process keeps the phases and drops the pilot, the documentation and the customer checkpoints, you have kept the part Royce called risky.

The Name Spreads (1976-1984)

"Waterfall" enters print, and the objections arrive with it

The label came from other hands. In October 1976, T. E. Bell and T. A. Thayer of TRW presented "Software Requirements: Are They Really a Problem?" at the second International Conference on Software Engineering, held in San Francisco on 13 to 15 October, pages 61 to 68. Their paper describes a top-down series of requirements documents and says Royce introduced the concept of the "waterfall" of development activities. A recent history of the model likewise notes that the term does not appear in Royce and was popularized by Bell and Thayer in 1976. In short, the word is in print by 1976 and is not in Royce's paper.

Critics were quick. Larman and Basili trace a steady line of objections in the same years. In 1976 Harlan Mills of IBM warned that doing the stages in sequence and not in iteration, without user feedback between them, moves a project from grand to grandiose. In 1978 Tom Gilb began a column in the UK's Computer Weekly that promoted small evolutionary steps. In 1981 Daniel McCracken and Michael Jackson argued against the "stultifying waterfall" in a chapter called "A Minority Dissenting Position," and in 1982 they followed with "Life-Cycle Concept Considered Harmful," a title echoing Dijkstra's famous letter on the go-to statement. Larman and Basili add a telling detail: the use of "life cycle" as a synonym for waterfall in those years suggests how dominant the model was.

Practice was running ahead of the label, too. Larman and Basili report that IBM's team on NASA's space shuttle software, from 1977 to 1980, used a series of 17 iterations over 31 months, because the shuttle's requirements changed during development. They quote the authors admitting that the ideal life cycle could not be strictly applied. A 1984 account of an air-defense project that began in 1977 says the waterfall model was adopted because the Department of Defense's standards guided development, even though real development is iterative. The model was already becoming something organizations did to satisfy a rulebook.

What this means for teams today: a name makes a method easy to adopt and easy to reject, and both can happen without anyone reading the source.

The Standards Years (1985-1994)

The Pentagon turns a diagram into a contract

By the mid-1980s, defense software contracts tied payment to passing a review at the end of each phase. Boehm's retrospective names the cause: the 1985 DoD standards DoD-STD-2167 and MIL-STD-1521B, which strongly reinforced the waterfall model by tying its milestones to management reviews, progress payments and award fees. Boehm adds that the model was most often interpreted as purely sequential, with design not starting until requirements were complete, and that government process standards reinforced that reading.

Alongside the standards, the critics grew louder and more senior. Frederick Brooks, according to Larman and Basili, wrote in his 1986 essay "No Silver Bullet" that much of software acquisition rests on the assumption that you can specify a satisfactory system in advance, and called that assumption fundamentally wrong. In 1986 David Parnas and Paul Clements argued that the ideal of complete specifications first is impractical, because users seldom know exactly what they want, details emerge during building, and requirements change. Barry Boehm's risk-driven spiral model, published in Computer in May 1988, offered a formal alternative, and Larman and Basili note an earlier 1985 version.

The shift reached the standard itself. By the late 1980s, per Larman and Basili, the DoD was seeing significant failure in software acquisition built on the strict, document-driven, single-pass reading of DoD-STD-2167. They cite a 1999 review of a sample of earlier DoD projects worth $37 billion in which 75 percent of the projects failed or were never used. A task force chaired by Brooks reported in October 1987 that 2167 needed a radical overhaul, and DoD-STD-2167A followed in February 1988. It said it did not intend to prescribe any particular method, yet many readers took it as the epitome of a waterfall specification. Larman and Basili add that the principal creator of the original standard later expressed regret, saying he had not heard of iterative development at the time.

Another Defense Science Board task force, on acquiring defense software commercially, reported in June 1994 that the DoD should manage programs with iterative development. In December 1994 MIL-STD-498 replaced 2167A. A summary of its changes carried a section titled "Removing the Waterfall Bias," and the standard describes development in one or more incremental builds.

There was a commercial pull as well. Boehm reports that in the late 1980s Hewlett Packard found its market sectors had product lifetimes of about 2.75 years while its waterfall process took 4 years to develop software, and that investment in product-line architecture and reuse brought development time down to one year by 1991-92.

What this means for teams today: when a method is written into a contract, it outlives the evidence for it. Check whether your governance requires a sequence your delivery team no longer believes in.

The Backlash (1986-2001)

Brooks, the defense advisers and Snowbird push back

This era overlaps the last one, since the standards and the objections ran at once. The turning point is not a document but a tone. At the 1995 International Conference on Software Engineering, as Larman and Basili record it, Brooks said: "The waterfall model is wrong!" Their account says public awareness of iterative development accelerated through the 1990s, with hundreds of books and papers and dozens of methods built on time-boxed iterations of one to six weeks.

The culminating event was a meeting. From February 11 to 13, 2001, seventeen people met at the Lodge at Snowbird, a ski resort in Utah's Wasatch mountains, and the group's account describes an alternative to "documentation driven, heavyweight software development processes." Boehm's retrospective lists the four value preferences that came out of it, including working software over comprehensive documentation. You can read the document itself in the Agile Manifesto article, and the methods that followed in what is Scrum.

The turn was not a victory lap for iteration over planning. Boehm points to two causes of the shift away from the sequential model: time to market, and products whose requirements emerge as users see them, not before. He cites the user's line, "I'll know it when I see it," as the shorthand for the second. Those are reasons about uncertainty, and they say little about situations where requirements truly are stable.

What this means for teams today: the backlash worked because it named conditions, not villains. State the conditions where sequence fits and where it does not, and you avoid re-running the argument every project.

The Hybrid Years (2001-present)

Sequential logic survives inside mixed methods

The model did not vanish. Larman and Basili wrote in 2003 that some commercial and government organizations were still unaware that iterative development had roots going back decades, and that some people viewed it as the modern replacement for waterfall. A 2025 history of the model by Antonios Saravanos at New York University argues the opposite emphasis: the waterfall remains suited to projects with stable requirements, a clear scope, and strong demands for traceability, and its sequence is often kept at the macro level, such as in planning or compliance phases, while Agile methods run at team level.

The practical result is the hybrid. Rather than choosing a method for the whole organization, teams choose per layer: fixed phases and gates where regulation or procurement requires them, short iterations or a Kanban flow board inside. The story of how that mixing was named and spread is in the history of hybrid project management, and the broader sequence of methods is in the evolution of project management methodologies. The scheduling tools that carry the phased plan have their own histories: the Gantt chart, PERT, the critical path method and the work breakdown structure. And the standards body that codified project phases for non-software work is covered in the history of PMI and the PMBOK Guide.

What this means for teams today: treat the phase plan as one layer of the system. Decide which questions need a fixed answer early (budget, compliance, safety) and which can wait for working software.

Key People

Key Facts

• Benington's 1956 SAGE paper describes a staged sequence from operational plan to system evaluation, and the program reached close to half a million instructions.
• Royce's August 1970 WESCON paper calls the simple sequential plan risky and recommends doing the job twice.
• The word "waterfall" is absent from Royce's paper and appears in Bell and Thayer's October 1976 paper.
• DoD-STD-2167 in 1985 tied the sequence to reviews and payments.
• MIL-STD-498 replaced 2167A in December 1994.
• The Agile Manifesto group was seventeen people meeting February 11 to 13, 2001.

The Pattern Behind the History

This is our synthesis, not published research. Five points repeat in the waterfall's history:

• A practice precedes its name. SAGE sequenced work in 1956, and the label arrived 20 years later.
• A warning becomes a template. Royce's diagram of the risky version outlived his five fixes.
• Contracts freeze methods. Standards turned a sequence into a requirement, and their authors later wanted it back.
• The critique comes from inside. Benington, Royce, Mills and Brooks were all builders, not outsiders.
• Conditions decide. The sequence keeps working where requirements are stable and breaks where they emerge.

What It Teaches Teams Today

• Build a small version first. Royce's "do it twice" and Benington's 35,000-instruction prototype both put learning before commitment.
• Document early, and keep it current. Royce's one non-negotiable is as valid for a sprint team as for a defense contractor.
• Keep the customer inside the sequence. His fifth feature is the one most often dropped.
• Do not let governance harden a method. If a contract or policy requires a sequence, review it when delivery evidence changes.
• Match the method to the uncertainty. Fix what is stable and iterate what is not, as the hybrid approach does.