When you're stuck together like this, I figure small differences in temperament are bound to show up.

-- Robert Pirsig[1]

The last planning activity in XP is pair programming. Two programmers discuss what they are about to program. They write a unit test which is a formal specification. Only after their intention has been communicated to each other, do they begin the implementation.

Pair programming is probably the most distinctive practice in XP. It qualitatively differentiates XP from other software methodologies. Pair programming is also the hardest practice to integrate. The payoff is that pair programming will elevate your system's quality to a new level. And, surprisingly, your team's overall efficiency will improve, too.

This chapter explains value of pair programming, how it works, and ways to adopt the practice. A number of the human factors surrounding solitary and pair programming are also covered.

Quality

We want to write quality software. Yet there are no rules that guarantee quality. For example, some people think applying the once and only once (OAOO) principle everywhere is a way to quality. Others think OAOO is not always applicable.

Yet we know quality when we see it. Two programmers often agree about the quality of a solution, but they probably won't agree on all the characteristics that contribute to or detract from its quality. It's particularly hard to assess the quality of the code as you are writing it. We can recognize quality, but it is not feasible to encode how to achieve it in all circumstances.

Your programming partner can tell you about the quality of what you are writing. He acts as an alter ego. With gentle reminders about the team's coding standards or even fuzzy statements like "this doesn't feel right", your partner improves the code before you invest too much energy into it. When there is a disagreement about quality, you discuss it. There are no rules. Your different experiences guide you.

Simply put, pair programming yields better software than solitary programming. Or, as Eric Raymond says, "Given enough eyeballs, all bugs are shallow."[2]

How It Works

Pair programming is two programmers sitting at one computer working on the same task. One person drives, and the other kibitzes.[3] They switch roles naturally when the driver gets stuck or when the kibitzer wants to express his thoughts as code or just whenever it's time to switch.

One programmer codes at a time. Just as the customer is supposed to speak in one voice, a programming pair does the same. XP's coding standard practice eliminates discussions about minor details, such as, how to align the statement braces.

The observer thinks strategically about the code with respect to the whole. He's likely to see more of the forest than the driver. For example, the observer may be thinking of additional test cases as the code is being written or seeing a pattern that was used elsewhere and should be carved out so it can be reused.

The communication between the driver and the onlooker is continuous. The feedback from the onlooker helps correct small errors in real-time before they become big problems. The driver and onlooker code in unison with the ultimate goal of not remembering who wrote which line of code. This won't happen at first, but when it does, you both know the code resulted from the synergy of your experiences and skills.

Ease on down the Road

Your initial sessions should be short (two hours or less) with frequent breaks. Adopt pairing gradually until all production code is written in pairs. In some teams this is impossible, and that's OK. XP values people over process. Some people can't pair program full-time (see sidebar).

Unlike marriage, you don't try to pair with someone until death do you part. And, even in marriage, it's a rare couple that can sustain eight hours working closely together, day in and day out. In XP, you switch partners once or twice a day. It's not like musical chairs, where everybody moves to the next chair at the same time. You might seek out specific partner, because he is knowledgeable about a particular problem or technique. Or, somebody might ask you or your partner for help.

Don't change partners too often, however. It takes time for a new partner to develop the context necessary to be productive. As with all the XP practices, you'll find what works well for your team through trial and error.

Rest & Relaxation

Pair programming is a lot of work. Sharing is hard, as anybody who has observed a preschool classroom will note. Working side by side taxes even the most peaceful programmers. You will need to remember to take breaks before tempers flare.

Pair programming is more intense than solitary programming, because somebody is always driving. It's like running in a relay race where you hand off the baton and then hop on a bike to keep up with your partner. One reason XP recommends you work only 40 hours a week is that pair programming is hard. To be an effective partner, you need to be fresh and rested. The 40 hour work week reminds us that most of XP's practices were devised to address the human side of software development.

People Problems

Software is written by people. We're the source of all the ideas and errors that go into the code and that makes us an important, if not the most important, implementation risk factor of software projects. XP doesn't try to hide the people issues behind a veneer of methodology and technology to protect us from each other. We don't ignore risk factors; we face them with courage.

Most of the XP practices are designed to force interpersonal issues to the surface so the team can address them. Software methodologists have long known that human factors are the weakest links along the chain from project conception to deployment. Gerry Weinberg sums this up in his second law consulting: "No matter how it looks at first, it's always a people problem."[4] One of the goals of XP is to help teams deal with interpersonal issues by themselves before management hires a consultant to figure out it for them.

I'm not trying to paint a picture that programming is a constant struggle with interpersonal issues, rather the complexity of our everyday lives and past experiences necessarily affects how we work. For example, have you ever had a bad hair day? Your hair, your breakfast, and the code comes out all wrong, and you just want to go home. Or, have you ever had a fight (excuse me, technical debate) with a co-worker that couldn't be resolved? You then each go off to solve it your own way. Instead of burying the hatchet, you end up burying the interpersonal conflict in the project's codebase.

