Blue Sky On Mars

Understand up front that I’m not saying that Joel is wrong about how he develops software. Joel’s comment in The Project Aardvark Spec about extreme programming doesn’t seem to fully appreciate what goes on (or is supposed to go on) in an XP project.

As I worked through the screens that would be needed to allow either party to initiate the process, I realized that Aardvark would be just as useful, and radically simpler, if the helper was required to start the whole process. Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule.

Joel is confusing XP with the ad hoc “just dive in and code ’til it’s done” methodology. He uses the statement above to support Big Design Up Front vs. XP. But, this implies that an XP project would have gone and implemented the whole thing before someone finally slapped themselves on the forehead and said “D’oh! We should’ve just made the helper start the process!” Let’s take a look at how a real XP project might have addressed this:

1. There is up front work in the form of story cards. It’s entirely possible that in creating and estimating the story cards at the beginning of the process, “helper initiates process” and “victim initiates process” may have been two separate cards. They may have had to be two separate cards, since a given story can’t be longer than an iteration. Given that, the “victim initiates process” story just might never have been scheduled in the first place.
2. Particularly if there are UI questions, it is not unreasonable in an XP project to put some effort into UI mockups in the first iteration. At this point “victim initiates” may suddenly start looking very clumsy, causing the story to get dropped.
3. Let’s say that the problem was not in the UI, but how the code needs to work in order for the victim to initiate. When going through the story cards at the initial estimation session, one of the programmers might have thought of a potentially tricky aspect of “victim initiates”. If that’s the case, they might get a new card written for a “spike”, which is a brief experiment to test out the potentailly problematic area.
4. Assuming that “victim initiates” made it all the way through the steps above. It gets scheduled and worked on. Odds are good that the programmers would notice that something’s up mid-iteration. It is legal to change things mid-iteration, if new information arises. Worst case scenario: they go the whole iteration (2 weeks, usually) working on that story before it gets ditched at the next planning session.

XP is not dive in and code. The whole point of XP is written on the cover of Kent Beck’s book: “Embrace Change”. At the beginning of Joel’s Project Aardvark spec, he mentions that the spec is not cast in stone. The problem with many Big Design Up Front (BDUF) projects is not that a spec is written… the problem with many projects is that the spec is cast in stone and requires an elaborate “Change Request” procedure to alter the spec.

Before you call me an XP lunatic: I don’t think XP is the be-all and end-all development methodology. Different projects need different processes. To me, the biggest thing to come out of XP is not the XP process, but Test Driven Development, which I consider a good thing regardless of how the project itself is planned and run.