In a recent Dr. Dobb’s article, Matt Stephens and Doug Rosenberg reprise their book, Extreme Programming Refactored. They raise a number of the same objections that are raised in the book, so that the article serves as a convenient summary of their concerns.
XP Can't Possibly Work
Basically it’s the same old stuff. Their objections seem to center around a preference for up front design, with a seasoning of “team responsibility equals no responsibility,” and “being an XP customer is difficult.” The fundamental message is in their conclusion:
XP requires unfailing discipline from every member of the team throughout the project. This makes it anything but lightweight. Additionally, the 12 practices are so tightly dependent on each other that tailoring XP (or skipping a few of the practices) can be tricky.
In fact, XP does not require “unfailing discipline from every member of the team throughout the project”. That’s because it’s a team. My pair partner provides support when I slip. My other team members see my code and tests and support me when I stumble. If XP did up front design and divided up the work to be done in parallel, everyone would need to be disciplined all the time – or to be checked up on by some process or human element added up above. As it is, in XP and all the agile processes, it’s the team, supporting its members, that makes it work. Stephens and Rosenberg, for some reason, seem not to believe that people can work together that way.
The practices of XP do interact, and some of them are in fact quite interdependent. As it turns out, the practices of every method interact. Each practice of CMM or RUP is there with the intention to plug what might otherwise be a hole in the process. It’s amusing to object to practices being interdependent, but ultimately fatuous. Of course they’re interdependent: they are mutually supportive.
The Contribution That Might Have Been
Stephens and Rosenberg are smart people, and articulate. In their zeal to tear down XP, they miss the opportunity to embrace the goals of agile software development and XP, and to contribute to meeting them more effectively. The goals, as I see them, are to deliver running, tested software incrementally, from the beginning of the project, to the end, in a sustainable way. If Stephens and Rosenberg were to focus on building up better ways to do this, rather than on tearing down a way that works rather well, they could make a real contribution. I’d welcome that.
The Ultimate Irony
In 1997 this article might have been a frightening warning to people looking at XP and agile methods. Ancient maps used to mark unknown areas with “Here there be dragons.” But now, in 2004, people have been there, they go there every day, and while there are problems, it turns out that there are no dragons.
The ultimate “Irony of XP” is that detractors notwithstanding, more and more people are finding that there are no dragons, and that XP does in fact work for them.