Search CompSci.ca
Subscribe
Education
Educational flaws: Programming with the Waterfall Model
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!
Read more
Discussion
Post a comment
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Well, in my computer science class this semester, we learned (rather, he taught; I already knew of) the waterfall model. He doesn’t enforce any design process for our applications though; he just cares that we are able to come up with an end result. I almost think he should though for the larger applications, though not the waterfall model.
I’m more of an extreme programming guy myself, with some exceptions.
Reply to comment
Sorry; this just has to be anonymous. At GM, their basic model (developed at great cost and over much time) is waterfall, but disguised so as to look like they’re allowing their vendors (GM doesn’t develop their own software, or even run their own systems) to do whatever they want. You know, in that short period between the long plan phase and the long define phase on one end, and the short test phase and long deploy phase on the other, to use whatever methodology they want to develop software.
Waterfall is not just an anti-pattern in theory, but in practice. The problem is that XP is not any good for corporate development either. What corporations need, and the reason they flock to waterfall methods, is predictability. Failing predictably is better from a corporate finance person’s standpoint than succeeding unpredictably. Agile is a good compromise, but the real problem is that all of these methodologies fall into one of two categories: hire good people from a small pool, thus paying outrageous amounts of money for the programmers but with little overhead, high probability of success, and vast unpredictability; or hire normal people from a large pool, at low money for the programmers but with high overhead, low probability of success, and low unpredictability.
What is needed is a development method that is relatively predictable (at least within a given band), relatively successful (even 50% would be good), and does not rely on having exceptional talent to succeed. I have yet to find such a methodology: in my experience, you succeed with good people or fail with bad people. That sucks for a company that has a lot of projects and not much budget, but it is what it is.
Reply to comment
Wow….
Sadly, I learned the Waterfall Model in highschool. It was what we used for the final project in grade 12. It was slightly modified to include reports needing to be written all the time for the final project. It might explain why we got low marks on the assignment: none of us actually followed the model closely, and were penalized because of it. Both groups (one group of 3, one group of 2) had a decent, working, final program (mine was something like frogger — my partner didn’t help much, other than creating the images, while the other group did a FPS using ray-casting. Both programs were done in Turing.)
I’m only in my first year at university, so we haven’t gotten to the software engineering/development stuff yet. However, we’ll probably get more into that with the course “Software Systems Development and Integration” next year.
I’m just shocked that we learned a highly flawed model. You’d think someone would have realized that it’s flawed, and leave it out of schools. It didn’t sound realistic to me when I learned it originally, but I thought “things must change when you’re working in a large team, or something.”
Thanks for this post, though. It’s been an eye-opener.
Reply to comment
It was tought to us in College, highlighting possible risks in requirement changes, but also enforced as the best approach. In reality, we rarely follow any model really, but it is closer to Waterfall. Tell me exactly what you want before I start. I didn’t know about the fact it’s an anti-pattern. Regardless though of how effective it was, in the WWW, it is possible the worst in practice. Online you need to be aggressive, keep adding and adapting to outside changes and users feedback.
Reply to comment
Perhaps the best approach would be to avoid trying to shoehorn thinking into “models” in the first place, and trust the instincts of programmers, and their ability to solve problems. Of course, that means actually teaching them in such a way that they have that ability.
Reply to comment
This is the first time I’ve heard about the waterfall model and I’ve been through grade 10 and 11 comp sci.
“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â€.” – reminds me of Freud in psychology class.
Reply to comment
[...] Educational flaws: Programming with the Waterfall Model [...]
Yes, it’s flawed, but unfortunately it’s used in industry.
I’m a CIS student in Guelph with co-op experience in avionics software development, and I can tell you that the Waterfall Model is the leading development model for DO-178B (i.e, avionics) certifiable software, and is the model used where I work. Other acceptable models in the industry are the Spiral model and the V model, but to my knowledge they haven’t gained widespread use. This is a very slow-moving, conservative field, by necessity. If you can’t convince a certification board that your solution will not fail under any reasonable circumstance, you don’t get to fly. End of story. They’re very sceptical of new (i.e, unproven) things too.
Although I fully believe that agile methods can produce software of equal or greater quality and reliability to traditional methods, in the more conservative fields these methods will be slow coming. Something tells me we’re stuck with the obsolete Waterfall model for some time to come.
Reply to comment
Your main audience is comprised of high school CS students. At their level, I don’t think it is necessarily appropriate to be discussing *any* development methodologies beyond a simple review. At their level, the only thing that should be worried about right now is core fundamental like grasping syntax and style, primitive data structures like arrays, and some program concepts like looping, recursion, interpreted vs. compiled, etc.. Waterfall vs. Agile vs. RAD vs. next year’s flavour is the concern of large-scale development. Yes, it’s important for anyone who wants to get serious with code, but it’s too early and far too much overhead for them to be concerned with. They don’t need to learn about pair programming and requirements specification and unit testing anymore than they should be required to know Complexity Analysis, NP-Completeness, relational DB normalization, etc.
Further, for a lot of projects anything but waterfall or cowboy coding (to borrow the Agile term) is overthinking and overcomplicating the task at hand. Every project has it’s unique needs, and some styles are more appropriate. Personally, even after taking a course dedicated to them I think Agile and XP are terrible. I’m not the only one that thinks this either. Consider this excellent essay:
http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
Reply to comment
I have studied Waterfall model at college but it was not really something which we had to go into depth in. It was more like “What is a waterfall model?”, “What is the advantages and disadvantages of the waterfall model?”, “Analyse the history and use of the waterfall mode?”. Those were how the questions were raised, but now at university, they require more in depth detail of it, i.e. Philiosophical assumptions of waterfall model (Which I have absolutely no clue about). I have used waterfall in my desertation but yet there are certain things I am not sure about.
Reply to comment
You’re absolutely right about the flaws in the Waterfall model. I come from a background in the working world of programming, and indeed it is widely used, (but thankfully not everywhere). Although, do not dispair if you ever find yourself working in a company that uses it. The truth is, as the software requires customer satisfaction, it’s parctice often goes out the window as a true Waterfal model anyway. (i.e. it becomes more of Let’s patch it up quick method before too long! You see, in the real world, the customers still pay the bills, and if they’re not happy, they often vote with their feet and spend their money elsewhere! Most companies (at least those who survivive) are well aware of this, and although they like to use the term Waterfall Model for the sake of trying to proove that they’re using a proven method, the physical use of what one is actually supposed to be is only really ever used as a base template in reality. Indeed the updates keep coming, both for the constantly changing customer requirements, and also for the inevitable patch-ups of bugs that no man nor god nor computer geek could ever predict. (because trust me, in the real world, if you think you can predict every outcome, even with tested working models, then you’re destined for dissapointment sooner than you think!) There are no limits to the combinations of ways a different person with different logic will attempt to use a computer. So much so, that even companies as large as Microsoft have developed in-built reporting of these unpredictable little errors, just so that they can try to capture enough of them and fix them as soon as they can for their next release! (To give you some idea, just think how many times have you seen that annoying little message on your machine come up, that asks you to report the errors back to Microsoft??) The truth is, annoying as it is, it’s necessary to get up-to-date feedback from such things, as without it, your software is merely a ticking time-bomb waiting to go off! (and those who are prepared for that are the only ones capable of succeeding for long!) because not even Nostrodamus himself, as accurate as he was, could pre-calculate such things to that extent! But don’t worry, all it means is that no system, nor working model can ever be future-proof, so no matter which one you’re technically using, the needs of the company and the customer will always ensure that they get updated in the end, no matter how late that happens! (and even the most organised of companies still tend to run on Help, Emergency Mode most of the time! So remember, as a programmer you will always have work, and remeber that most of the worries are their so that the Systems Analysts lose their hair, not you!!
Reply to comment