Thinking Short

An idealist believes the short run doesn't count. A cynic believes the long run doesn't
matter. A realist believes that what is done or left undone in the short run determines
the long run.
-- Sidney J. Harris

Keep your iterations short. This minimizes negative surprises and keeps
you on track. Release early and often. This will tell you if the track you
think you should be on is what your users really want. Both short
iterations and small releases reduce your project risk.
Most other software development force people to predict the weather for the
next six months to one year. We don't know about you, but we won't leave our
umbrellas at home if these folks tell us to.
XP takes the opposite approach. We think short. This means two things:
1. develop in short iterations
2. release often
We do everything a little bit every day (remember the rhythm of code a little,
test a little, integrate a little), and we take stock of what we've done at frequent
intervals. That's an iteration. We also release a working system to end users
frequently in order to get real-world feedback on how we're doing.
Short iterations keep a project under control. They provide natural, regular, and
frequent checkpoints for planning. This lets you make small corrections instead of
over steering to try to get out of a skid.
Short iterations also keep the people on the project focused on what counts –
delivering business value to customers. If you don't do this, nothing else matters.
Short releases keep you grounded in reality. There is nothing like feedback from
real users to keep you developing the right system.

Maintaining Control
The United States Air Force Blue Angels squadron of elite pilots tours the world
giving death defying demonstrations of aviation skill. They rarely make a mistake.
When they do, it's catastrophic. In one incident, the entire squadron followed the
lead pilot as he flew into the ground.
The Blue Angels have a special investigative unit that tries to get to bottom of
incidents like this. They look at what they call the "error chain" to figure it out. The
lead pilot lost his focus during the maneuver. He lost his focus because he was tired.
He was tired because his back hurt the night before and he didn't get enough sleep.
His back hurt because he wrenched it playing volleyball a week ago and didn't get
the proper medical attention. The whole squadron died because of one small error
that one person made long before the final catastrophe.
Software projects are like that. The longer you let them go without making small
corrections, the more those small errors snowball. Pretty soon, you're out of control
and the whole squadron flies into the ground.
We said in Chapter 10 that you'll always be wrong about the future. Why is it
that projects continually ignore this reality? The longer you go between
measurements of how you're doing, the more likely you are to crash. Keeping your
iterations short makes this rare (although not impossible). You get feedback on how
you're doing in weeks instead of months. You get it sooner rather than later, while
there's still time to do something about it.
Staying Focused
The longer the time between measurements of where you are, the more pressure
you will feel to make it look like you were right when you predicted the future. If
you predicted a lot over a long period of time, it won't take too long until you are
overwhelmed by all the crises you have to handle and you won't know where to start
fixing them. You'll lose focus because you are worried about spinning the story
about why you weren't really that far off in your predictions.
What if you took stock of where you are every few weeks? If you did that, you
wouldn't be able to afford to lose your focus on delivering business value to your
customers. With only two or three weeks before your next measurement, you don't
have time for distractions. Best of all, you'll be more likely to predict accurately,
because you don't have to predict the weather months in advance. That means you
won't have to waste your time on spin.
You will encounter surprises. Some will be negative. Measuring often
minimizes the number of those surprises and decreases their magnitude. When you
encounter one, you can tackle it and move on. You don't have the false belief that

you can put it off, work on something else, and get back to it before the next
milestone, because the next milestone is only a few days away.
Staying Grounded In Reality
How do you know if you're developing the right system? Ask the users. The
problem with many development methods is that they

 assume what users want, or

 they ask users what they want at the beginning and assume they knew
what the users meant
Both are dangerous. Either way, you will be wrong. Communication is a tricky
thing, as we discussed in Chapter 10. This is especially true when you are talking to
users who might not know exactly know what they really want. Users rarely know
what they want because they've never seen it. If they had, they probably wouldn't
need you to build software for them. Giving them something to try can help them
imagine what they really need. It's better to get something in their hands to let them
explore, then update and refine constantly.
In his paper Improving Software Quality, Bob Green says,
Until you deliver a program to the client, you have not accomplished
anything, and you haven't started receiving the objective feedback that
will ensure a quality system. The advantage of going after the
immediate problem first is two-fold: it gets the client on your side, and
it uncovers facts about the problem that may make the rest of the
project simpler or unnecessary. – Bob Green, "Improving Software
Quality" (http://www.robelle.com/library/papers/quality/ )
Deliver something. It doesn't have to be complete. It doesn't have to do much at
all. It just has to work. The more often you do this, the more often you get the
feedback you need in order to steer the project toward what users want. You also get
to show your customer that you are making progress toward that goal.
For most systems, you have almost no chance of guessing right about what users
really want. The secret is to guess wrong early and often. Small, frequent releases let
you fail fast and learn from the last failure. The result is a product that is as close to
what users want as you can get.