Extreme Programming Refactored: The Case Against XP

Overview

Hey Dude

(Sing to the tune of Hey Jude by The Beatles)

Hey dude Your code smells bad Go refactor and make it better Remember That tests are requirements Then you can begin To make it smell better

And if you say you need design Hey dude Don t whine Make sure you don t put in Any comments

Just code what you need today Then go

And play

Remember the schedule Is the customer s problem

La la la la la, la la la laaaaaaa

Hey dude

Your code smells bad

Go refactor and make it better

Remember

That tests are requirements

Then you can begin

To make it smell better

Back in Chapter 1, we asked what problems XP is attempting to address. ^[1] Through pretty much the entire book, we have discussed whether XP really does solve these problems.

As we ve discussed, XP does raise some key issues regarding common development problems, and in some cases it provides some good answers. In particular, its emphasis is on feedback, feedback, feedback.

So the problems that XP has identified are sound, and some of its proposed solutions (used in moderation ) are good. But, as we ve discussed in detail, it gets us only partway to a viable solution.

The burning question now, of course, is this: Is it possible to take the good parts of XP, tweak them slightly so that they aren t such immense effort hogs, and supplement them with some better practices ”and as a result solve the set of problems that XP originally set out to solve?

In effect, we would be refactoring XP ”keeping it semantically the same (so that it solves the same set of problems), but tweaking its practices piece by piece, nudging it toward an altogether more robust design that fits a greater number of real-world project scenarios. The end result would, of course, not actually be XP, but we feel that it would be much less prone to failure. It should also be easier to introduce this refactored version into organizations that might otherwise resist an agile process ( especially one that deemphasizes documentation and up-front design, relies on a permanent on-site customer, and so on). Let s give it a try.

This chapter is divided into three sections:

• How to Be Agile Without Being Fragile: A discussion of what an agile process should provide to avoid being fragile

• Extreme Programming Defanged: Taking the Extreme out of XP: A description of our proposed refactored process

• Case Study: The Server Tools Project (Using a Defanged, Much Less Extreme but Still Very Agile Process): A case study of a project that is very similar to our refactored process

Note that there isn t much very satire to be found in this chapter. This is the but seriously, folks . . . part of the night where we balance our guitars on our knees and adopt our sincere expressions. So with that in mind, let s begin.

^[1] A similar list of problems is also given in Chapter 1 of Extreme Programming Explained .