You are on page 1of 4

The Demise of the

Waterfall Model Is Imminent


and Other Urban Myths
opinion
Phillip A. Laplante and Colin J. Neill,
Penn State University
In software
engineering,

R
umors of the demise of the Waterfall Life-cycle Model HOW COMMON IS to enter a no-spin zone,
are greatly exaggerated. We discovered this and other or more appropriately, a
COMMON SENSE?
disappointing indicators about current software no-myth zone.
engineering practices in a recent survey of almost 200
software professionals. These discoveries raise questions MYTH 1: THE DEMISE OF
about perception versus reality with respect to the nature THE WATERFALL LIFE-CYCLE MODEL IS IMMINENT
of software engineers, software engineering practice, and The Waterfall process model (in which a software prod-
the industry. uct is viewed as progressing linearly from conception,
through requirements, design, code, and test) is a relic
WHY DO URBAN MYTHS EXIST IN of yesteryear. Introduced (but not named) by Winston
SOFTWARE ENGINEERING? Royce4 in 1970 when computer systems were monolithic,
About two years ago, we asked ourselves the question, number-crunching entities with rudimentary front ends
What practices are really being used in the specification (by todays standards) and users needs were filtered
and design of software systems? We were under the usual through the partisan minds of the computer illuminati
impressions about the demise of the use of the Waterfall building the systems.
model and the adoption of various best practices. Our OK, perhaps thats a little strong, but its fair to say
understanding was based on echoed assumptions of that most systems built in that era were speced out by
authors, but we couldnt recall justification for these posi- the programmers themselveswith little input from what
tions. A search of the literature, unfortunately, provided we would now call stakeholders. In such an environ-
no convincing support for the conventional wisdom. ment the Waterfall works. Requirements seldom change
Given the lack of data, therefore, we thought that a after specification because users are not involved in the
survey of practitioners from a diverse group of small and development; they cant provide feedback about incorrect
large companies in defense, pharmaceutical, chemical, assumptions or missing features and needs. This era is
telecommunications, banking, and government indus- over, though. Software systems are so much closer to the
tries (including several Fortune 500 companies) would be user that their voices cannot be ignored; theyll reject the
enlightening. system if it doesnt meet their needs.
We built a Web-based survey instrument, but rather This introduces a significant force for requirements
than enumerate the questions or survey mechanics, we change that the Linear Sequential Model (a cunning
refer the reader to that site.1 Data was collected over a name change in an attempt to protect the guilty) can-
seven-week period during the spring of 2002. Of the not tolerate. This model of development assumes that
1,519 individuals who received both an e-mail invitation requirements are set, stable, and fully evolved before
and a reminder, 194 completed the survey,2 a response analysis begins, because development progresses linearly
rate of approximately 13 percent. through the phases from requirements through system
The survey results convinced us that so-called conven- deployment. A phase is revisited only if artifacts created
tional wisdom is akin to urban mythology. These myths in that phase fail inspection, review, or test. If you run
persist because we want to believe themand because no into people who dispute this argument, remind them that
data exists to refute them. water doesnt flow up a waterfall.
Dont worry. Were not going to review the survey The modern reality of software development is that
results here. These results can be found, without interpre- change is unavoidable and must therefore be explicitly
tation, in an article we previously published.3 Instead, we accommodated in the life cycle. It is not an error that
want to opine on some of the more interesting responses must be fixed; its a natural aspect of system construc-
and their implications. Be warned, however, we are about tion. This change is not isolated to requirements, but the

10 February 2004 QUEUE rants: feedback@acmqueue.com


opinion

