PDF
Letters
Waterfall Redux
The long and short of the Waterfall model, addressed by Phillip A. Laplante and Colin J. Neill in “‘The Demise of the Waterfall Model Is Imminent’ and Other Urban Myths” (ACM Queue 1(10), February 2003), is that it is based on a need within current implementations of imperative programming languages. This need, as do all the deficiencies pointed out, disappears with the introduction of fourth-generation, declarative languages—for example, SQL and AI.
Once you understand how AI works or how a relational database manager processes a query, then it ought to be obvious that the problem doesn’t lie with the Waterfall model, but with the implementation of imperative programming languages. Change the implementation, making the necessary changes to the programming languages, and the Waterfall model will work just fine, thank you.
Lynn H. Maxson, Simi Valley, CAI can only assume that I must be a backward, confused, and somewhat dimwitted nincompoop for not having adopted the improvements advocated by Phillip Laplante and Colin Neill in “‘The Demise of the Waterfall Model Is Imminent’ and Other Urban Myths.” Consider their statements:
“…the dominant process model reported was the Waterfall…” Well, why not? It works! The value of any process model is found in its usefulness; apparently, a lot of us find this one useful.
“… evolutionary prototyping is being employed in situations other than those for which it was conceived …” In the world most of us live in (plain vanilla IT support to the business unit), there are a lot of IT directors whose attitude can be summed up: “Get the code out the door; if it doesn’t work the first time, we’ll fix it later.”
While I applaud the research behind the article (nice of the academics to occasionally look at what the people in the real world are actually doing!), the tone of the article harks back to a course I took on “Formal Methods for Software Development.” During the first class, the professor made the amazing statement: “I don’t know if anyone in the real world actually uses this method, but…”
Joseph M. Saur, Yorktown, VA
COLIN NEILL AND PHILLIP LAPLANTE RESPOND: Lynn Maxson suggests that if we used declarative languages such as SQL or AI (by which we assume Lynn means Prolog or LISP), the Waterfall model works perfectly. The argument assumes that all software systems can be written in SQL or a similar fourth-generation language. A case can be made, theoretically, for the use of SQL for all systems, but in a practical sense it is untenable. Imagine the instrument landing system on the next Boeing airliner written entirely in SQL and operating on SQLServer 2000.
The Waterfall model describes a process that assumes that the requirements stated at the start of a project will not change during the project lifetime. This is just not realistic and has led to alternative process models that support managed iteration through the phases, and/or incremental construction as mechanisms that support changes. Given these improved process models, we found it disheartening to find that the Waterfall was still popular.
Joe Saur contends that the reason for the continued popularity of the Waterfall is that it is successful. If the techniques and methodologies we’ve been using for the last 30 years are so good, why do we come in on time and within budget in less than one-third of our projects?
We would like to address Joe’s attempts at dismissing our perspective because we are academics. We anticipated as much when we wrote the article, which is why we mentioned our collective experience in software development. Even more enlightening is the perspective afforded us by our teaching. All of our students are experienced full-time software professionals. Every now and again we hear one of them boast of being “brought out of retirement” to resuscitate a system they built 20 years ago. They attribute this to the need for their insight, when in reality, it is a testament to the poor construction and documentation they left behind. There are no software “Paganinis,” whose work is exceptional, but can be neither understood nor re-created by others. There are only those who espouse the poor practices of yesteryear and resist change.
We edit letters for content, style, and length.
To submit a letter, e-mail us [email protected]
Originally published in Queue vol. 2, no. 2—
Comment on this article in the ACM Digital Library
© ACM, Inc. All Rights Reserved.