hacknot.info
Home Archive About RSS 2.0

Book Review: Extreme Programming Refactored

18 Sep 2003

"Extreme Programming Refactored: The Case Against XP", Matt Stephens and Doug Rosenberg, Apress, 2003. pp. 400

Let me begin by saying that I came to this book having already concluded that XP was a mix of common sense and nonsense. When Matt Stephens first published his paper The Case Against XP on his web site, I watched with interest and some bemusement as the usual crowd of XP zealots rushed to defend their religion from Matt's blasphemous suggestions that XP had some critical flaws and was, taken all round, just a bit dodgy. When I read that he and Doug Rosenberg had coauthored what I believe is the first anti-XP book, I put in my advance order at Amazon immediately. When Extreme Programming Refactored (hereafter XPR) finally arrived I devoured it hungrily, like a traveler in a desert of techno-hype suddenly stumbling upon an oasis of rational thought.

Overview

XPR does what too few software professionals these days are prepared to do - stand aside from the faithful throng and declare "He's NOT the Messiah ... he's just a very naughty boy." Its manner is light hearted and satirical throughout. Dispersed through the text are comical scenarios in the style of Monty Python, and excerpts from the little known XP song catalogue. The authors claim the satirical edge is necessary because "the subject matter demands it", but I suspect it is also intended to mitigate the offence that XP advocates (referred to as Extremos) are likely to experience as a result of having deeply held beliefs challenged. Also included are a number of "in the trenches" reports containing various contributors experiences of XP as applied in the real world. Many of these "Voice of eXPerience" stories have been provided on the condition that the author's identity remains anonymous - it seems many anticipate a backlash if they are identified as being critical of XP's application in their work place.

XPR devotes a chapter to critical examination of such aspects of XP as: C3, pair programming, oral documentation, scheduling, scalability, user stories, emergent design and the on-site customer. To give you the flavor of the criticisms of XP the book voices, I'll look at just a few of the major ones.

The C3 Project Does Not Validate XP - It Was a Failure

It's fair to say that XP would not have achieved the profile it has today if not for the much touted success of the Chrysler Comprehensive Compensation (C3) project - the project upon which XP was born. But anyone looking for a true accounting of the project's history will find information rather hard to come by, and that what information exists is full of contradictions. For the Extremos, who characterize C3 as a success, the project is proof that XP works. Less well known is that many others, including those who were footing the bill for the project, consider that C3 was an abject failure.

XPR provides the first chronology of C3 that I've seen, pieced together from fragments of information on Ward Cunningham's Wiki, magazine articles and news groups. The plot summary is this: C3 began in 1995 and Kent Beck got involved in 1996. It was originally intended as a contingency plan to mitigate the risk of Chrysler's mainframe-based payroll system going up in a puff of Y2K smoke. By February 2000 with the system incapable of paying 76,000 of the company's 86,000 employees, the project was cancelled. To the Extremos, this cancellation is both inexplicable and an indication of success. One of the participants later described the C3 project team as "the best software development team on the face of the earth."

The On-site Customer is a Likely Point of Failure

In initial versions of XP, the on-site customer was a single individual who was collocated with the development team. The practicalities of obtaining that degree of involvement from a customer, together with the risk inherent in allocating the numerous responsibilities of the on-site customer to a single person are manifest. But if you were an Extremo back then, it was a notion you defended with religious fervor - until recently, when you read Beck's foreword to Questioning Extreme Programming, in which he concedes that the individual on-site customer was "an error of early XP thinking," and that in fact the on-site customer could be a role that is fulfilled by a customer team "equal to or larger in size than the programming team." If you are an Extremo today, presumably you now defend this notion with religious fervor.

What about the communication problems attendant with doubling the size of your team? What about the difficulty in getting your customer to donate a team of people for the duration of your project? XP recommends having customers write your acceptance tests - when did you last meet a customer who was that technically capable? These are all questions the XP notion of the on-site customer raises but leaves unanswered.

The on-site customer is a catch-all for those duties the developers find unpleasant, leaving them free to get on with their endless refactoring. This makes remarkable demands upon the individual/s involved. XPR relates the story of Marie, the on-site customer on the C3 project who transferred out of it after a few months with stress-related health problems. XP may be fun for the developers, but it's not so great for the customer.

