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
• 11/01/2001

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 not tired.
• 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.