Every time I talk about Spec-Driven Development, someone says the same thing. “That is just waterfall.” They mean it as a gotcha. It is not.
Two things are going on here. First, most people have never read what Royce actually wrote. Second, even the real waterfall is good in the right place. Let me take both.
People attack a strawman
The waterfall model comes from a 1970 paper by Winston Royce, “Managing the Development of Large Software Systems” [1]. People remember one picture from that paper. Requirements flow into design, design flows into code, code flows into test, and everything moves in one direction, top to bottom.
Here is the part they forget. Royce drew that picture and then said it was risky and invited failure. It was his example of the naive approach. The rest of the paper was him fixing it.
He added feedback loops from testing back to design, and from design back to requirements. He said to do the job twice, with a pilot first. He said to plan and monitor testing. He said to keep the documentation current. He said to involve the customer.
So the model people mock is the version Royce warned against. His real proposal never became the popular image. People kept the strawman and threw away the answer.
But let me be fair
I want to add one honest point, because it makes the case stronger, not weaker.
The “Royce was misread” story is sometimes told as if his improved model was already Agile. It was not. His feedback ran between neighbour phases. It was not a set of short iterations that ship working software every few weeks. It stayed plan-driven and document-heavy. Real iterative and incremental development has its own long history, and Larman and Basili traced it back decades before the Agile label existed [2].
And that is fine. That is the whole point.
Waterfall is good when it fits
Plan-driven development, which is the honest name for waterfall, is a good choice when the situation fits it.
It fits when requirements are stable. It fits when a late change is expensive. It fits when you need traceability and real documentation. It fits regulated work and fixed-scope contracts. It fits a domain that is well understood.
In those cases, thinking up front is not bureaucracy. It is risk reduction. You do the hard thinking before you spend the money.
The Agile movement needed a villain to define itself against [3]. So it froze the strawman version in everyone’s memory. That was good marketing. It was bad history.
The real pain was the handoff
Here is the key insight, and it is the one people miss.
The pain of waterfall was never “requirements first”. The pain was the handoff. The specification was a frozen document passed from one group of humans to another. The loop from that document to working, tested code took months.
Barry Boehm described the cost-of-change curve [4]. A defect found late costs far more than one found early. Waterfall pushed testing to the very end, so defects showed up late and cost a fortune. Royce’s fixes, do it twice and add feedback loops, were an attempt to pull that cost back to the left.
He was right about the goal. The tools of 1970 could not deliver it.
Spec-Driven Development is Royce, made cheap
Now look at Spec-Driven Development with AI.
We still put requirements first. We still write a clear specification. We still care about traceability. That part looks like waterfall, and I am happy to admit it.
But the handoff is gone. The specification is executable. We can regenerate the code from it. The loop from spec to running software is minutes, not months. When we learn something new, we change the spec and generate again. The cost of a late change drops toward zero.
This is the thing waterfall could never do. AI flattens the cost-of-change curve that Boehm drew.
So when someone tells me Spec-Driven Development is just waterfall, I do not argue that it is different. I tell them something better.
Spec-Driven Development is what Royce asked for in 1970. We finally have the tools to make it cheap.
Keep IT simple
Read the source before you quote it. Royce did not sell you the waterfall. He warned you about it, and then he told you how to do better.
We are only now catching up to his advice.
References
[1] Winston W. Royce, “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON, Los Angeles, August 1970, pp. 1-9. A reprint is available at https://www.praxisframework.org/files/royce1970.pdf
[2] Craig Larman and Victor R. Basili, “Iterative and Incremental Development: A Brief History”, IEEE Computer, vol. 36, no. 6, June 2003, pp. 47-56. https://doi.org/10.1109/MC.2003.1204375
[3] Kent Beck et al., “Manifesto for Agile Software Development”, 2001. https://agilemanifesto.org
[4] Barry W. Boehm, “Software Engineering Economics”, Prentice Hall, Englewood Cliffs, NJ, 1981. See also Barry W. Boehm, “Software Engineering”, IEEE Transactions on Computers, vol. C-25, no. 12, December 1976, pp. 1226-1241.
[5] “Waterfall model”, Wikipedia. https://en.wikipedia.org/wiki/Waterfall_model Diagram: “Waterfall model” by Peter Kemp and Paul Smith, Wikimedia Commons, licensed under CC BY 3.0. https://commons.wikimedia.org/wiki/File:Waterfall_model.svg
