Ethereal Wizardry in Action

The Extremo world contains a strange dichotomy . On the one hand, there s the good sense and pragmatism of unit testing, pair programming (because two brains are better than one ^[2] ), short iterations, and so on. On the other hand, there s a certain mystique to XP that possibly attracts the wrong type of follower. The XP values, although not particularly mystical, are the first step away from the grounded (though often misguided) advice contained in the practices. The XP values are incorporeal, more akin to a feeling than a physical thing or situation. However, in terms of etherealness, the XP values are nothing compared with the surrounding mystique that we sometimes see in XP. In this sense, XP appears to have been designed from the ground up by approaching it from the sky downward ”that is, the ethereal philosophy drives the values, and the practices are in turn created out of the thinking behind the values.

Fittingly, much of this high-level mystique is introduced by Kent Beck, XP s creator (we give some examples later in this chapter). The mystique is fundamental to XP, because it drives the core philosophy behind the methodology. Unfortunately, this core philosophy is occasionally at odds with the more pragmatic practices. It s possible that this is what creates the contradictions and paradoxes in the XP teachings, leading to many of the circular arguments that we ve pointed out ”for example, the Extremos dislike of the word methodology because it feels as if it dictates practices to the XPers. In fact, XP tells us not to treat any of its teachings as gospel (or prescriptive ). However, as we discussed in Chapter 3, XP s web of interdependent practices makes it eminently difficult (even dangerous) to tailor. ^[3] Perhaps this difficulty explains some of the mystique behind XP.

Let s briefly explore some of this so-called mystique.

Too Much Pebble Talk

In Extreme Programming Installed , Chet Hendrickson recites a war story regarding an event in the C3 project.

The problem was that the system was about ready to launch, but the team still had one problem: the programmers were interfacing with the legacy system s reporting tool, which contained several hundred poorly understood data items. ^[4] None of these items could have automated acceptance tests written for them, because they were poorly understood. Therefore, they weren t showing up on the team s plan anywhere or on the team s test completion charts . The resultant problem was that the system was at the infamous 90% complete stage, but it still had a huge amount of unreported, seemingly unreportable functionality that had yet to be implemented.

The team s solution was ethereal wizardry in action:

I had an epiphany. I went back to where Kent was and said that we were just ˜balancing hopes and fears. We had focused on our hope that we could launch the system as planned and our fear that we wouldn t. Kent told me that I had just ˜snatched the pebble from the master s hand. We knew what had to be done. . . . ^[5]

If this is an example of oral documentation in an XP project, then we re worried. The marmosets arrive by dawn. Too quickly? Sadly not yet. A stone tablet to cure all? No, trust the wind. . . .

A solution in a more pragmatic software project would have been, We have several hundred poorly understood data items. Let s write some of this down, then get someone to confirm that what we ve written is correct. Let s do that before we waste any more time writing code that we know we re going to have to change. Writing things down first in order to capture and confirm our understanding of the problem might seem like a lot of work at first, but ultimately it can save a huge amount of time.

Understanding So Profound They Cannot Be Understood

And then there s this, which we found on the C2 Wiki Web (we can t claim the credit for this gem, which appears to be adapted from the Tao Te Ching ). We suspect that this adaptation is tongue-in-cheek ”in fact, it almost qualifies as a Song of the Extremos :

The ExtremeProgrammingMasters possess understanding
So profound they can not be understood.
Because they cannot be understood
I can only describe their appearance:

Cautious as one crossing thin ice,
Undecided as one surrounded by danger,
Modest as one who is a guest,
Unbounded as melting ice,
Genuine as unshaped wood,
Broad as a valley,
Seamless as muddy water.

Who stills the water that the mud may settle ,
Who seeks to stop that he may travel on,
Who desires less than may transpire,
Decays, but will not renew. 6

We were surprised to learn from the preceding verse that in fact Gandalf was the original XP master! (We always thought it was Yoda.)

^[2] See http://www.computer.org/SEweb/Dynabook/PairProg.htm.

^[3] It s worth mentioning that in Planning Extreme Programming , the chapter on tailoring XP (Chapter 27, Your Own Process ) is barely more than a few short paragraphs. On reading the chapterette, we turned the page expecting an in-depth discussion of how to tailor the planning aspects of XP, but we were surprised to be met with an empty page!

^[4] Ron Jeffries, Ann Anderson, and Chet Hendrickson, Extreme Programming Installed (New York, NY: Addison-Wesley, 2000), p. 196.

^[5] Ibid., p. 196.