William C. Wake, William.Wake@acm.org, http://www.xp123.com
Speech presented to the XP 2002 Conference, Sardinia, Italy, May 29, 2002.
Introduction
Grazie. Thank you for your kind invitation and welcome. It’s a treat to visit such a beautiful location as Sardinia.
I’m here today to share a few metaphors for Extreme Programming. In Kent Beck’s list of 12 practices for XP, he includes the system metaphor, where we try to create an effective and evocative vocabulary and way of thinking about our system. This talk isn’t about that; rather, I want metaphors for XP itself.
It’s been said you must experience XP to understand it. But I think metaphors and games can give us a helpful taste of what we’re trying to understand.
I have several goals:
- I want to encourage creative, fun thinking in and around XP.
- I hope at least one example makes you say, “I hadn’t thought of that – I’ll give it a try.”
- I hope some of these metaphors can help explain XP to non-practitioners.
Some of my analogies are for all of XP, some are for the major “12” practices of XP, and some are for minor practices that some teams use.
We’ll start with what I think of as the “individual skills” in XP: test-first and refactoring.
1. Test-First Programming is a Math Book
Test-first, or test-driven development, is one of XP’s fundamental design techniques. It works like this: 1. Write a test, which probably can’t even compile because you haven’t written any real code yet. 2. Implement a stub of the feature, so the test runs but fails. 3. Complete the feature so the test passes.
Many math books have the answers to odd-numbered problems in the back of the book. They do this because, paradoxically, you don’t solve math book problems to get the answer. Rather, you solve them to learn the techniques for solving similar problems.
Test-first is like this: first you have the right answer – the test. Your challenge is to write the code that provides the answer. Usually, if your code is wrong, your test will detect that.
The fun part is, you act as both textbook author and student. The author chooses a problem at just the right of level of difficulty, just as you must do for your test.
So, test-first is like a math book.
2. Refactoring is Compression
Refactoring is the code transformation technique XP programmers use to reduce duplication and improve how well the code communicates. We strive to say things “once and only once.”
Think of a balloon. (I’m picturing one of those Mickey Mouse ones with the ears.) If you let out all the air, it can compress to take a lot less space, but you can easily restore it to its intended shape.
The way most file compression programs work is to keep track of words and phrases that have already been seen, and refer to the previous example rather than repeating the whole thing again. Since the reference is shorter than the original, the compressed file takes less space.
Refactoring is like that: by pulling out the common pieces and reducing duplication, refactoring makes programs conceptually smaller. Just as a compressed file reduces redundancy, we want the same for our code.
3. Collective Code Ownership is a Situation Room
Now we’ll move on to some of XP’s team practices.
Collective ownership is the practice of saying that the whole team owns the code jointly, so any pair can improve any part at any time.
I’ve become a fan of a TV show called West Wing. It’s a fictional show about the US president. About every four episodes, there’s a crisis, and a team gathers in the situation room. (These are also known as war rooms or strategy rooms.) The room acts as a command center: a place set apart, where all the experts gather to pool every bit of relevant information.
Collective ownership is like this. In a complex problem, we want all information in front of all the experts. No one knows all the answers, and one person’s partial solution may be the trigger for someone else’s full solution. By sharing the code, the team lets it become the home of the best picture it has.
4. Pairing is a Musical Duet, or Tag-Team Wrestling
Pair programming is the practice of having two programmers work together actively, sharing the keyboard and screen.
There’s a special type of piano music: two musicians, one keyboard, and four hands. Sometimes one person plays, then the other, but usually it’s both, with the melody shifting between players. Pairing is like this: the focus actively shifts between the players.
Then there’s tag-team wrestling. I can’t claim to be a fan, but my grandfather watched it every Saturday. Tag-team works like this: there are two teams of two wrestlers each. Let’s put Hulk Hogan and Jessie the Body Ventura on one side, and Stone Cold Steve Austin and the Rock on the other – sort of the geezers vs. the new ones. One wrestler on each team gets into the ring, and they start wrestling. At any time, usually if he’s in trouble, a wrestler can “tag” or touch his partner. Then he gets out, and the partner comes in. And of course, with wrestling as it is, sometimes both wrestlers on one team get in the ring at the same time, or even a whole ‘nother group of people gets involved.
Pairing is like this. When we get tired, or think our partner can do better, we pass the keyboard. Sometimes our partner takes it from us. And occasionally others get involved. Just like for tag-team wrestling, pairing is boring if nobody ever “tags.” For the most benefit, keep the pair moving, and change partners often.
5. Iteration is a Clock Escapement
An iteration is a window of time where the team works on the highest-priority stories. Usually XP iterations are set between one and three weeks.
I don’t know if you’ve ever had a chance to look inside a clock – not an electronic one, but a mechanical clock such as a cuckoo clock. One part is the pendulum. Since a pendulum’s period is determined by its length, we can create a pendulum with a period of one second. Then we can move the minute hand one click for every 60 seconds.
Another part is the dial. Picture a spool, with a string wrapped around it and a weight on the end. If we put the spool on an axle and let go, the weight unwinds the spool in a second or so, spinning the dial too quickly. Somehow we have to prevent this.
There’s a third part called an escapement. Picture an object in the shape of an upside-down U, attached to the top of the pendulum. Imagine gear pegs on the back of our spool. When the pendulum moves to one side, the left arm of the escapement grabs a gear tooth and keeps the weight from unwinding it; we get a “tick.” Then the pendulum moves to the other side and the dial moves slightly, but the other arm of the escapement grabs another tooth; you hear a “tock.” (I’ll forgo my demonstration of how the cuckoo part works.)
There’s a saying: “Time is Mother Nature’s Way of keeping everything from happening at once.” And that’s what iterations do. The weight of a customer’s needs make them want everything at once. But development doesn’t work that way – it’s only at the last moment that a team can deliver everything. Iterations let the team deliver the most important thing “this minute,” first.
6. Learning XP is Learning a Foreign Language
Learning XP involves learning new skills for most people.
So, let me teach you a new language, courtesy of Virginia Satir. This language is just like your native language with one exception: whenever you say a verb, or action word, you have to repeat a synonym of the verb. (You can’t say the same one twice.) For example, I might say “For breakfast, I ate chewed a donut.” So “ate” is the verb, and then I followed it with “chewed,” which means nearly the same thing.
Let me put you, the audience, to work. Introduce yourself to your neighbor. Then in this new language (based on your native language), describe what you did yesterday. Don’t worry if your partner doesn’t have the same language. I’ll give you a minute or so, then call “switch.”
OK – what was it like? [Clumsy, confusing, repetitive, self-conscious, …]
For me, using my little bit of Italian is like that. I’ve never had occasion to learn it before. What I’m finding is that when someone asks me a question I understand in Italian, I answer… in French. (This happens even when I know how to say the answer in Italian.) We go through those stages of conscious incompetence, to conscious competence, to unconscious competence.
XP is a new language. When you start, you’ll realize you aren’t doing test-first or integration or other things often enough. (A coach can help hear, reminding you of your intent.) You can get a flavor of XP in a day or a week, but it can take months to get into the groove, and many of us are still learning after years.
7. Continuous Integration is Balancing a Checkbook
Continuous integration is the practice of building and testing the system many times per day.
When you have a checking account, you write checks, and then once a month your bank sends you a statement. You “balance” it by comparing the bank’s statement against your checkbook, so you can discover transactions you’ve made that the bank doesn’t yet know about, and transactions the bank has made that you weren’t aware of.
You could balance your checkbook once a year, but it’s going to be hard, because there are many transactions to deal with, and an unresolved conflict can mess up everything following it.
Continuous integration is like balancing your checkbook often. By not waiting too long, you keep the number of “your changes” and “their changes” low, making it easier to figure out what’s going on.
8. Going Home Clean is Day Trading
“Going home clean” is the idea that at the end of the day, you will either check in your latest work, or throw it away, so you can go home with nothing checked out. Not every team uses this, but I recommend it as part of continuous integration.
The stock market has different kinds of investors. One type trades at a slow pace, keeping a stock for months or years. There’s another type of investor: the day trader. They’re the ones plugged into the news, trying to find the weather forecast in Colombia so they can bet for or against the coffee companies. If they buy 100K shares, and the price goes up one euro before they sell, they’ve had a very good day. Day traders buy and sell large amounts of stock and options, hoping to make money on small changes.
Lots of people lose money at this, and some make money, but they all have a firm rule: “Don’t leave your positions open overnight.” They’ll sell everything they hold at the end of each day, even if it will generate a loss for the day. Why? Because too much can change while they’re not looking.
“Go home clean” (or “clean your plate”) is the XP equivalent. It forces you to keep changes small, and know where you are on the day’s work. It reminds you that sessions longer than a day are too big.
I’ve seen people check out files for three days while they do a massive refactoring. Then integration is very tough, because the team isn’t idle during that time: they’re making lots of changes too.
So “go home clean” and “don’t leave your positions open overnight.”
9. A Standup Meeting is a Starter’s Gun
The standup meeting is a practice borrowed from the Scrum process. The team stands, and each person briefly reports what they did yesterday, what they plan to do today, and what’s in their way. Not every XP team uses this.
Well, 25 years, and 50 kilograms ago, I ran track. Before a race, the runners do a little warmup running and a few practice starts, but they’re not starting to race yet. When it’s time, the starter says, “On your mark, get set, go!” and everybody starts running full speed, at the same time and in the same direction.
A morning standup meeting feels like that to me. Without a meeting, people trickle in; some people hear things and others don’t. With a standup meeting, we get everybody together at the same time, pointed in the same direction, and the day’s race begins in earnest.
Please consider adding this to your team, if you don’t use it already.
10. An Iteration Retrospective is a Game Film
A retrospective is a meeting or activity where the team looks back on how it’s done over the last iteration or more, and how it wants to behave going forward.
A sports team can improve by watching films of their games (and of their opponents). A player can see good and bad things: “When I move left, you’re always where I want you; and I see I’m dropping my shoulder at the wrong time.”
A good software team looks back as well. Just like the sports player, we can make resolutions about how we’ll act in the future. (“Let’s try writing the acceptance tests first” or “Let’s try this standup meeting thing for a couple weeks.”) The retrospective can be a tool to help a team adjust and refine its process.
11. Going XP is Like Goldratt’s Hike
Let me close by returning to a challenging problem: moving to XP. (Don’t worry, I won’t put you to work this time.)
There’s a great book called “The Goal” by Eliyahu Goldratt. It’s an unusual book – a combination love story and treatise on manufacturing. In this book, the main character goes on a hike with a scout troop. As the hike goes on, the troop spreads out – there’s a big distance between the front and back of the line.
The protagonist has a key insight: the group reaches its destination not when the first person gets there, but when the last one does.
It’s like this for a team moving to XP or otherwise changing its process. While there are some individual skills, XP is a team sport and a social discipline, and most practices require the team to cooperate. For these, it’s not the first person that matters, it’s the last. Even if you integrate 25 times a day, the team is not continuously integrating. It’s the same for the coding standard and many other practices.
So, as you improve your process, understand the limiting factors, and help your team move to an agreement about how to work together effectively.
Conclusion
Let me remind you of the metaphors we used:
- Test-first is a math book
- Refactoring is compression
- Collective ownership is a situation room
- Pairing is a musical duet, or tag-team wrestling
- Iteration is a clock escapement
- Learning XP is learning a foreign language
- Continuous integration is balancing a checkbook
- “Go home clean” is day trading
- A standup meeting is a starter’s gun
- A retrospective is a game film
- Going XP is a group hike
I hope these have been interesting and useful, and I hope they inspire at least one improvement in how you work. Good luck on your hike.
Thank you.
—
Bill Wake is a software consultant and coach. He’s the author of Extreme Programming Explored, and the XPlorations articles at www.xp123.com. He is working on a Refactoring Workbook and an Extreme Programming Starter Kit. You can contact him at <William.Wake@acm.org>.
Copyright 2002, William C. Wake.
[Written May, 2002.]