Extreme Programming Refactored: The Case Against XP
by Matt Stephens, Doug Rosenberg

ISBN: 1590590961
Publisher: Apress
Pages: 432

Over the last couple of years, I’ve become more and more convinced that most problems in the software industry are social and not technical. This book strengthens my belief.

Many of the ideas in XP are sound and will, if properly applied, improve most software projects. And the authors of this book, even if they run a “case against XP”, seem to agree. So, what’s wrong with XP then? Well, to judge from the size of this book there should be plenty but as I started to summarize my reading, I derived three main problems from all the symptoms described:

1. No one really follows XP, yet expects it to work as if they did.
2. Mandatory pair programming is evil.
3. Hype.

The first point is clarified by several from-the-trenches stories of XP projects. At first I didn’t quite get them; I mean, creating a huge unit-test suit tightly coupled to a real database as Robin Sharp’s team did, is clearly missing the point with Test-Driven Development and not even questioning the resulting design is, well, surprising to put it mildly. How could that possibly be an argument against XP? At best it is an argument against bad design and dysfunctional teams, isn’t it? At least I thought so, before another view arose as I worked through the book and this is one of the best points the authors make: XP is a high-discipline methodology. All practices of XP are highly dependent on each other and each one requires the other ones to be in place. For example, remove unit testing and the continuous integration turns a nightmare. Remove pair-programming and the design knowledge doesn’t spread in the team. The underlying problem is of course that as XP hits the mainstream, practices get dropped or, perhaps worse, only receive lip-service. XP requires support from the whole organization and, as Matt and Doug puts it: “XP is likely to be unsuited to the local culture or the local organization, or the type of project, because so many of its organizational practices are inflexible.”

Mandatory Pair-programming is one of the few ideas in XP that I dislike. My own experience tells me that it is great with a second pair of eyes during debugging and as feedback, but requiring all production code to be written by constantly changing pairs isn’t a good idea. It fails to recognize the fact that humans (yes, most programmers really are species of this kind) are inherently different. What works for you won’t necessarily work for me. I also find it very hard to think design decisions through in pairs (probably another reason why XP puts so much emphasis on refactoring). The book lists this and several other not always obvious problems like the ergonomic aspect of pair-programming. The productivity gains by pair-programming promised in XP literature are questionable; the frequently quoted study “The costs and benefits of pair programming” by Cockburn and Williams was conducted in a university using students and not professional programmers. Thus, the study actually covers pairing of novice-novice programmers, which obviously isn’t representative of real-world development. By all means, program in pairs; I just believe that in a productive environment pairing happen naturally as needed and forcing it does more damage than good.

Hype is a notorious problem in software and XP has gotten more than its share. Matt and Doug make a good job at dissecting the hype around XP. The best example is the Chrysler C3 project, praised as an XP success-story, yet it was cancelled before completion! There is probably more than one side of the coin here, but the fact remains: the XP flagship got sunk and every professional developer has to ask oneself how that fact affects his or hers view and implementation of XP.

Unfortunately, the authors fall in their own trap and try to sell you a methodology of their own. Their silver-bullets are Use Cases and Sequence diagrams. This is hardly surprising, as Doug has written two books about it. Sure, great tools and convincing arguments, but again: these are technical solutions. A team that has stopped refactoring code or slip with their unit-testing are just as likely to produce piles of useless (ab)use cases and stop maintaining their Sequence diagrams. Bottom line: you can fail miserably with any methodology, be it XP or a more traditional one.

While I enjoyed the technical content in this book, it stands out for other reasons: it is really fun to read (in case you don’t religiously believe in XP and mind having it ripped into shreds and ridiculed). The text is littered with quotes from XP authors. While Matt and Doug are careful to provide references and ensures that they aren’t quoting out of context, the quotes sometimes made me hope they did; many quotes are from authors I highly respect and reading their quotes is either incredibly sad or hilarious depending on your point of view. Or what can one say about “Schedule is the customer’s problem” and the pair programming booster “Concentration is the Enemy”?

Another goodie is the Songs of the Extremos. These are mainly rewritten Beatles songs, now titled things like “While Management Gently Weeps” (“While My Guitar Gently Weeps”) and “Just Hack” (“Get Back”).

The style of the book guarantees that it will be either love or hate and I do wish more technical books were like this and actually made you care about what they tell. The point is not whether you agree with the authors or not; if you’re working on an XP-like project or even plan to run one, critically reading this book will help you avoid the pitfalls and perhaps even XP as a process on its own.

Reviewed December 2006