XP's safeguards help resolve interpersonal issues like these. If you aren't your usual self one day, your partner will notice. He'll drive until you snap out of it. Everybody needs to coast sometimes. When you and your partner have a conflict, you have to work it out. If you don't, someone else on your team will notice you wrestling the keyboard from each other. They'll help you resolve the conflict, because they don't want to deal with battles embedded in the code.[5]

Pair programming teaches us about sharing, good manners, and acknowledging others' feelings and opinions. It's your average preschool curriculum.[6] And, by the way, pair programming can be as much fun as preschool, too. I find myself laughing and celebrating successes much more often than when I'm programming by myself. Sharing is about getting more out of who we are as individuals.

Different Strokes

The first step to acknowledging emotions is accepting that people are different. It's not as easy as it sounds. Over the years, we have developed bad habits in response to emotional situations. Some people withdraw in conflict situations. Others become more aggressive. Like most people, we reuse these patterns without regard to the other people in the situation.

Psychologists can help us to handle and to resolve conflict easily. Robert and Dorothy Bolton have developed a pragmatic approach to help people work with each other. Their system, called style flex, teaches us how to treat people differently based on our individual characteristics:[7]

Style flex involves tailoring your behavior so that your work fits better with the other person's style. Flexing your behaviors is like a professional baseball player electing to swing differently at a fastball, a slider, and a curve. [...] Style flex is a way of adapting to another person's process; it is not about conforming to his or her point of view. It is about relating constructively while appropriately disclosing your perspective on things as well as listening empathetically to others. The better the interpersonal process, the more likely that people accurately hear each other and creatively resolve conflicting opinions.

And, one of their most important tips is:[8]

When a relationship isn't going well, don't do more of the same; try something different.

If you keep this rule in mind, you will not only program with a partner better, you will also become more adept at dealing with your peers and your customers. Pair programming is an all-around learning experience that helps the team get the most out of each member, and everybody therefore gets the most out of the project. And, you'll also get help on bad hair days.

Gumption Traps

Bad hair days are when nothing seems to go right. Robert Pirsig says this happens when you run into a gumption trap, something that saps your energy, discourages you, and causes you to make mistakes. Some examples of gumption traps are:[9]

Intermittent Failure

In this the thing that is wrong becomes right all of a sudden just as you start to fix it.

Parts Setback

It's always a major gumption trap to get all the way home and discover that a new part won't work.

Value Rigidity

The facts are there but you don't see them.

Ego Traps

When the facts show that you've just goofed, you're not as likely to admit it. When false information makes you look good, you're likely to believe it.

Pirsig defines these gumption traps in terms of motorcycle maintenance, but they apply equally well to software development. Whether you are a mechanic or programmer, gumption traps keep you from getting your job done.

You can get out of gumption traps by yourself. Pirsig gives solutions for each of these traps. The biggest problem is recognizing that you have fallen into one. Even when you recognize you are in a trap, it can take you days to get out of one, if you are working alone. With a partner you'll probably be out in a few hours or possibly even minutes.

You and your partner think differently. You have different backgrounds and skills. When you are pair programming together, these differences balance each other out to help both of you avoid and recover from gumption traps.

Each of you probably won't fall into the same gumption traps. If you both fall into the same trap, one of you will come out first and help the other out. I'm sure you have had the experience of searching for a code defect with another person. It would be a rare event for both of you to find it at the exact same moment. It doesn't matter who finds it first, because both of you can continue coding once it is found.

Reducing Risk Through Knowledge Transfer

Programming pairs are not only better at finding defects, they produce better code and learn more than solitary programmers. Programming partners often come up with two different implementations for the same task. One or both of the implementations might contain ideas new to the other person. You'll discuss the differences, and possibly merge the solutions. In any event, one or both of you have learned something.

One partner is likely to know more about the code or problem you both are working on than the other. While you add business value to the project, the more experienced partner transfers knowledge to the less experienced partner. When all production code is written in pairs, no one person has unique knowledge of the codebase. This reduces risk, and spreads experience. Everybody benefits from the continous learning that goes on in an XP project. In addition, the customer benefits from the reduced risk and from the increased quality that pair programming delivers.

Footnotes

1. Zen and The Art of Motorcycle Maintenance, Robert M. Pirsig, Bantam Books, 1989, p. 40.

2. The Cathedral & the Bazaar, Eric. S. Raymond, O'Reilly and Associates, 2001, p. 30. Available online at http://www.catb.org/~esr/writings/cathedral-bazaar/. Thanks to Joe Johnston for adding another connection between open source development and XP. For others, see Open Source Development with XP

3. According to Webster's New World Dictionary: "An onlooker at a card game, etc., esp. one who volunteers advice."

4. The Secrets of Consulting, Gerald Weinberg, Dorset House, 1985, p. 5.

5. Or, to have to dislodge the keyboard embedded from your partner's skull. It's bad for your partner and the keyboard.

6. My son's preschool teacher was a corporate trainer. She said both jobs require the same skill set.

7. People Styles at Work, Robert and Dorothy Bolton, American Management Association, 1996, p. 68.

8. Ibid, p. 72.

9. Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, Bantam Books, 1989, p. 277-283.