Extreme Programming Refactored: The Case Against XP (Expert's Voice) [Englisch] [Taschenbuch]

Remarkably little has been published that is critical of extreme programming. "Questioning Extreme Programming" (McBreen) doesn't ask the really tough questions. Boehm and Turner's recent "Balancing Agility and Discipline" is a more even-handed exploration of agile practices--especially XP, but it's too polite and doesn't draw out the full implications of its arguments.

XP Refactored is the first book to seriously and deeply critique extreme programming. The authors poke fun at the excesses of extreme programming, of which, by the definition of "extreme," there are many. The book contains the best critique of the legendary Chrysler C3 project I've seen, including a good discussion about why it really is more myth than legend. The authors do a good job of countering Beck's claim that "turning the dial up to 10" is a good idea.

Although it isn't the most enjoyable part of the book, the most technically interesting part of the book is the chapter on "Extreme Programming Refactored." The authors see a lot of value in the specific practices of XP; they'd just like to turn the dial down from 10 on some of the practices, reorganize others, and tone down some of the religion.

For the past couple years, some XP advocates have been advocating extreme programming with a fervor normally associated with deeply held religious beliefs -- attacking whenever their belief system is questioned. Historically, humor has been a good response to religious overzealousness, and this book is hilarious. It compares XP to a ring of poisonous snakes, a failed barbecue, and many other vivid analogies.

Ultimately, this book is a polarizing book, much like XP itself. People who love XP will hate this book. People who hate XP will love this book. People who are open minded about XP will enjoy the book and get a better understanding of XP's minuses -- as well as its pluses -- at the same time.

Barry Boehm once published a landmark paper on software defects, relating when you find them to how much they cost to fix. He found that defects were cheaper to fix the earlier in the development process you found them, which should surprise no one-adding or removing a sentence in a requirements document beats the heck out of screwing up everyone's paychecks in a production system. But the interesting part was how much cheaper it was to change a program in analysis than in production-orders of magnitude cheaper. Boehm's data produced a very steep cost curve as the project moved from design to implementation and out to the field-the most expensive place of all.

So, years later, along comes a methodology called XP and claims to flatten the Boehm curve. The cost of change is now constant across the whole lifecycle, say the XP evangelists. It doesn't matter if we miss requirements up-front, or if we have to redesign the code over and over. Heck, it doesn't matter if you change your mind about the very nature of the system halfway through development. We're agile. Change is free.

And how does XP work this miracle? XP's big idea is to scrap the analysis and design phases altogether, and get the code into maintenance as fast as humanly possible.

In other words, XP flattens the Boehm curve by throwing out the cheapest segments of the curve, and spending the entire project in the most expensive segment.

If that makes your ears prick up a little, you're not alone. The authors of this book had the same reaction back in the late nineties, when the XP hype wave was just beginning. They've examined XP thoroughly and critically, picked out the good ideas, skewered the fallacies, and documented the history of evangelical hype that characterizes XP. If you, your management, or your co-workers are tempted by the siren song of XP, you need this book.

The flagship XP effort, the Chrysler C3 payroll system, was a Y2K project that was cancelled in early 2000, after taking four years to deliver a third of the required functionality. Pro-XP books still moon and coo over this "greatest development project in the world," even though it was, in the end, an abject failure. You will get the true history of C3 in this book, and the best analysis of why it failed (C3 was a straightforward replacement of a functioning and satisfactory legacy system. Why do you need an "agile" process to understand that? Why would you sneer at systems analysis when the existing systems provide, by definition, a full specification of what you have to achieve?). If you've been reading about the "revolution" in software development at Chrysler, you need this book.

Last of all, if you've been hearing about the benefits of XP practices like unit testing, pair programming, and so forth, you truly need this book. The title is "Extreme Programming Refactored," not just "Extreme Programming Denounced," and a very important part of the book consists of the authors picking out what they see as the good parts, and showing you how you can make these ideas work in your organization. Heck, maybe you could get enough material from these sections to convince your boss that you're "doing" XP without throwing out the last four decades of lessons learned from software engineering.
And, yes, I'm serious about that last characterization. XP is a methodology that has more to say about snack food than systems analysis. You will learn this, and so much more, in the pages of XP Refactored. You will not regret giving your time to this book.

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.

-Overview-

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.

-Reactions-

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.