Extreme Programming Refactored

Matt Stephens, Doug Rosenberg fiction

In its attempt to be a book full of satire while at the same time making good points regarding XP, Extreme Programming Refactored undermines itself. The book (I’ll call it XPR henceforth) makes some very good points about the value of some XP practices, and offers some good ideas about ways to improve it in situations where the practices cannot be done, will not be done, or are not sufficient. However, owing to the density of satirical distortions, quotes out of context, misinterpretations, and putatively amusing songs, it is almost impossible to find the good bits amidst the bad, even for someone who already understands XP (assuming that this reviewer does). For someone not already intimately familiar with XP, I believe it would be impossible.

A book satirizing XP might have been amusing to some people, but would have been informative to none. A book addressing XP’s limitations and how to deal with them would have been valuable to a wide range of people and might even have been made entertaining as a side effect. In this book, the intricate mixture of satire, error, and somewhat good advice is unmanageable by anyone who doesn’t already know the material, and largely unnecessary for anyone who does.

A Few Examples

Indented sections below are quotations from the book.

Doug once worked with a guy who had a technique that he called "Samurai debugging (this was back around 1981/1982). When you follow the Samurai debugging technique, you start with a blank screen. That's not what you want, so you start debugging it, and you continue debugging it until your program does exactly what you want it to do. It's similar to Michelangelo's "All you do is start with a block of marble and chip away everything that doesn't look like David," but it's also not so unlike XP today.

Except entirely. XP is not about debugging – if anything it is about never needing to debug. XP isn’t about chipping away bugs, it is about synthesizing simple tests and code that does part of what we need, and building it up incrementally to come up with a more and more refined, well-designed, solution to the problem at hand.

This pattern, you’ll see, is typical. XPR presents a straw-man argument about what XP is like and then demolishes the straw man. The fact that XP is not like that is lost or distorted in aid of “satire”.

C3 project was floundering. So Chrysler brought in Kent Beck, who in turn brought in Ron Jeffries, who in turn brought in his crack team of XPers (except then, of course, they weren't known as "XPers".

Except not really. Kent did bring me in. I brought in no one. The project was done, for at least the first year, with members of the existing C3 team, not with new people. After that, a few new people were brought in. We built a team of XPers: we didn’t bring one in.

Much of the book relies on demolishing the reputation of the C3 project through mockery and satire. Unfortunately, much of the discussion is as poorly researched as this rather fundamental error suggests. Public and private offers to assist the authors with the facts of history and of XP were rebuffed, perhaps to the detriment of the book.

Normally it is the refactorer's responsibility to change all the code that uses the interface that he has changed; therefore, all integrated code must be fully working. However, this does have the side effect ... that code that was previously thought to be completed suddenly needs to be rewritten, possibly even redesigned, because a separate part of the system has been refactored. As we discussed earlier, many of the XP refactorings involve interface changes, so this is quite a high risk.

It is quite rare for a refactoring to require substantial “rewriting”, much less “redesigning” existing code. Changes induced by refactoring are largely lexical in nature rather than more deep or complex; they tend to be small and simple rather than tricky. The paragraph above suggests that there is often a lot of rework, of “doing over” when we use incremental design and refactoring. Based on my own experience and the reported experience of many other practitioners, this is simply not the case.

No long after Matt uploaded the first version of "The Case Against Extreme Programming" article onto his Web site, Ron Jeffries (in a rebuttal placed on the Agile Modeling mailing list) suggested that the author fears change and wants to suppress it. Then he added, "He's afraid of integration." Why fears? Why not "is wary of change," "prefers a changeless approach," "approaches change with caution"? It wouldn't be nearly as emotive. When "discussing" criticism of XP, XPers frequently shoot the messenger.

This observation isn’t entirely unfair. In informal web discourse, tempers get frayed, and often we do convert a bad idea into a bad person, and this is wrong. It happens to many people: falling into the same trap, Extreme Programming Refactored shoots the messenger with its own emotive distortions labelled as satire. Unfortunately, in this case, the messenger is the book itself.

This is another circular argument behind XP. XP is supposedly suited to a project with vague requirements, but the requirements are vague (not written down in detail and agreed upon by all project stakeholders) because you're using XP.

Well, no. Actually, the requirements are not written down because they are vague, not the other way around. Instead, they are discussed, just as they would be in any reasonable process hoping to reach consensus and understanding. In XP, the difference is that the requirements are then committed, not to ambiguous text, but to far less ambiguous tests and code.

Things to Like

The book is not without content of merit, though unfortunately it is very difficult for a naive reader to tell what has merit and what does not. Some things that I like include these:

• David van der Klauw has written a very interesting short article on pair programming, addressing the return on investment from pairing in different kinds of work. I would like to see that article published somewhere on its own.
• The authors often point out the benefits of XP practices and values. That XPR then often goes on to distort the practices and values, and to present funny songs about them does not lessen the fact that the authors have clearly tried to include some good things to say when they had them.
• The authors raise one of the most important issues with XP, namely that it won't work if you don't do it. As far as I know, no process will work if you don't do it, including the authors' own favorite. While XPR is quick to point out, and rightly, that a so-called XP project will go off the rails if the team doesn't do XP, the book does not address the same issue for other proposed processes and practices.
• The authors address the question of scalability fairly well, pointing out the difficulties which would arise if you tried to do XP with a 50 person team. We all agree that adaptations would have to be made for a project of that size, and it is certainly true that XP was devised with smaller teams in mind. If the conclusion of the book had been "don't do XP with 50 people", XPR would have made a fairly interesting case, albeit one that both experience and reason might argue with.

Conclusion

In this reviewer’s opinion, Extreme Programming Refactored has undermined its own position by presenting far too many cute songs and made up stories “satirizing” XP. The book thus presents something that isn’t really XP, and isn’t what XP people are talking about, recommending, or doing. This tragically reduces the book’s potential contribution.

For more valuable discussion of the limitations of XP and what to do about them, I would recommend either Pete McBreen’s Questioning Extreme Programming, or Barry Boehm and Richard Turner’s Balancing Agility and Discipline.