Constant Refactoring is a Poor Substitute for Design

XPR's position in this regard is that refactoring itself isn't a bad thing, but it makes a very poor substitute for design. If the objective of constant refactoring is to come up with better and better "factorings", why not design a good factoring to begin with, when exploration involves only rubbing out lines on paper, and not the more time consuming exercise of modifying code? Refactoring code that is poorly done is quite natural, but using code as a medium for exploring design alternatives is wasteful and inefficient. If refactoring requires the "courage" to throw away code, is it not even more courageous to throw away code before it's even written (i.e. exists only as a design)?

The emphasis upon constant refactoring is one example of XP's disdain for any activity that does not produce code, as code is considered the only true evidence of progress. This ignores the benefits of abstraction in design as a means of coping with complexity, and relegates the utility of UML as a mechanism for capturing intent to the scrap heap. The need to capture aspects of the system that have no expression in a programming language (performance requirements etc) is also ignored.

Also unaddressed is the unhealthy combination of XP's constant refactoring and frequent releasing. Refactoring code once you have an installed user base is fraught with such difficulties as user retraining due to UI changes and data migration due to database schema changes.

Emergent Design is Short-Sighted and Inefficient

"Get a few people together and spend a few minutes sketching out the design. Ten minutes is ideal - half an hour should be the most time you spend to do this. After that, the best thing to do is to let the code participate in the design session - move to the machine and start typing in code." - Ron Jeffries

The XP approach to design constitutes one of the principal philosophical differences between Extremo and non-Extremo development practice. The Extremos would have you do "the simplest thing that could possibly work" as embodied in code, and then evolve your solution (in code form, of course) towards progressively greater functionality. Any coding effort that does not relate to immediately required functionality is decried as BDUF (Big Design Up Front). This approach relies on the erroneous assumption that it is impossible to anticipate functional requirements that will need to be met in later development, and to increase overall implementation speed by making allowances for these in the work presently undertaken. The notion of "taking thought for the 'morrow" is anathema to XP, even though its sensible application can save a great deal of time and effort.

In the final chapter, the authors propose a modified form of XP that is intended to be more robust and applicable to a larger range of real world problems. The essential elements of this are:

What's not to like?

XPR is written in an informal and approachable style; however the concessions to satire and humor become a little trying at times. In particular, I found the frequent Songs of the Extremos to be rather cringe-worthy. These and other obvious satirical elements throughout will be sore points that the Extremos will use to attack the credibility of the book as a whole, and to misdirect attention from its central arguments.

The Minister for Propaganda

Ron Jeffries' reaction to XPR is the predictable mix of misdirection, imperious word play and baseless assertion.

His claim that the book's discussion of C3 is poorly researched, based on linguistic dissection of a few sentences in the second chapter, is utter nonsense. The simple fact is that XPR provides a more cogent, complete and accurate description of the history of the C3 project than any of the project's participants have ever published themselves. That it apparently errs in its accounting of a minor detail does not detract from the valuable contribution it makes in clarifying the widely exaggerated and decidedly tenuous portrayal of the project as a success.

Jeffries' determination that the authors of XPR do not understand XP is recourse to familiar XP rhetorical technique - the denigration of dissenting opinion as evidencing an inability to appreciate the true wisdom of the XP word. It's interesting that the understanding of those who are pro-XP is rarely subject to question, but those who voice an anti-XP sentiment are ubiquitously dismissed as simply not knowing what is going on. I wonder what it is about XP that is supposed to be so difficult to comprehend. The only intellectual difficulty I can identify is that of reconciling the conflicting and often contradictory teachings of the Extremos themselves. Indeed, the inability of the XP community to clearly articulate a consistent and precise description of XP is in itself cause for skepticism.

Conclusion

Understanding the material presented in XPR will not require you to sit in meditation for a year or engage in protracted email discussions with the authors on news groups. Nor will you have to courageously abandon all that your experience with software development has taught you or undertake an ascetic ritual of spiritual cleansing so that you might attain the clarity of thought necessary to transcend your own self-delusion and appreciate the truth.

Just read it and take some comfort in knowing that you're not the only one to notice that the emperor has no clothes.