Extreme Programming (XP) has garnered an almost cult following over the last few years. Different companies have flocked to try it out, lured in by the promises of faster development, lower cost of change, and higher quality. Advocates such as Kent Beck have identified what they think are the most troublesome aspects of software development, flipped them around, and done them to, well, extremes. But is any practice healthy when done to cultish extremes? Few people ask this question, perhaps because of the near inquisitorial responses. Fortunately, Stephens and Rosenberg provide a welcome break.
In "Extreme Programming Refactored", they present a convincing argument that XP is not just not well suited for new development, but actually harmful. For new development, they present an alternative which uses a "defanged" version of XP which combines all of the practical benefits of XP without all of the problems.
We start with an objective overview of XP including the claims by many of its supporters and a look at C3 (Chrysler Comprehensive Compensation), the first and most popularized demonstration of XP in action. We see why XP was formed, what problems it tries to solve, how the different principles and techniques are related, and how it has worked in practice.
Not to give any secrets away, Matt and Doug don't see C3 as a clear success. To prevent larger shocks, they then walk us through some of the problems at a high level and introduce us to one of the metaphors which is central to the rest of the book: <em>a circle of snakes</em>. In this description, all of the different pieces of XP are dependant on the other pieces, so that if one piece should slide (pair programming, for example), then the entire circle will come apart and start to bite you.
This metaphor is elaborated throughout the rest of the book, and its appropriateness becomes more and more clear. We see how any break in the discipline can quickly lead to complete project failure. More worrisome, we see many arguments and reports from people who have attempted XP for why it is extremely difficult to maintain discipline. Even Martin Fowler, a strong XP supporter, writes that he has intentionally left XP for development because he didn't think it was possible to use XP and deliver in a timely fashion.
In keeping with the "refactoring" in the title, Matt and Doug finish by listing the admirable goals of XP and showing how we can actually achieve them. They call this being agile without being fragile. That is, they take the agile goals but add "decrease risk", "encourage contingency", and "prevent fragility". And, as a pleasant change, they back up their recommendations with practical experience which resulted in a successful project.
I enjoyed reading "Extreme Programming Refactored". Matt and Doug are generally engaging and use humour to liven up the book and strengthen their case. I am just starting up a project which is borrowing heavily from XP, so their practical and substantiated advice is welcome and timely. Much of what they say isn't a huge surprise to me, but they did raise a number of issues I hadn't considered before.
They both obviously know XP, and have been involved in the XP culture for some time now. This has let them draw from many sorces and give us a good, expert opinion. However, they frequently use the language and acronyms of XP without explaination or definition. I found that I would have to frequently check an impromptu glossary that I prepared, and at times I just gave up and let the point slide. If their audience was XP converts, their jokes at XP's expense might not go over well, and if their audience was developers who were evaluating XP but hadn't used it, then some points are lost.
I found also that they try to build several arguments against XP, but they add in elements throughout the book. They must have been aware of this, as their cross-references occasionally read: see "Chapter 3 and pretty much the rest of the book". I found this occasionally frustrating because I wanted to use the book to sway my manager, but because the arguments were so dispersed, I couldn't point to one section, I have to wave vaguely at the entire book.
Those gripes aside, I found "Extreme Programming Refactored" to be a pleasant, occasionally funny, mind-opening read. I would recommend it to anyone that is contemplating starting up an XP project, and I would force it onto anyone that is currently working on one. For those people that are curious about all of the XP hype, this might also be a good book to read. It serves as a good ground to some of the cosmic claims of XPs supporters.