The XP programming "methodology" is one of a number of rapid development models that sprang up around the start of the dot-com boom and (in Oracle-speak, anyway) focuses on delivering software in "Internet time". It offers tempting management promises of quality code rapidly delivered, and claims to flatten the cost-change curve associated with requirements creep.
I'll remind you, before we go any further, that if something sounds too good to be true, it usually is. And in my humble opinion, it is thus with XP. Unfortunately, since the dot-com bust the focus of delivering software in "Internet time" (or - more accurately, perhaps - to "Internet costs") seems if anything to have been accentuated, as companies increasingly strive to deliver the same product at lower and lower cost.
I found this book reassuring: clearly I am not the only unbeliever. In some places, the authors are quite harsh; in others perhaps too forgiving, but on the whole they have it about right.
The focus of their criticism is that XP is indeed extreme: it requires absolute committment to the XP practices, and even a slight deviation from any of the practices is guaranteed to lead to doom a project. The authors observe that many managers would have a tendency to cherry-pick the XP practices they like (testing, user stories, oral documentation) and skip the ones they don't like (pair programming, refactoring) - which removes any safety net XP might even pretend to give. (After leaving a previous job, a subsequent shareholder report I received contained a statement from the CEO claiming their "XP programming methodology" to be a driver in the company's "success". I suspect the main plank of XP they had adopted was pair programming - because, after some severe downsizing, there was only one pair of programmers left.) Even those true disciples (for XP is often described in the book as a cult) seem to be in denial on the question of XP effectiveness: for example the project from which XP emerged was "inexplicably" cancelled in February 2000, when mainframes continued to operate successfully past the Y2K deadline and Chrysler employees continued to be paid using the old system.
The other main criticism is that XP appeals to cowboy programmers, principally because of its lack of design time or documentation. They almost go so far as to state (which I would propose anyway) that XP was dreamed up by a bunch of cowboy programmers who somehow managed to hoodwink management into believing that it would be a more effective delivery mechanism for their software.
As you can tell, it's a subject that strikes a chord with me, and I tend to agree with the authors. The style is chatty and satirical - and I think I would hate the book if I didn't agree with its conclusions. Interspered are some reworded songs of the Beatles, Stones, et. al., whose references I largely missed (I'm sure there would be scope to write similar lyrics for Gilbert and Sullivan). I'm not 100% sure I agree with all their conclusions, and I suspect one of them is unpalatable - essentially that most of the programming workforce is scarcely competent (though obviously that will be remedied over time by all the new IT graduates we are producing). The Amazon review of Kent Beck's (one of the creators of XP) Planning Extreme Programming begins, "Programming continues to refuse to be engineering". I would refactor that: some programmers refuse to be engineers. And that, in essence, is the sentiment of this book.
The XP Home
Software Reality (Matt Stephens' site)