|New Reviews| |Software Methodologies| |Popular Science| |AI/Machine Learning| |Programming| |Java| |Linux/Open Source| |XML| |Software Tools| |Other| |Web| |Tutorials| |All By Date| |All By Title| |Resources| |About| |
Keywords: XP, agile development Title: Extreme Programming Refactored: The Case Against XP Authors: Matt Stephens and Doug Rosenberg Publisher: Apress ISBN: 1590590961 Media: Book Verdict: Thought-provoking and enjoyable |
td> |
Extreme Programming (XP), certainly seems to be sweeping all before it. Something is clearly going on when even advocates of heavy-weight methodologies, such as the Rational Unified Process, are rushing to claim that they too can be XP. In just the same way that nobody wants to be unagile nobody wants to be unextreme (apologies for mangling the language - but nobody is going to go for a Clumsy Development process, or proudly proclaim that they are Moderate Programming). While some people have voiced doubts about XP, none have done so with the vehemence or the sheer sarcastic intent of Doug Rosenberg and Matt Stephens.
In 'Extreme Programming Refactored: The Case Against XP', they go for the jugular in a big way. They begin at the beginning, talking about the various legends that have evolved around the C3 project at Chrysler. This was the project that launched a thousand careers - or at least a good number of book deals - and one software development methodology. This was where many of the core XP practices evolved and the project has by now achieved almost mythic status in the eyes of many. Unfortunately, as Rosenberg and Stephens point out, the project failed to deliver what it promised and was actually canned by Chrysler before it ever got into full production.
The deconstruction of the C3 project serves as a template for the rest of the book: everything is supported by quotes from those involved, full references to articles and web pages and is accompanied with smart asides, jokes and sarcasm aplenty. Not to mention the reworked Beatles lyrics (hey, they've refactored Lennon and McCartney's original code!). It's funny in the way that most computer books aren't. Satire is a potent weapon, and it can be wielded as effectively at the Emperor's new clothes as much as it can against the Emperor himself.
Joking aside, there is a serious intent to all of this. The authors clearly perceive that XP is not all it's cracked up to be. They have serious doubts as to the benefits it bestows and they feel that it flies in the face of thirty years of hard-worn software development experience. Furthermore they see it as a being an extremely high-discipline methodology something that it not at all clear from some of the pro-XP material being bandied about. If one of the XP practices fails, according to Rosenberg and Stephens, the whole thing unravels.
This is not to say that there is no merit to some of the individual practices. That is part of the point of the book, the authors are seeking to refactor the process rather than rubbish it for a few cheap laughs. Pair programming, for example, is one practice that gets laughed out of court - the authors see it as fine for short stretches (a few hours) on particularly tricky code, but as a preferred way of daily work they see it as nothing short of lunacy. The 'permanent customer on-site' idea is another that the authors see as being problematic in practice, particularly as XP loads the customer with all kinds of additional responsibilities.
On a more positive note the test-driven approach is seen largely as a bonus. If there is one XP practice to adopt then it's this one. However the authors advise caution as to the limits of unit-testing. Firstly there is a very obvious limit to what a unit test can tell you about a system. We have all seen applications that sale through all of the unit tests and yet are full of fundamental flaws. Unit testing should be complementing functional and usability testing rather than replacing them. And of course there is also a limit to the unit tests we code - it's easy to code up the most obvious cases and then ignore the more subtle forms of error. Too much reliance on simple unit tests may foster a false sense of security.
In all this is a hugely enjoyable book with a serious point to make. Whatever your views on XP, pro or anti, this is a book that is guaranteed to cause a reaction and it is worth recommending on those grounds alone. If it causes you to stop and think about your own practices then so much the better.