IBM Skip to main content
Search for:   within 
      Search help  
     IBM home  |  Products & services  |  Support & downloads   |  My account

developerWorks > Java technology
Demystifying Extreme Programming: Winning with a pair
Discuss71KBe-mail it!
What pairing is -- and isn't
The benefits of pairing
Why some programmers hate it
Why some managers hate it
What pairing is really about
About the author
Rate this article
Related content:
Demystifying Extreme Programming series
An excerpt from "Java Tools for Extreme Programming"
Extreme Programming with IBM VisualAge for Java
dW newsletters
dW Subscription
(CDs and downloads)
Two heads are better than one

Level: Introductory

Roy W. Miller ( with a pair)
Software Developer, RoleModel Software, Inc.
11 March 2003

Column iconCertain XP practices make project managers scoff and programmers wince. Pair programming (or pairing) is one of them. Based on feedback from some of XP's critics, pair programming gets the award for "practice most likely to offend" -- that is, if you had to pick just one. This month, XP coach Roy Miller talks about this radical way to write code, including the misconceptions surrounding pairing, why so many software developers hate it, and why it's so important to your project's success. Share your thoughts on this article with the author and other readers in the accompanying discussion forum. (You can also click Discuss at the top or bottom of the article to access the forum.)

Programming has been essentially a solitary profession for the last five decades. Oh sure, programmers talk to other people, especially during the requirements-gathering phase of projects. But once the coding starts, programmers in most companies tend to dash for their offices or cubicles to be alone. Managers don't mind too much, because programmers working alone fit into the work plan easier, and having many people working on discrete pieces of the problem at the same time seems more efficient. Then along came XP proponents who said programmers should write code in pairs. If you tell that to most managers and programmers, you're bound to get some weird looks, suggesting they pity you for being so misguided. The reason is because they either don't understand what pairing really is, or they do understand it, but think it's an unwise or crazy approach to coding.

What pairing is -- and isn't
When I first mention pairing to people unfamiliar with the concept, I tend to get three common reactions:

  • Huh?
  • That sounds interesting.
  • That's insane/stupid/inefficient/fill-in-your-favorite-derogatory-adjective.

I can respond to the first two reactions easier than the third, because the first two usually come from people who need more information. In the first case, the person has no idea what I'm talking about, so I give him a quick definition:

Pairing is two people working on the same programming problem together.

As I said in the second article in this column, "XP distilled revisited, Part 2," the mechanics of pairing look like this:

