No such thing as "Waterfall"
Back in 1970 a man named Winston W. Royce published a paper with IEEE entitled, "Managing the Development of Large Software Systems" [1]. He begins, "I'm going to describe my personal views about managing large software developments
Interestingly, it is this paper which is often cited as the source of the term "Waterfall", a term that has been used ever since to describe an approach to implement a software system—as if Royce himself endorsed it. He didn't. Indeed, Royce uses the term "waterfall" exactly zero times in his paper. He did however include this picture.
It is the second diagram in his paper, and the first to include all the phases of the process. It seems that most readers got as far as this diagram, maybe read the description, and decided there was no need to read further. These are the steps to develop a large computer program, they decided. It says so here. Let's get going.
Had they bothered to continue, the very next sentence would have given pause for thought: "I believe in this concept, but the implementation described above is risky and invites failure". It seems few did—either read, or think—and Waterfall as an implementation method was born. A paper that essentially advised "Don't do this" was understood as saying "Do this". Such is the power of sliver-bullet thinking.
Royce's paper is well worth reading to the end. We can see from the successive diagrams that indicate feedback and frequent iteration
领英推荐
Those that advocate "Waterfall" for software development are actually not following these 1970 recommendations at all, but something much older, something like a manufacturing process that grew up during the industrial revolution (1760–1840). A more general term for the approach would be "defined process
No software system has ever been made before. Each one is new. Each one is unique and designed for a specific purpose. We cannot define an exact process to make a thing that has never been made; it is actually impossible, and it takes magical thinking to believe we can.
Developing new products require emergent processes
—
[1] Royce, W.W. (1970) Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, 26, 328-388. PDF version available here.
Follow me for unconventional Agile opinions and insights shared with humor.
3 个月It's funnier than that... Royce didn't use the term "Waterfall," presented the linear approach as flawed, and advocated for iterative processes. The term "Waterfall" first appeared in a 1976 paper by Thomas E. Bell and T.A. Thayer ("Software Requirements: Are They Really a Problem?"). They refer to the sequential development process as the "Waterfall model," and it stuck. But let's go one step further. Bell and Thayer concluded that software projects often hit roadblocks because of bad requirements. Issues like missing, ambiguous, or wrong requirements were common, and were a huge reason projects failed or systems didn’t work as intended. They advised starting with as solid and clear a set of requirements as you can, but then having the discipline to update them throughout the project as new information comes to light. That’s where the irony comes in. The "Waterfall" term got attached to a rigid, step-by-step process, but Bell and Thayer weren’t advocating for that at all. They recognized the need for upfront clarity and ongoing refinement, which is... iterative. The confusion probably came from how people interpreted Royce's diagrams in 1970. A picture's worth a thousand words, but it helps to also read the thousand words.
Business Manager Systems - Avanceon | LUMS EMBA '24 Gold Medalist | PMP?,TüV FS Engineer SIS | Business Development, Business Strategy, Digital Transformation, Financial Management | Design Thinking & Customer Centricity
1 年Quick questions: 1. How would you justify the emphasis on thorough documentation, as indicated on Page 5/11 and in the screenshot below? 2. Why did Royce emphasize the Big Design Up Front approach, which is an inherent requirement of the Waterfall methodology, despite its limitations?
I agree with your position, mostly. But let's not forget his essay also, unfortunately, reinforced key elements of the Waterfall myth: · Royce argued “begin the design process with program designers, not analysts and programmers”. · And “ensure that a preliminary program design is complete before analysis begins”. To understand the context of those suggestions, and to understand why Royce had not yet abandoned the Waterfall myth entirely, it helps to remember that computers were the size of trucks and the cost of change was extremely high. A design flaw discovered late in development was expensive and time-consuming: much more than changing a few lines of code, imagine having to disassemble a truck-size computer, manufacture new components, and rewire entire electrical circuits. He argued it was necessary to spend the requisite time designing with chalkboard and paper before employing analysts and programmers (i.e., the people who assembled the hardware, operated the keypunch machines, catalogued the punch cards, and ran the programs). Many readers of his essay concluded that segregated sequential phases are necessary.
Professional People Geek | Author | CEO | Certified Scrum Trainer | Facilitator | Agility Guide & Mentor
1 年Thanks for posting. I point out this fact from 1970 all the time in #csm workshops. Reading comprehension goes a long way. Too many look at a picture and make assumptions.
Curating valuable patterns for customer-centric people driven Product cultures. Enabling flow in adaptive organizational ecosystems.
1 年Tobias Mayer if you look at the article he also says do all the steps at least twice. And the second time you’ll be closer to what the customers might want. Even with possible big batch it was recommended to have two full iterations. Something conveniently forgotten and assumed as first time get it right.