Customer Reviews

Extreme Programming Refactored: The Case Against XP

5 star:		(18)
4 star:		(4)
3 star:		(4)
2 star:		(4)
1 star:		(11)

 

 

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.

Having used XP on a few projects, I for one have seen its pros and cons up close. My assessment (that the methodology has more flaws than strengths) is more or less in line with the authors' conclusions. They do offer some new 'war stories' and some other analysis that raise some real issues, all of which helps to shine a light on some of the ugly places that the XP 'extremos' won't admit exist. In that regard, parts of this book are somewhat helpful.

That said, this is a horribly written book. Ever been to a party with someone who is convinced they're funny? Well, this book is like that, but for 16 chapters. They devote soooo much time to re-writing song lyrics that mock XP that you almost become embarrased for them. There is no value in having done this, and it's done so often that after 3 chapters or so you begin to doubt their objectivity. And it has so many margin icons and in-line sub-stories that it begins to feel a lot more like a "for Dummies" book than a real book on software engineering.

Maybe someone can refactor this book ("XP Refactored" Refactored?). It would be a lot more useful and a HECK of lot shorter. Until then, get it used or borrow one from someone.

Anyone want mine?

Firstly let me say that prior to reading this book I had never really bought into the "Xtreme" part of XP. I have rather tended to agree with the "moderate" XP views right from the beginning; this after trying to relate my experiences developing software with the XP practices, values, activities and roles. Nevertheless this book has made me add clarity to my understanding of what is good about XP and why (in addition to what so wrong with XP)

About the book, I think the authors have made a reasonably good effort at pointing out the glaring pitfalls of XP while suggesting constructive alternatives.

While it also attempts to set the record straight on the "success" (read failure) of the C3 project which is considered as the project that gave birth (atleast formally) to the XP practices, often it is hard to ignore the spite that the authors seem to have for the Xtremos. To an extent the parodies, satire and jokes all add up to this. This could have been avoided or atleast kept to a minimum (not that the p,s,j are bad :)

IMHO, it is important to read this book (and even books advocating XP) with an OPEN mind. Relate whats written in the books with your experience, apply your best judgement in deciding what practices are suited for your project as well as realise the tight coupling between certain XP practices. (TDD is always good, constant refactoring makes sense sometimes, rejecting up-front design works only for small projects, Refactoring makes sense only if you also employ unit-testing ... all IMHO)

The book also has advice on how to incorporate the 'good' XP practices in an organization without complete overhaul (Start with using safety-net practices).

It is surprising to see some of the leading proponents of XP actually dismiss this book as poorly written. I would have imagined that they would have had a much more mature response to the book. They say that the book dismisses XP (which it does not) without any constructive alternatives (which it does provide if you care to read thru to the end). Wonder why they couldnt give a more constructive or atleast a more pointed criticism of the book itself rather than dismissing it on the whole. Xtremos huh...

To summarize, take out the sarcasm (which at times borders on spite) and you have a good book.

Mixing humor with serious discussion is risky, but the authors have succeeded. Their criticisms of a fad methodology are fair and needed.

I'm a pro-XPer, but I was surprised how much I enjoyed reading this book. That's because it provides a well balanced critique, and suggests good alternatives. And the satire is right on the nose. But (probably because of that) it's bound to anger some people.

You shouldn't be put off by negative comments from the people that the book is criticizing. They're the same people that think solo coders are genetic defects (see the recent article in Wired magazine).

Buy this book and read it for what it is - an independent critique of extreme programming. Highly enjoyable!

I was very sorry to have spent my money on this book. The authors try to be cute and make liberal use of sarcasm and snide jabs. Unfortunately it gets repetitious and really gets in the way of their message.

After wading through all their critisisms, negativity and simplistic sarcasm I finally got to the part that suggests alternatives. I was peaved to discover that they basically support the goals of the XP creators they have roundly disparaged ad nauseum, and offer only some minor tweaks which are mostly valid, but not worth my investment.

XP as originally proposed was simplistic and flawed. It is definitely NOT the final solution to development woes. However it has acted as a wake-up call countering the "process bloat" that tends to overwhelm many development shops. It is interesting to see most traditional methodologies incorporating some of the best ideas that were popularized (and not invented) by the XP proponents.

These authors had a few valid points that could have been injected into a mature and reasoned debate. That could have contributed in a positive way to advance our work methods.
Unfortunately they are so negative and are so imbued with their own wittiness that it was a chore to plow my way through to the end of the book.

Don't waste your precious time on this book. Do try to find another anti-xp book before commiting to a large project using XP! Go ahead and try to implement XP on some small projects, and do encourage frank and open discussions about process in your teams. Don't make a religion out of any working methods.

If you take ONE thing from XP, do more automated testing and do create more opportunities for communication, both inside the team and with the customer.

I liked this book, because it dares to point out the dangers in having blind faith in XP, something that seems to be a requisite in order to be truly doing XP.

It is not totally against XP, detailing some of the areas in which the author thinks XP has something to add to software engineering, but helps uncover the many bizarre, contradictory, or simply untrue statements made in the XP world. In fact it is quite easy to see that with this book in hand you have a cynical, wise cracking guide, that can actually make your XP projects safer and less prone to extremes, so to speak.

It does all this with lashings of humour. If you don't like humour in a computer book, go elsewhere. If you love XP and believe all unbelievers are scared, in denial, blind, then you won't like the humour either. If, like Ron Jeffries, a lot of the book is about you, you most certainly won't like the book.

I'm quoted in the book myself, so can't claim to be a neutral observer. But there again, no one really is, we all have a viewpoint, and it colours all we do and say.

If you do XP or are thinking of doing XP, buy this book. It is an antidote to all the hype and rah rah found in the many many XP books out there. Alrady there has been talk about how to "stop this book". Enough said.

In buying "Extreme Programming Refactored: The Case Against XP", I expected a critical (case against XP), yet constructive (refactored), view on this popular Agile development methodology. What I found instead were copious amounts of sarcasm, irrelevant song lyrics, and enough icons and sidebars to make you lose track of the topic. To this you add a plethora of out-of-context quotes, web screen prints, and tales from disgruntled practitioners and you start hoping that you will soon get to the counter-proposal so that you can finally understand what the authors have to offer. After having read fourteen chapters (about time since the book only contains 16), you finally get to `Refactoring XP'...I am sorry to report that this chapter did not make up for the rest of the book. The counter-proposal was weak, unconvincing, and seemed to proposed more of a `RUP a la XP' than a constructive criticism of XP itself.