The waterfall development method is by far the most widely known approach to creating software. As a popular section, included in introductory programming courses throughout the educational system, many would at least recall hearing about the approach. I remember first learning about the waterfall methodology steps back in high school. What was failed to be mentioned, and as Daniel over at dmiessler.com points out, is that the waterfall design model is actually an anti-pattern.
When it was initially laid out, the author explicitly stated that it was an example of how things should not be done.
Wikipedia reveals some history on the origins of the Waterfall Model:
The origin of the term “waterfall” is often cited to be an article published in 1970 by W. W. Royce. Royce himself advocated an iterative approach to software development and did not even use the term “waterfall”. Royce originally described what is now known as the waterfall model as an example of a method that he argued “is risky and invites failure”.
Of course the simplicity of the model raised no questions from the young but impressionable students, who most likely just wanted to get back to getting their games to work. So the model remained in the curriculum books. A rather unfortunate fact, considering the amount of problems arising in a real world application.
The most obvious problem should have been “there are no feedback loops”. For anything! There will be bugs found during testing. Always. Those bugs need to be addressed in the implementation, sometimes even in the design itself, and tested again. Also, realistically, clients often tend to change their minds about the requirements half way into the project – such a static approach as Waterfall is just a setup for trouble. As well, the maintenance stage is a lot more involving if the software comes with a version number. Possibly not applicable to a school assignment, but there is a real world out there, and it should be considered.
The Waterfall Model could remain in schools, but then it should be taught explicitly as an anti-pattern. Explain the problems. Conclude with “don’t do this”. For some better software development models, consider Agile Development or even possibly Extreme Programming. It would also be interesting to hear what methods of software development you’ve learned about in school, and how applicable that was later on. Leave a comment!