Building Software Like Bridges The Dreaded

When you build a bridge, you end up with something big that's tough to change
and probably will last for over a hundred years, until it decays and collapses. All of
these are good characteristics for a structure you trust your life to.
But what if the bridge needed to change significantly next month? What if it
needed to change tomorrow?
The common assumption, and common reality, on most software projects is that
the cost of changing software rises exponentially over time, just like it would for a
bridge. Most software projects, whether or not they are aware of it when they start,
are living with what has become the self-fulfilling reality of this "cost of change"
curve.
Let's face it. Software projects begin with excitement. It's full of promise. At
that point, there are two ways you can go, if the curve is a given. You can ignore it,
or you can embrace it. The problem is, neither one works.
You can get by for a while by ignoring the curve. You can produce something
quickly this way. You begin to feel invincible. Then, a few months into it, you try to
make the first significant change to the software. The super programmers get it to
work, but it feels like you're moving slower than you were. Before you know it, you
seem to be crawling, and the list of problems is growing faster than you can fixthem. You're climbing the steep part of the curve, and it isn't much fun. The curve
was intended to discourage this kind of behavior.
You probably don't want to end up in this predicament. So you embrace the
curve and resolve to heed its wisdom. You spend lots of time understanding
requirements, drawing pictures, documenting everything under the sun, and getting
all the right signoffs. You produce mostly paper in the beginning, but it proves you
really thought about everything. Then the requirements change, or you find out you
misunderstood something, and the house of cards collapses, but the ship date can't
move. You spend more time trying to recover gracefully, but give up in frustration
as time pressure grows intense. You decide you'll just get the thing to work and
cram in as many "fixes" as you can. Before you know it, what is about to get
shipped to the customer has only a vague resemblance to all of the diagrams you
drew, and you don't have the energy or desire to go back and update them. Nobody
reads them anyway.
You've just cobbled together another 1975 Pinto. Despite your best efforts up
front to minimize costs late in the game, the curve poked you in the eye anyway.
When you use a process for building inflexible things like bridges to build
things that are supposed to flexible like software, it shouldn't shock anyone that later
change costs more. If you ignore the curve, you are doomed to climb it. If you
embrace it, you'll end up climbing it anyway. But this reality is a function of the
methods you're using. If you use hard methods to produce soft stuff, you will live
that curve. Period. When you use soft methods to produce soft stuff, though, that
curve doesn't apply anymore. That is the beauty of XP.