The Waterfall Process: Is it Still Viable?

Proponents of the waterfall approach to software development often act like they believe the process was handed down (along with the 10 commandments) as “the right way” to develop software. Having a historical perspective on the process might be useful in debunking this myth. Back in 1970 – that’s right, almost 50 years ago – Winston Royce wrote a paper called “Managing the Development of Large Software Systems”. In it, he describes what we think of now as the waterfall process, although he didn’t call it that. Here is his first diagram:

According to urban legend, someone at the Department of Defense read the first part of the paper, liked the first diagram, and decided to use the approach, which was later adopted as a federal mandate. If that’s true, they didn’t bother to read the next sentence under the diagram: “I believe in this concept, but the implementation described above is risky and invites failure.” Royce goes on to point out that since testing occurs at the end of the process, there a potential for discovering “disruptive changes in design” during testing that can result in a major redesign. He recommends feedback loops between each phase, doing more design up front, creating an early version of the software to test feasibility, and involving the customer to help avoid these problems. He also recommends doing a lot of design documentation. The paper adds to and evolves the above diagram, and ends with a much more complex diagram that incorporates his recommendations. Poor Royce – he is now considered the “father” of the waterfall process, even though what he was trying to do was point out its limitations!

Learn About our Agile & Scrum Training, Coaching, & Certification Services

Keep in mind that in 1970 a lot of software development was being done for things like missile and spacecraft guidance systems. (The moon landing was in 1969.) Royce worked at TRW, and he points out that “in my experience there are whole departments consumed with the analysis of orbit mechanics, spacecraft attitude determination…and so forth, and when they have completed their difficult and complex work, the resultant program steps involve a few lines of serial arithmetic code.” In Royce’s world, once the analysis was completed, the requirements didn’t change much, and there wasn’t much uncertainty around them. That type of analysis is very different than analyzing needs for today’s business systems and users, which involves dealing with uncertainty and frequent changes to the requirements.

So the next time you get pushback about using a more agile approach from someone who thinks the waterfall process is engraved on stone tablets, you might point out that it was defined almost 50 years ago, and the man who is supposed to be responsible for it didn’t think it worked very well!