[Pairing] typically means two developers sharing one computer, one monitor, one keyboard, and one mouse (I've found two monitors, two keyboards, and two mice to be more enjoyable and more efficient, but the single version works fine, too). You and your counterpart sit at the keyboard. One person drives (the "driver") and the other helps him find his way (the "navigator," or "partner").

If the driver gets stuck or frustrated or loses his train of thought, the navigator and driver can switch roles. In fact, that should happen very often, sometimes every couple minutes (or even more frequently than that). Once you get used to it, and to the particular person you're pairing with, you slip into a flow, switching back and forth naturally.

When I describe pairing to the "Huh?" people in those terms, their reaction usually shifts to "That sounds interesting" or -- more likely -- "That's insane." Either they have questions about how pairing could work in their particular situation (see the accompanying discussion forum where you can ask these questions and see my responses to those who've come before you), or they want to convince me that it's just not a viable option. I'll get to the "That's insane" folks a bit later, but first let me talk about the most intriguing question I've heard: Why pair?

The benefits of pairing
Why should you pair? The simple answer is that pairing:

  • Reduces risk
  • Makes the team more productive
  • Results in better code

Risk can be paralyzing for most teams. Think about your last project. I'll bet you can think of something you wanted to do, but played it safe because your idea seemed too risky. Join the club. The best way to reduce risk is to make sure everybody on the team is broadly familiar with all parts of the system and with all changes to the system. Chalk talks and design documents are helpful, but they can't spread knowledge well enough and fast enough for most fast-paced projects. The most efficient way to spread knowledge is for somebody who knows the code to work on it with somebody who doesn't.

Pairing is one of the greatest tools managers and teams have to reduce risk and keep change from killing a team. When teams pair, all design decisions and code changes get made by at least two people. By pairing programmers, managers ensure that more people are familiar with the code and the changes it's going through. In addition, code written by a pair is almost always better than code written by an individual. Two heads really are better than one, especially for design decisions that affect the entire system. No matter how smart a programmer is (or thinks he is), a second opinion helps avoid bad decisions that arise from ignorance, arrogance, or simple oversight.

While many programmers probably don't have much trouble staying focused, it certainly helps to have somebody else keeping the rest of us mere mortals on track. It's especially helpful when you're trying to solve a frustrating problem. When you feel like giving up, there's somebody else there to encourage you and keep you going. Teams are also less likely to neglect tests or other important details -- that alone increases productivity.

On my pre-XP projects, my teams slowly picked up speed as the project moved along, but eventually slowed down again as bugs piled up. On my XP projects, however, my teams get unbelievably fast very quickly, and then stay there. Recently, for example, my team's velocity went from 14 story points in iteration one, to over 60 story points in iteration five (see Resources for more information about the XP concept of story points). The primary reason was that our code got more mature much faster than I had ever seen before, which allowed us to move more quickly as the project developed. And when teams pair, code is constantly being reviewed by at least one person. That's the best code review I've ever heard of.

The XP value of Simplicity suggests everybody on my team ought to do the simplest thing that could possibly work, both for code and for process. Pairing might not seem simple when you start. It's a bit uncomfortable, and it takes some getting used to. But the values, principles, and practices of XP don't encourage you to do the simplest thing possible -- they encourage you to do the simplest thing that could possibly work. If something is simple (say, having everybody code alone) but it isn't effective, than it's not the simplest thing that could possibly work. Sometimes the simplest thing that could possibly work is hard until you get used to it. Pairing is a good example. In my experience, not pairing doesn't work as often as pairing does.

Why some programmers hate it
I've met quite a few programmers who think pairing is crazy. Many of them refuse to try it or even talk about it with an open mind. I think their intense antipathy comes from several sources:

  • They believe pairing will "slow them down."
  • They've tried pairing and they find it too draining, too stressful, or both.
  • They need time alone to figure problems out.
  • Deep down they're afraid of letting other people see that they're not always geniuses.

Programmers tend to be a proud lot, and many are prone to delusions of grandeur. Sometimes they can back up the bravado with prodigious intelligence and skill, but even those who can't probably think they can. Still, even the best programmer in the world can learn something from the lowliest hacker -- a fact many of them forget. When a programmer says pairing will slow him down, he might be right. Perhaps working with somebody else will reduce his individual speed. But the benefit of having two minds attack the problem can cancel out any short-term dips in individual productivity. What most programmers mean when they say pairing will slow them down is, "I'm better than that other guy, and carrying him will hold me back."

Pairing isn't for everyone. Spending all day in a cubicle bouncing ideas off another person is probably not your typical programmer's idea of a good time, and it can be stressful. But the stress can pay off. Relating to people is often more difficult than being alone, but sooner or later every programmer is going to have to speak to other human beings (or at least other programmers) in order to get the job done. Pairing is a habit that can help make the human interchange feel as normal and non-threatening as coding.

Even if a programmer buys the idea that communicating is a better way to learn and create, he still probably feels like he needs some "alone time" to figure stuff out. I can understand. Sometimes a little concentrated thought, with nobody to have to explain myself to, is what's necessary to solve a problem I'm working on. I'm convinced, though, that this need for alone time really is a symptom of something much deeper.

Of all the reasons programmers might give for why they think pair programming is stupid, the scariest one is that they're afraid. This is human. Nobody likes to put his weaknesses and ignorance on display. Many programmers have a hard time admitting that they aren't brilliant, but they have an even harder time letting it show. They hate the idea that they might be proven wrong. But we need to expose our weaknesses in order to learn from them and grow as a result. Pairing can make you more whole as a professional software developer.

Why some managers hate it
I think many managers hate the idea of pair programming for a combination of reasons:

  • Conditioning
  • Fear of what their peers or their superiors will think
  • Resistance from programmers who work for them

Especially in the last hundred years, managers have been conditioned strongly to believe that more than one person working on the same task is inherently inefficient. In some industries, such as manufacturing, that might be true. But it's not necessarily the case for knowledge work such as software development. As soon as someone starts talking about pairing programmers, though, many managers say, "That's inefficient." I usually say, "That's right, and that's good." Creating great software isn't an efficiency optimization problem. It's about invention. Invention is a messy business where efficiency doesn't work. Now, if two people sit together, but one person simply looks over the other's shoulder and doesn't participate, that's truly inefficient. If, on the other hand, two programmers are working to solve the same problem, you get the benefit of two focused minds. The solution will almost always be better. If one mind has a flash of brilliance, the other might balance it by keeping it focused on the simplest implementation of the idea. If the other mind goes for simple and passes right on to stupid, the other can stop the madness. Manager conditioning on this issue is wrong, and most managers don't (or can't) question it.

One of the reasons many managers shy away from pairing is that they're afraid of how it might be perceived. If their boss sees programmers sitting together looking at the same monitor, he might storm into the manager's office and demand to know why "resources" are being wasted. If a peer drops by to discuss something and sees programmers pairing, word might get around that the manager has lost his mind. Those are real fears. But I suggest that the damage to the team's real (as opposed to apparent) productivity will far outweigh the damage to the manager's reputation. Results matter. Suppose he lets his programmers pair, rather than having everybody work separately. If the pairing experiment produces better results more often, the means of getting there becomes less of an issue. It might even become the standard.

Notice, incidentally, that I said the manager lets his programmers pair. What if his programmers don't want to? This, I think, is the biggest reason most development teams don't pair. I've spoken to many managers who think pairing sounds like the right thing to do. Those same managers, however, tell me that their programmers threaten to quit, in some cases en masse, if forced to pair. You've already read why programmers might react that way, but what's a manager to do? I'm convinced there are only three options:

  • Find people who want to pair and manage them instead.
  • Force the team, including the naysayers, to try pairing for a two-week experiment.
  • Go somewhere else where you can manage people who want to pair.

Before I get flooded with responses telling me how hopelessly naive I am, let me say that I realize the first option isn't typically available. Most managers aren't that empowered. The third option is a bit drastic, but more on it in a moment. The second option, however, might prove interesting.

Some research, albeit with university students, shows that programmers who initially hate the idea of pairing end up liking it after they try it (see The Costs and Benefits of Pair Programming by Alistair Cockburn and Laurie Williams in Resources for more details). Forcing people to do something is heavy-handed, but sometimes it's necessary to jolt people out of their collective or individual rut. Try forcing people to try pairing for a very short time. If they object, emphasize the fact that it's only two weeks. Anybody can put up with anything for two weeks. Those who aren't convinced after two weeks probably won't be convinced after two months -- and even if they would be, you'll probably never find out because they would never try it for two months. A manager's strongest hope is that two weeks will convince most programmers that pairing has promise. If not, you always have options one and three.

What a good manager cannot do is mandate pairing for the long term. That's beyond heavy-handed. It's dangerous. It's a good way to make enemies. If your programmers are so mad that they leave, you're left holding the bag. Experiments are fine. Changes after you get some team buy-in are fine. Oppression usually fails.

Give me your ideas

You can help determine what I write about next month. What's the biggest question you have about XP? What do you think is completely silly, or unwise, or unprofessional, or impossible? What's the most confusing practice? Offer your suggestions in the forum for this column.

What pairing is really about
Pairing can be discussed at two levels. The first level is mechanical -- the raw description as to what constitutes "pairing." The second, deeper level is the interpersonal. Pairing is about relating to the people you work with as part of a team. That's the most challenging part of work -- relating to people you're not related to because (most often) somebody else told you that you must. Since every person is different, this can be a challenge, both for you and for others. As Ken Auer and I point out in Extreme Programming Applied (see Resources), interpersonal relationships are hard, especially in a professional environment where politics and hidden agendas can complicate things. Even if just for a few hours, these types of relationships are not something most people are interested in. This is a radical idea, and it isn't for everyone. But it also can produce some of the most rewarding experiences of your professional career.


About the author
Roy W. Miller has been a software developer and technology consultant for almost ten years, first with Andersen Consulting (now Accenture) and currently with RoleModel Software, Inc. in North Carolina. He has used heavyweight methods and agile ones, including XP. He co-authored a book in the Addison-Wesley XP Series (Extreme Programming Applied: Playing to Win) and is currently writing a book about complexity, emergence, and software development (the working title is Growing Software: Debunking the Myth of Prediction and Control). Contact Roy at or You can also visit his personal Web site at

Discuss71KBe-mail it!

What do you think of this document?
Killer! (5) Good stuff (4) So-so; not bad (3) Needs work (2) Lame! (1)

Send us your comments or click Discuss to share your comments with others.

developerWorks > Java technology
  About IBM  |  Privacy  |  Terms of use  |  Contact