Royce 1970 and the Waterfall Misreading

Narrative

The primary paper's publication history is clear, though secondary sources blur it. Royce presented "Managing the Development of Large Software Systems" at IEEE WESCON in Los Angeles in August 1970, pages 1 to 9. Bibliographic records show a reprint in the Proceedings of the Ninth International Conference on Software Engineering in March 1987, pages 328 to 338. The 1987 reprint is probably why many later citations date from the late 1980s, when DoD-STD-2167 and Boehm's spiral model were being debated. Royce opens by calling the content his "personal views", drawn from nine years of spacecraft mission planning and analysis software. Several popular summaries I retrieved (Medium, ProjectManagement.com, Smartsheet, an Artemis Agile blog) repeat the myth-correction without adding archival evidence, so I have kept them out of the source list.

On naming and mutation, the evidence points to Bell and Thayer. Their 1976 paper "Software requirements: Are they really a problem?" (ICSE-2) is the earliest known use of "waterfall" for this style of process, and Royce himself never used the word. Bossavit's "Leprechauns of Software Engineering" (chapter 7) sets out the standard story, that Royce "invented" waterfall in 1970, and the agile counter-story, that Royce was misread. It also records a third group that treats "waterfall" as a later straw-man term, which makes the agile retelling contested rather than settled. Boehm wrote in 1987 that Royce's paper already treats prototyping as an essential step, and that the earlier Benington and Hosier papers had good approximations to the stagewise model. That undercuts both "Royce invented waterfall" and the cleaner "Royce was a proto-agilist" line.

The standards story is the strongest supported part. Larman and Basili (IEEE Computer, June 2003) report that the DoD experienced significant failures in the late 1980s with the strict, document-driven, single-pass model that DoD-STD-2167 required. They also say that 2167A (February 1988) was meant as an amendment allowing life-cycle neutrality. In their account many still read it as preferring waterfall, because of its document-driven milestones, and the principal creator of 2167 later expressed regret to them. The Defense Science Board report of June 1994 then urged iterative development, and MIL-STD-498 replaced 2167A in December 1994, with an article by Maj. George Newberry titled "Removing the Waterfall Bias". Even 2167 itself, per the Wikipedia summary of section 4.1.2, allowed more than one iteration of the cycle in progress and described an "incremental build" approach. That nuance is worth keeping in view because it separates the text of the standard from how contractors and auditors applied it. One secondary source (Smartsheet) wrongly dates 2167A to 1985, and a Serena paper wrongly says Royce coined the term.

On foresight, Larman and Basili find "hints of iterative development, feedback, and adaptation" in Royce, but say the paper is clearly not classic iterative and incremental development. Walker Royce told them his father "was always a proponent of iterative, incremental, evolutionary development", and Walker then described the CCPDS-R project in 60 pages, with six time-boxed iterations of about six months each, consistent with what became the Rational Unified Process. This is personal communication, so it is testimony rather than archival proof. Larman and Basili also date iterative practice to the mid-1950s, and Gerald Weinberg recalled incremental work in 1957 and said that waterfall labels made practitioners realise they were doing "something else". This supports the view that waterfall dominated documentation and procurement more than practice. Boehm's 1988 spiral paper opens with "The waterfall model is dead" and treats waterfall as a special case of risk-driven process choice.

Gaps in this lane: I retrieved no DORA, ThoughtWorks Radar, Fowler, InfoQ, ACM Queue, MIT Sloan or HBR items on this topic, and I did not retrieve Bertrand Meyer's critique or the DoD-STD-2167 text itself within the search budget.