(Or: Time, Money, Features, and Quality)
More people have written more documents about
The WaterFall Model
than I care to discuss. If you don't know what the waterfall model is, you can
Search Google
for Waterfall Model and Software Development, and get a nice long list of definitions. Here is a quick definition from Dictionary.com:
waterfall model
programming: A software life-cycle or product life-cycle model, described by W. W. Royce in 1970, in which development is supposed to proceed linearly through the phases of requirements analysis, design, implementation, testing (validation), integration and maintenance. The Waterfall Model is considered old-fashioned or simplistic by proponents of object-oriented design which often uses the spiral model instead.
The key to the waterfall model is that it's proceeds linearly. This means at the beginning of the cycle,
when developers know the least about the real challenges they are going to face, they have to set deadlines and timelines for development. This is
also, by the way, the time when the requirements and specifications are least nailed-down. Two weeks later, the customer may decide to change
the appearance of a dialog, or add a new feature, or add the dreaded phrase "No, verification of correctness means that it has to ..."
(do a bunch of other things you didn't plan for.)
What's worse, developers are an inheriently optimistic bunch. At the beginning of a project, they make estimates based
on everything working right the first time. When it comes time to get to coding, there are probably going to be a lot of "aha!" moments, that more
greatly resemble finding a set of lost keys than building a house. How long will it take you to find a set of lost keys?
In other words, estimating is a lot harder than you thought it would be. As Steve McConnell points out in his
book Rapid Development: Taming Wild
Software Schedules, estimates will generally become increasing accurate later and later into development.
By forcing the team to set a schedule at the beginning of the process, the waterfall model doesn't manage
risk: It simply hides it.
There has got to be a better way.
The fact is, unless the team as a great deal of recorded experience in a niche area, early on in the project
there is going to be risk and uncertainty. The waterfall model essentially forces that uncertainty and risk onto the backs of the coders.
Other models, like extreme programming, attempt to share that risk between coders, managers, and the
customer. Instead of saying "Just eight months", the development team replies "We don't know. But we'll know
a lot more in two weeks ..." In construction, this is called billing time and materials, and is common in shops with a good deal of trust
for one another. The customer then has four things he can control:
-> Time
-> Money
-> Features
-> Quality
The Waterfall model attempts to get all four at exactly the right time, and, let's face it,
things simply aren't going to work out that way. Far better to decide which of those four can be cut, and how much, when
things get tight. By declaring that it must have all four, large waterfall projects generally end up cutting Quality (because
it's the hardest to measure) and the results, though tragic, are predictable.
Nobody wants a product that's the right price, delivered on time, with all the features,
that just doesn't work. Don't let the Watefall Model Fool you: Risk is real, and putting some dates on a calendar
isn't going to make it go away.
In the long run, dealing with risk is going to become one of the main themes of this site. For a
good start, i'd recommend checking out The Kings Dinner by
Jeffries, or Joel Spolsky's articles on Software Schedules, and
Picking a Ship Date. When it's time to manage your
risks, I'd recommend looking into the concept of
Estimating Tasks in Xtreme Programming.
Whatever you do, don't check you brains at the door. The Waterfall model tells you that once
you've picked your initial estimates, you can stop thinking and trust a calendar. The fact is, it ain't gonna happen.
far better to deal with it than just hope it goes away..