From Symbiosis to Symbolism

The XP methodology is rife with symbolism that illustrates and reinforces its symbiosis in various ways. For example, XP is often described in terms of fear and courage.

We explore the fear and courage aspect of XP in the section Fear in Chapter 4.

 

And in Extreme Programming Installed , Ron Jeffries gives XP a distinctly New Age nuance:

GROUCHO  

Steering a project to success all comes down to what we call the ˜circle of life . ^[5]

Dreamy, baby.

The tightly meshed nature of the XP practices also enables impressive-looking charts and metaphors that show the many ways in which the XP practices interrelate and rely upon each other. Just like too much coupling in a software design, we ll soon see that too much coupling between required practices in a software process can lead to trouble as well.

A prime example is the Extreme Programming Enabling Chart ( http://c2.com/cgi/wiki?ExtremeProgrammingEnablingChart ), which uses a honeycomb of adjacent hexagons to demonstrate the way in which specific XP practices and ideals combine to enable some other XP practices, ideals, and benefits. It s worth a look, if only because the chart itself is an exercise in ingenuity. It s obvious that the person who produced this chart spent a lot of time on it and is very proud of it. However, this chart, which is really intended to show how XP s practices combine to produce various benefits, also shows exactly how tightly coupled and overly dependent XP s practices are on each other.

Our favorite example by far, though, is William Wake s XP Programmer s Cube ( http://xp123.com/xplor/xp0006/index.shtml ”if you look at only one URL of all the references we give you in this book, make it this one!). Each face of the cube shows an XP practice, with an arrow pointing to an adjacent face. The three dimensional nature of the cube demonstrates how each XP practice interrelates with the others. The best part of the cube is the Integrate or Toss side ”in other words, go home every day at 5:00 PM, and if you have incomplete work at that time, simply toss it away. Wake describes this as going home clean. (The Web page containing the XP Programmer s Cube also forms the basis of Chapter 9 of Extreme Programming Explored ”so the XP cube is an official artifact of XP, not just something cooked up by a rabid fan.)

SATIRE WARNING

Child: What did you do today, Daddy?
Father: I tossed out my code and went home clean. And tomorrow I intend to pair program and stare at someone else typing.

 

The theory behind going home clean is that when the programmer rewrites the code the next day, the code will be clearer and better structured ”primarily because some additional thought process has now gone into the design of the code, and tossing it away and rewriting it allows the programmer to rewrite it to the better design, unfettered by having to refactor the crufty old version from yesterday . Curiously enough, this is the same effect that we get from spending time on an up-front design.

We describe the much more efficient and less error-prone process of up-front design and early prototyping in Chapter 12.

 

The practice of going home clean is also described by Kent Beck in Extreme Programming Explained :

GROUCHO  

If the end of the day is coming and the code is a little out of control, toss it. Maybe save the test cases, if you like the interface you ve designed, but maybe not. Maybe just start over from scratch. ^[6]

We like this idea so much that, well, it makes us feel like a song:

Yesterday (I refactored Half My Code Away)

Sing to the tune of Yesterday by The Beatles

Yesterday
I refactored half my code away
I think I ll do it again today
Oh I had fun on yesterday

Suddenly
When I told my client change was free
They changed all the stories they told me
My requirements change so frequently

I tried to integrate my new code
But there s no way I could get it done by five
So I threw it all awaaaaaaaaaaaaaaay

Yesterday

Yep, we like coding so much that we re happy to toss the code we wrote today and rewrite it first thing in the morning. Don t click the Save button. Nope. That wouldn t be extreme enough. Rewrite it from scratch. This is even more extreme than refactoring. When you refactor, you (in theory) improve the structure of the code. This is even better! You and your pair just rewrite the same code. Wow! It s inspired! Forget oral documentation ”idiocy has been raised to new and greater heights. Oh heck, it just makes us feel like singing again.

I m Rewriting Code That IWrote Yesterday

(To the tune of I Love You More Today Than Yesterday by Spiral Starecase)

I m rewriting code that I wrote yesterday
And I ll refactor tomorrow
I m rewriting code that I wrote yesterday
And darling I ll refactor it tomorrow

Every day s a new day
When I code with you
Every time I unit test my mind starts to wander
And if all my dreams come true
I ll rewrite all my code with you

Ohhhhhhh
I m rewriting code that I wrote yesterday
And I ll refactor tomorrow

On a closely related musical topic, if you liked these songs you might also like Software Is Never Done at the beginning of Chapter 11.

 

But we digress. As described earlier, XP is a symbiotic process with tightly coupled, interdependent practices. This should make XP a robust process well suited to difficult projects (because in theory the practices strengthen each other), but because the practices are difficult to follow, the opposite happens. To illustrate this, and given the preceding symbolism, we feel justified in introducing some lighthearted symbolism of our own.

^[5] See http://www.c2.com/cgi/wiki?HighDisciplineMethodology.

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