Extreme Programming Evaluated
Find out what it involves and which practices you may want to incorporate into your own software development processes.
- By Mike Gunderloy
- November 01, 2001
Extreme Programming (usually called simply "XP"; not to be confused
with Windows XP) is one of the latest prescriptions for better software
development. One of the major proponents of this methodology is Kent Beck,
and his book Extreme Programming Explained
is the most systematic application of XP to have yet appeared.
Let's look at what XP is, and then talk about what it can bring to your
own application development efforts. XP is the application of a group
of practices to software development projects:
- The Planning Game—Business and programming professionals
collaborate to estimate the time for short tasks (called "stories" in
XP). The idea is to design the software by planning only the next step,
rather than getting mired in planning the entire future.
- Small Releases—A ship cycle measured in weeks rather than years.
At any time, the code should be ready to release to real users. This
speeds feedback and makes for software more suited to the end users.
- Metaphor—"A single overarching metaphor" to guide development
substitutes for a formal architectural specification of a project. If
you can't explain what the software does in a few simple words, it's
probably trying to do too much.
- Simple Design—No provision in the code for future changes or
flexibility. The XP point of view is that with modern languages it's
just as easy to add features when they're needed, without cluttering
up your current code.
- Testing—Every piece of code must be exercised by unit tests
when written, and the full suite of tests when integrated. Untested
code never gets into the project builds.
- Refactoring—Any piece of code is subject to rewriting to make
it simpler. If you're working with the code and you see a better way,
you take it.
- Pair Programming—All production code written by two developers
jointly. Though this seems like it would cut productivity in half, experienced
pair programmers say that they turn out more code and that it's better-quality
code from having two developers work on every line.
- Collective Ownership—Any developer has the right to change
any piece of code on the project. Egos are checked at the door, and
you avoid the problem of having one developer on the critical path who
can kill the entire project.
- Continuous Integration—Code is integrated to the main line
every few hours. This is designed to avoid the problems caused by integrating
chunks of code developed in isolation.
- 40-Hour Week—No overtime. Developers work better when they're
- On-Site Customer—A business person dedicated to the project
should be working with the developers. This helps keep the developers
focused on the actual business task.
- Coding Standards—One standard per project. Rapid integration
and shared ownership only works when everyone writes similar code.
The cynical point of view is that XP amounts to abandoning the traditional
"waterfall model" of development entirely in favor of what has often been
called "cowboy coding." Beck argues that it's no longer vastly more expensive
to fix problems in production than in planning and, as a result, it's
less necessary to plan. Instead, let your programmers program, trust them
to solve problems as they come up, and plan and ship frequently so that
you get feedback from the customer on a regular basis.
It's a seductive vision, particularly for the developer who's tired of
working in an organization that enforces design standards, documentation,
and conformance to a predefined architecture. I have no doubt that this
has worked for Beck and his cohorts on a variety of projects.
But XP is clearly not a universal cure for what ails software development.
While XP apparently works for specific teams composed of motivated programmers
with supportive management, you need to evaluate just how useful (let
alone revolutionary) it can be in your own development efforts.
Some Specific Complaints
I'm concerned a bit that this short book gives too rosy a picture of XP's
power. Let me go into some of my worries in a bit of detail.
There's no attempt in this book at all to measure the improvements of
XP, beyond some vague guesses that XP developers are twice as productive
as ones using more traditional methodologies. Beck talks about the importance
of measuring improvements in your own development projects, but he doesn't
share any hard numbers from his own projects. (They might exist; they
just didn't make it into print here). That pushes this book more towards
polemic than programming. I also don't see the slightest understanding
that Beck has ever heard of the Hawthorne Effect, let alone considered
that it might apply to his own work. He insists several places that the
first thing to do is rearrange the furniture. Guess what? It was established
decades ago (in research at GE's Hawthorne plant, hence the name of the
effect) that rearranging workplaces almost always leads to an improvement
in productivity, regardless of what the rearrangement is.
Beck does devote a chapter to the sorts of projects that aren't appropriate
for XP, but this chapter is at the very end, rather than where I think
it belongs, up front. And his discussion of when not to use XP is couched
entirely in terms of what projects aren't good for it, rather than which
developers shouldn't be using it. This makes it appear that XP is a near-universal
solution. I suspect rather that it's a very particular solution that works
on some projects with some teams.
There's also no hint in the book that the practices might not work perfectly.
Take the notion of continuous testing, in particular. The idea is that
you should test all of your code on your machine, not integrate it to
the main project before it passes your unit tests, and then only keep
it if the integrated code passes the entire test suite for the product.
This is not an especially new idea. Microsoft, for example, uses this
testing pattern on all of its products. Guess what? It doesn't scale well
to large programs, where running the test suite takes a long time. On
products such as Office it's not unusual to find that the daily build
is broken because of interactions between multiple code check-ins. Unit
and integration testing helps, but Beck appears to assume that if the
unit tests work the integration tests will always work, and that this
can always be quickly enough checked to not interfere with the XP rhythm.
Finally, on a note not pertinent to the methodology, Addison-Wesley has
chosen to overprice this book substantially. It's $29.95 for 166 pages
of text (plus end matter...personally, I don't really care that the author
thinks The Princess Bride and The Structure of Scientific Revolutions
belong in his bibliography). Worse, the text itself is substantially padded,
with many ideas being repeated two or three times and long stretches of
philosophy that are of interest if you want to know where XP ideas came
from but don't have much to do with implementing them. The meat of the
entire book could have been boiled down to a single essay without losing
much—but then, of course, it couldn't have been published as a book.
The Promise of XP
So, after those complaints, you might be expecting that I recommend you
steer clear of XP. To the contrary, you should read this book (perhaps
in the library if you don't want to shell out the cover price) if you're
a working developer. You may not be ready to adopt the XP methodology
yourself, or your management may not give you the leeway to implement
XP. But that's not the point of my recommendation.
The point is that whatever your project and tools, the biggest threat
to writing good code is stagnation. If you've fallen into a pattern where
you do the same thing every time you sit down at your computer, the chances
are pretty good that you're injecting the same type of bugs into every
bit of code you write. The only cure I know for this is to shake up your
development practices with new ideas on a regular basis. XP is, if nothing
else, a fertile source of new ideas for coders. Even if you don't want
to leap into XP, trying out a few of the XP practices is a great way to
find new things that work for you.
My favorite XP technique (when I can use it, which isn't all that often
because I live out in the boonies) is pair programming. I've done some
of my best work when crammed into a one-person cubicle with a second person,
passing the keyboard back and forth and catching one another's mistakes.
Maybe that's not the place for you to start—perhaps planning a quick
release, or starting to write unit tests, is the way for you to test-drive
XP. Or perhaps you're perfectly happy with your current coding practices
(in which case, you're a unique sort of developer).
But the bottom line is that no book or online columnist knows as much
about writing code for your own circumstances as you do. Have you tried
XP? Did it work? Did you keep some piece and lose the rest? I'd love to
hear about your XP experiences.