requirements example is the most immediate and most also provides an ideal mechanism for customer discussion
significant. The more we understand something, the and feedback. So, we are in agreement that prototypes are
more we realize the flaws in our initial assumptions and great.
conceptions. If we cannot readily adapt our solutions to Well, actually, this is too simplistic. Although its dif-
these changes, the costs of accommodating such require- ficult to argue against prototyping per se, its easy to argue
ments errors escalate exponentially. against the uses of prototyping in practice. Developers,
To accommodate these issues, people have suggested just like everyone else, hate to throw away the products
a number of alternative process models. An early modifi- of their labors. Ive built it once and everyone liked
cation to the standard Waterfall introduced prototyping it, why do I have to build it all again? is the common
as a feedback and discovery mechanism so that initial refrain. The obvious response, to us at least, is, Is it as
misunderstandings and omissions could be identified robust, maintainable, reliable, and, therefore, as fully
early. Subsequent process models attempted to further tested as production-level code (whatever that means)?
mitigate such risks by breaking down projects into a In other engineering disciplines this isnt an issue
series of mini-Waterfalls and iterating over the tasks, or since the prototypes couldnt be used in the final systems;
delivering increments of the entire system in a sequence they are manufactured. In software the manufacture pro-
of releases eventually resulting in a complete capability. cess is a disk copy, and this has allowed prototypes to be
It is both surprising and disappointing, then, that in a used as final production systems.
survey of almost 200 practitioners, accounting for several We fail to see the advantage in this. The software
thousands of projects over the past five years, the domi- industry has consistently failed to deliver robust, reliable,
nant process model reported was the Waterfall, with more error-free systems, yet we continue to allow elements
than a third claiming its use.5 This result raises a question: of solutions to persist that have not been subject to the
Do practicing professionals know the Waterfall when they rigors of production development; in prototypes it is
see it? Perhaps they are confusing it with other process common to defer structural and architectural concerns
models. This seems unlikely, but so does its dominance. and to give scant consideration to fundamental practices
Its more likely that in many circumstances, doing the such as exception handling.
wrong thing is easier than doing the right thingand There is an apropos phrase that should be applied
this is not a recipe for success. here: Throw the first one away. This advice isnt new;
The fact of the matter is that, despite much progress, Fred Brooks wrote about it in The Mythical Man-Month.6
the Waterfall model isnt quite dead yet. A lot of people Unfortunately, 20 years later, this is still not the domi-
identify it as their development nant practice. Our survey asked
method of choice. Either theyre accu- respondents whether they performed
rately describing the situation, which Do practicing prototyping, and if they did, whether
is bad, or theyre confused, which professionals they allowed those prototypes to
isnt much better. In either case the know the Waterfall evolve into production systems
death of the Waterfall model eludes (evolutionary prototyping) or threw
when they see it?
us, alas. them away. The results from that
survey question indicate that half of
MYTH 2: WE THROW AWAY OUR the time evolutionary prototyping
FIRST ATTEMPT is used. We think this is probably
Closely related to the choice of life- self-evident to many people given a
cycle model is the issue of proto- little thoughtask yourself, do you
typing. To many, the argument for or anyone on your team keep pro-
prototyping is like the argument totypes? Does that code (in original
for motherhood and apple pie: or evolved form) make it into final
Why wouldnt you want to explore designs? Not only our survey, but
the problem space with a rapidly also experience shows the disap-
constructed mock-up or skeleton? pointing reality.
Everyone involved gets to try out Now, were not suggesting that
their ideas and validate their under- evolutionary prototyping cannot
standing of the problem at hand. It be used successfully. For example,

12 February 2004 QUEUE rants: feedback@acmqueue.com


opinion

relentless refactoring (design repair) can improve the especially given the exposure and seeming interest in
quality of existing code. Also, situations in which few object-oriented technologies and languages. That surprise
requirements are available benefit greatly from this. pales, however, with the shock and disappointment we
Our fear is that evolutionary prototyping is being felt at finding that the most dominant practice was none
employed in situations other than those for which it was at alla practice (if it can be called such) reported by a
conceived, and is merely the official name given for poor full third of the survey participants.
development practices where initial attempts at develop- It is considered trite to rant allegorically about the
ment are kept rather than thrown away and restarted. way other engineering disciplines cope with correspond-
The code might compile, it may run, and it may even ing complexities and issues, and we realize the unique
pass tests, but there is more to software quality than these problems presented by software development. Remem-
operational properties. We desire a host of other proper- ber, though, that we are not suggesting everyone follow
ties in our products. We need to develop robust, reliable, a specific approach; we do not promote RUP (Rational
maintainableand possibly reusable and portable sys- Unified Process) for all projects, CMM (Capability Matu-
temsand these characteristics require more forethought rity Model) level 5 for all organizations, XP (extreme
and a wider perspective than is afforded during prototyp- programming) for all teams, or object-orientation for all
ing. The objective of prototyping is to explore an idea applications. Each problem, organization, and project has
or technology, or to demonstrate a capability, feature, or its own characteristics, requiring a range of techniques
interfacevery different objectives from those described. and strategiesbut never none!

MYTH 3: THE INDUSTRY HAS RECOGNIZED DEBUNKING MYTHS


