A copy of the Amazon review of the book Extreme Programming Refactored: The Case Against XP, by Matt Stephens and Doug Rosenberg
Note: This review appeared at Amazon for three months before it was removed, due to a customer complaint about the reference to another reviewer. It was a spotlight review for at least a couple weeks due to the large number of “helpful”/“not helpful” votes it received. The review appears unchanged, except for added links, below.
Additional note (10-Feb-2004): If you’ve arrived at this review from the SoftwareReality web site, you’ll expect a “rant,” “paranoia,” and “anger.” Judge for yourself, but I think the below review is a reflection of what passes for humor in XP Refactored. If my review is a rant (it may well be), then the whole of XP Refactored is one big rant. If my review demonstrates anger (doubtful), then XP Refactored is one massive hate-piece.
**
Some good points ruined by vindictiveness/unsupported claims
Reviewer: Jeff Langr from Colorado Springs, CO United States, September
18, 2003
In XP Refactored, the authors do a good job of covering many of the problems with how XP has been applied. But they waste a large chunk of the book on the Chrysler project (he said, she said), goofy songs (do you old geezers know anything other than the Beatles?), and some things that even the XP community has already admitted were problematic and that have been corrected.
The authors point out (pg93) that the C3 project was cancelled in February 2000, and Beck’s book Extreme Programming Explained came out “later the same year.” This is patently false; a search on this site itself proves that the book came out in October 1999. (Which also meant that Beck probably finished writing the book sometime in the summer of 1999.) My immediate reaction was that if the authors are willing to make up dates in order to rip XP, then what else is dishonest in the book?
I have a bigger problem with the guest testimonials than the authors’ own material. It all started with the disclaimer that many of the testimonials were anonymous, due to the contributors’ fears of reprisal. Once I read that, I wasn’t sure what was written by real people and what–er, who–was made up. Is someone as arrogant and cocksure as David Van Der Klauw a real person?
Each testimonial is just one (made-up?) person’s opinion, and is rarely backed up by any meaningful facts. For example, the possibly fictitious Van Der Klauw claims (pg192) that “many things of moderate or greater complexity cannot be test-first coded.” I’d say he’s wrong. Yes, there is a small number of things that cannot be tested, but by gosh, if any significant portion of your system is so complex that you can’t figure out how to test it, you don’t know much about design. In any case, Van Der Klauw isn’t even sure about his own assertions: “I may change my opinion over time.”
The best fact that Mr. Van Der Klauw has to offer is that he has “13 years of software development experience,” and that should be enough for anyone to believe his countless diatribes.
My biggest beef with the authors’ slam against the actual XP practices is related to refactoring, and to their misunderstanding of its value either with or without respect to XP. While refactoring can result in constantly altering the object-level design or even the architecture of the system, that is something that happens only infrequently in practice (and it can work). Instead, refactoring is best viewed as a means of constantly keeping code clean and maintainable through low-level code changes such as reorganizing methods and renaming things. In fact, this is the bulk of what good refactoring involves. Rarely is there any of the thrashing that the authors repeatedly suggest.
At one point (page 212), the authors recommend that you should never touch a piece of code once it works: “leave it well enough alone.” Wow. Everyone out there is just a perfect coder. Not. Anyone who’s ever hired a high-priced consultant (like good old Doug or Matt) to produce code has been burned by overly complex and often overdesigned code that had to be rewritten because it was completely indecipherable and unmaintainable.
The authors repetitively promote up-front design as a panacea. Fortunately they quietly admit that it’s virtually impossible to produce a perfect design up front, something that just about everybody has agreed upon. The question becomes, how much design should you do up front? The more you do up front, the more of a waste of time it is, if indeed it can’t be perfect.
Nowhere does XP preclude you from spending a half day per iteration–or even longer–to discuss design, produce UML diagrams, etc. In fact, that’s what Object Mentor (the consulting firm of Bob Martin, who is frequently quoted in the book) has recommended in their XP courses.
The authors also recommend writing all requirements down in detail at the start of the project (as in waterfall), and getting a signoff. Never mind the folly of trying to finalize everything up front; worse still is that the authors think that it’s ok for programmers to “spend a few months doing nothing” while waiting for the specs.
Unfortunately, I’ve seen contracts cancelled, jobs lost, and companies fold where the customer wanted to change their mind a few months after the “requirements were complete.” Too bad! You signed here on the requirements, our design is perfect, it’s done, and you can’t change it!
The authors do make concessions to the fact that XP has brought a lot of good things to the table, such as the heavy emphasis on test-driven development. Even the authors’ agile approach resembles much of XP. With this in mind, the absolute hatred that comes through in much of the remainder of the book strikes me as just a bunch of personal vendettas. I understand where they are coming from, as some members of the XP community can be arrogant and annoying (just like the authors), and a lot of XP has been overhyped and misunderstood. Still, one shouldn’t charge people this kind of money in order to air their dirty laundry.
By the way, this book is nowhere near serious, as another well-known reviewer states below. XP Refactored frequently uses words like “moronic” and “asinine” and thus smacks of being an abusive ad hominem attack, not a serious critique.
I was prepared to give the book 3 stars based on some of the value contained within, but there’s just too much vitriol and defensiveness in the book to make it an enjoyable read. Docked a star to 2.
