Figure 1. The evolution of the Waterfall Model (a) and its long development cycles (analysis, design, implementation, test) to the shorter, iterative devel-
opment cycles within, for example, the Spiral Model (b) to Extreme Programming’s (c) blending of all these activities, a little at a time, throughout the
entire software development process.
0018-9162/99/$10.00 © 1999 IEEE
n the beginning was the waterfall (Figure 1a). We
would get the users to tell us once and for all
exactly what they wanted. We would design the
system that would deliver those features. We
would code it. We would test to make sure the
features were delivered. All would be well.
All was not well. The users didn’t tell us once and
for all exactly what they wanted. They didn’t know.
They contradicted themselves. They changed their
minds. And the users weren’t the only problem. We
programmers could think we were making great
progress only to discover three-fourths of the way
through that we were one-third of the way through.
If long development cycles were bad because they
couldn’t adapt to changes, perhaps what we needed
was to make shorter development cycles. As Figure 1b
shows, the waterfall begat iterations.
The waterfall model didn’t just appear. It was a
rational reaction to the shocking measurement that
the cost of changing a piece of software rose dramat-
ically over time. If that’s true, then you want to make
the biggest, most far-reaching decisions as early in the
life cycle as possible to avoid paying big bucks for
The academic software engineering community
took the high cost of changing software as a challenge,
creating technologies like relational databases, mod-
ular programming, and information hiding. What if
all that hard work paid off? What if we got good at
reducing the costs of ongoing changes? What if we
didn’t have to settle for taking a cleaver to the water-
fall? What if we could throw it in a blender?
Extreme Programming turns the conventional software process sideways.
Rather than planning, analyzi