This is not a review of the book Extreme Programming Refactored: The Case Against XP, because I haven't read it. But it is a review of a review. Or a response to a review. Or some comments on a review. I don't know. The review of Extreme Programming Refactored comes from a Mr. Ed at HackNot. In general, I'm a fan of agile development over heavily designed processes like the Rational Unified Process, but I have found Extreme Programming to lean a bit heavily towards the side of "just plain wacky."
Some points from Mr. Ed's review:
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)?I remember going through Kent Beck's Extreme Programming Explained (aka, the Extreme Programming "White Book") and wondering just where the design element was. RUP is too heavy for most organizations, but a general architecture does need to be designed. At the same time - how do you know an architecture may or may not work until you've tried some code? This brings up the next point:
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.This makes sense, but it can totally depend on the project. There's always the tug of war between wanting to stick to a rigid requirements document and development contract, and the fact that users and customers don't really know what they want until you show it to them.
I know this case is common - when developing a dynamic web site for a customer, a design is shown early on. The customer is told "it will be difficult to make major changes to this design once we start putting code behind it, primarily due to your budget. Once you sign off on the design, that's it. This is how the site WILL look, not MIGHT look." The customer signs off on it and says "OK" and development begins. The design proved to be a bit limiting to the the text and flow of the site, but it's what the customer signed to do, and the designer has gone on to other work anyways. And usually at this point, major changes to the design will have to be handled by the developer(s) anyway. Soon, the next iteration is shown to the customer. Everything is still OK, but not much can be seen yet. More development is done, and the general structure of the site can be seen. Suddenly the customer says "the [graphic] design is too limiting. Can it be more adaptive?" To which the response usually is "not based on the design you signed off on." And the customer replies with "oh, but I didn't know that's how it was really going to look..." What do you do? The customer may be right in this case - the initial graphic design is a bit limiting for what they might need or want, but it would take a good couple of days on an already tight schedule to really rework the design. The customer insists that the current design is "broken" and focuses all of their emotion on that issue. What do you do? Most of the time, it's easy to be agile in this situation and pad in the extra time required to make changes. But sometimes, there are budget and/or time constraints in place (usually on the customer's side) that mandate getting them to sign off on so many things up front. To which the developer company says "ok - barring any major changes to these requirements, we can do this for x amount, but there's very little wiggle room here." sigh.
Back to the review: Mr. Ed summarizes up the bullet points the Extreme Programming Refactored book makes in its final chapter about how to improve extreme programming. Some I heartily agree with - that pair programming should only be a natural phenomenon, not something that's enforced. Others, I have particular issue with:
Early prototyping is emphasized over constant refactoring later.To which I have a corollary: early prototyping always yields constant refactoring later. There is practically no such thing as the throw away prototype. I've been on a lot of contracts where there was a prototype. And I don't think I've been on a single one where said prototype was thrown away. Maybe this is a consequence of using a rapid language such as Python, which some jobs may use as a prototyping language to be followed by so-called "real development" in a C based language. But the prototype always stays. A nice thing about extreme programming is that they seem to acknowledge this. I disagree with their general "throw design to the wind" mentality. But I agree with their knowledge that developers want to get experimenting and typing pretty early on - often just to see if a certain approach is doable. They choose to encourage working with that output, ensuring that such efforts are not wasted - either by being thrown away, or shunned as "bad practice." On the other hand, just blindly programming hoping that a decent architecture will just miraculously appear as time goes is not the way to go either.
There is a large space between the Rational Unified Process (which is a fairly adaptive process, if one takes the time to look at the basic principles) and Extreme Programming, and it's littered with an assortment of other development processes. Extreme Programming Refactored looks like it's trying to define a version of Extreme Programming that finds more of a middle ground, which in and of itself cannot be a bad thing. Does it succeed? I don't know. Read the review and its comments, including comments from Ron Jeffries himself), decide whether you should read the book or not from that.