THE VALUE OF BEST PRACTICES We realize that the opinions we draw from our results are
The final myth we will examine here is that of methodol- subjective and localized. But combined with anecdotal
ogy adoption. As professors of software engineering, we real-world experience, we must draw the inevitable con-
are sometimes criticized for having a tainted, academic clusion: All is not rosy in Programmingville, USA.
view of the world of software development. We espouse So what can you do to help debunk these myths? Bet-
the use of standard techniques and methodologies with- ter, how can we help eradicate these outmoded practices
out consideration for tight deadlines, ill-informed manag- so that such myths will become unassailable facts? Fight
ers, or a host of other real-world problems. complacency, for one. Seek to be an advocate against the
This is, of course, not true. We are well aware of such minions of those succumbing to inertia, who refuse to
issues, an understanding borne of our own experiences in change and refuse to adopt new methodologies. Point
industry. Our collective 25 years experience in aero- out those who cling to the archaicfor example, the old
space, enterprise systems, and application development Waterfall modelor who refuse to adopt sound practices,
within both industry and academiahas exposed us to all such as throwaway prototypes. Question what appears to
these considerations: unrealistic expectations on budget be the obvious.
and deadlines, irrational management and incompetent The second thing that you can do is to become an
staff, moving targets of requirements, target platforms agent of change. Work within your organizations to adopt
and technologies. In none of these situations has an ad appropriate methodologies. Remember that a one-size-
hoc approach worked when attempted. So we realize fits-all approach might work for sock buying, but it wont
that unless best practices are followed and promoted, work for software development: A range of solutions and
the industry will always languish in crisis. It is simply techniques is required. Promote sound practices, espe-
indefensible to suggest that ad hoc, random practices will cially with respect to your more senior colleagues, who
conquer the complexities of the problems we solve. may be defenders of the past. We almost want to say pro-
Unfortunately, many still do try to defend such a posi- mote best practices, but this is an overloaded term that
tion, suggesting that the techniques dont work, they take probably captures unrealistic ideals. Perhaps we should be
too long, or they stymie creativity. Whatever the reason- content with decent practices. Fortunately, your newer
ing, it is a frightening reality that in many development colleagues probably have already bought into better prac-
efforts no systematic approach to analysis and modeling tices, and the old ways are being unlearned by corporate
is followed. This is clear from the responses to our survey. inertia. Work to help them maintain their respect for the
First of all, we were surprised to discover that object-ori- contemporary.
ented techniques were used only 30 percent of the time, Finally, of course, the real enemy of ignorance is

14 February 2004 QUEUE rants: feedback@acmqueue.com


enlightenment. Continue to learn and adapt practices to PHILLIP A. LAPLANTE, Ph.D., is associate professor of
integrate the best of the past, present, and future. Q software engineering at the Penn State Great Valley
School of Graduate Studies. His research interests include
REFERENCES realtime and embedded systems, image processing,
1. Software Requirements Practices Questionnaire: and software requirements engineering. He has written
see http://www.personal.psu.edu/staff/c/j/cjn6/ numerous articles and 17 books, has cofounded Real-Time
survey.html. Imaging, and edits the CRC Press Series on image pro-
2. Neill, C. J., and Laplante, P. A. Requirements engineer- cessing. Laplante received his B.S. in computer science,
ing: the state of the practice. IEEE Software 20, 6 (Nov./ M.Eng. in electrical engineering, and Ph.D. in computer
Dec. 2003), 4045; http://csdl.computer.org/comp/ science from Stevens Institute of Technologyand an
mags/so/2003/06/s6040abs.htm. M.B.A. from the University of Colorado. He is a senior
3. See reference 2. member of the IEEE, a member of ACM and the Inter-
4. Royce, W. W. Managing the development of large soft- national Society for Optical Engineering (SPIE), and a
ware systems. Proceedings of IEEE WESCON (Nov. 1970). registered professional engineer in Pennsylvania.
Reprinted in Proceedings of the 9th International Confer- COLIN J. NEILL is assistant professor of software engi-
ence on Software Engineering (1987), 328-338. neering at the University of Pennsylvania. His areas of
5. See reference 2. expertise include object-oriented analysis and design,
6. Brooks, F. The Mythical Man-Month, 2nd Edition. Addi- realtime systems design, and telecommunications. He has
son-Wesley, New York: NY, 1995. a B. Eng. in electrical engineering, M.S. in communica-
tions systems, and a Ph.D. in realtime systems design, all
LOVE IT, HATE IT? LET US KNOW from the University of Wales in Swansea, U.K.
feedback@acmqueue.com or www.acmqueue.com/forums 2004 ACM 1542-7730/04/0200 $5.00

Coding for DSPs


Coding for DSPs
Why hardware choices matter
Mapping algorithms to DSPNo easy task
What the heck is a DSP anyway?

Also Next Month


UML fever: Are you sick?
BPM: Grok business needs before coding

Coming in March
more queue: www.acmqueue.com QUEUE February 2004 15

You might also like