Introduction

Probably the most polarizing of all the Agile technical practices is pair programming. People either love it or hate it and often strongly hold one of those two positions even if they’ve never tried it for themselves.

When first introduced to the concept through XP, pair programming seemed completely counter-intuitive. There was clear value in two people together on really hard problems yet the experts were saying that it was useful even for simple code and that made no sense. Surely putting two people on the work would make it take twice as long and cost twice as much. How could that possibly be good?

We tried it because some really smart people were doing it and raving about it. People whose opinions we respected. There had to be something here even if we couldn’t see it on the surface.

After giving pair programming a real try over several months, it became obvious that all the benefits we’d been hearing about were real and tangible. It’s the most effective form of peer review we’ve ever seen and it’s a phenomenal way of getting new people up to speed on a code base.

The code written by the pairs is higher quality, with lower defects, and most surprisingly, it doesn’t take twice as long or cost twice as much. In fact, in most cases those same two people working together will ship new features just as fast as if those same two people were working independently. Except that now there are fewer defects and we have two people who understand that feature instead of just one.

The mechanics of pairing

If you haven’t tried pair programming before then you may have trouble visualizing what this really looks like.

At its simplest, pair programming is two people sitting together at the same computer, working on the same code at the same time. Only one person is actually typing at a time but both are working on solving the problem. For people new to the concept, this may seem extremely counter productive and yet the reality is that typing is only the smallest part of writing code and so sharing a keyboard is really not nearly the bottleneck that it might appear at first.

As they work, there is a continuous conversation going on between the two developers which helps both of them work at a better level.

More predictable productivity

Although we rarely talk about this, developer productivity is full of highs and lows. One day we can be turning out incredible amounts of code and the next day we can get absolutely nothing done. We’ve never met any developers who were consistently productive all the time even though as an industry we like to pretend that we are.

What we’ve found is that when pairing, we’re never quite as productive as we can be on our best days alone but we’re also never as unproductive as we are on our worst days. On average, we’re more productive when pairing and have significantly fewer fluctuations. This makes our work both more productive and more predictable when working in a pair.

One contributing factor is that pairs are less likely to get interrupted. People who are pairing are less likely to compulsively check email, Facebook or instant messaging.

Other people are generally reluctant to interrupt a pair whereas they wouldn’t think twice about interrupting an individual. We instinctively assume that people working on their own are available to answer our questions. The mere fact that we’re working in a pair discourages those kinds of interruptions.

Promiscuous pairing

We were once called in to help a team that was experiencing significant performance problems. They had code to query data from a database that was taking minutes to run and it needed to be able to run in less than a second. It turns out that this particular code had been written using pair programming but with the same two people always working together and never soliciting help from anyone else in the team. These two had written four thousand lines of code, over a period of months, to extract this data.

When we involved other team members, we were able to reduce these thousands of lines of code down to a single SQL statement, that executed in less than a second. A very complex SQL to be sure, but just one.

The expertise to solve this problem was already within the team but these two programmers chose to only work together and not involve anyone else. As a result, they built something that was far inferior to what could have been built had they involved the rest of the team.

To prevent this problem, we implement promiscuous pairing, where the pairs get mixed up on a regular basis. Sometimes pairs change for each story, sometimes it’s on a time limit. We’ve worked with teams that switched pairs by the clock - you’d pair with one person in the morning and another in the afternoon. While that worked well for some teams, other teams will sometimes find that too disconcerting and want to change pairs only on story boundaries or sometimes even on iteration boundaries.

One rule that we’ve seen implemented with success is that if a given story can’t be completed within a single iteration and has to be rescheduled, the original pair isn’t allowed to work on it in the second iteration. The theory being that they were likely stuck and having a fresh perspective on the story will be beneficial.

One technique that’s useful for encouraging promiscuous pairing is to put a pairing chart on the wall in a visible place. Every time two people pair, they put a dot on the chart at the intersection of their names to track their progress. By making this visible, people will automatically adjust their behaviour to mix up the pairing with minimal external pressure.

For example, a pairing chart for a team made up of Amy, Bob, Carol, Don and Ellen might look like this. Every time two people pair on a task, they put a tick or a check in the box where their names intersect. By making this visible, most teams will automatically switch up their pairing without any explicit requests from outside.

What if it doesn’t work?

Does pairing always work, with any combination of people? Well actually, no. Sometimes there are personality or cultural conflicts that prevent people working together in this way. We’d like to stress first that there are far more people who are convinced that it won’t work for them or for their people than there are actual cases where it doesn’t work. You might be surprised how often it does work.

Sometimes despite everyone’s best intentions, pairing just doesn’t work. We’ve worked with one team where the two most technically adept developers couldn’t pair with each other but either one could pair with anyone else on the team. Kept apart, they both brought needed skills and expertise to the team but when they sat together, sparks would fly. Strangely enough they were both proponents of pairing and wanted a chance to pair with others but could not resolve the differences between themselves. In that particular situation, the team ended up losing both developers because the issues could not be resolved.

Pairing can be very tiring, particularly for the introverts in the crowd, and so frequent breaks are a necessity. It’s also acceptable to have a mix of paired and non-paired time to give everyone a chance to recharge.

When introducing pairing to a team that isn’t comfortable with it, we ask each person to spend twenty minutes a day pairing with someone else and to mix it up so they aren’t always pairing with the same person. Twenty minutes is short enough that it’s not threatening and yet gives some experience with the actual practice.

In these twenty minutes a day, it will quickly become apparent whether pairing will work in your environment. Sometimes there are conflicts between people that just can’t be resolved and forcing people to pair in this case will cause extreme pain for the entire team.

We’d like to stress again that while almost every team initially thinks that pairing won’t work for them, it’s really a rare situation where it really doesn’t work. In my experience, most developers who have seriously tried pairing have come to prefer it over solo development.

The benefits of explaining your work out loud

The benefits of explaining problems out loud have long been known. We’ve all had the experience of explaining a problem to someone else and before we’re even finished, we’ve already solved it without getting any input from that other person.

While often discussed in the context of software development, this scenario is hardly unique to the IT field. A 2007 study¹ of four and five year old children demonstrated that their problem solving abilities were far better when they explained their thinking out loud to their mothers than they were when they worked quietly (even when their mother was still in the room).

If we accept that we have better problem solving abilities when we talk out loud even without having anyone respond, it isn’t a stretch to imagine how much better it would be if that person was working collaboratively with us to solve the problem. This is part of the magic of pair programming.

Physical space concerns to enable pairing

The simplest pairing arrangement is two people sitting side by side and sharing one keyboard and mouse. While this is easy to set up, it isn’t ideal from a usability perspective. It’s much better if each person has their own keyboard and mouse that are connected to the same machine. Most laptops will accept and external keyboard and mouse such that both the build in ones and the external ones are active at once.

The arrangement that we’ve personally find the most productive is with the two people sitting across from each other as shown in layout D above. The conversation seems most natural when we’re sitting across from each other, rather than sitting side by side.

Your team should experiment with different layouts to see what feels most comfortable for them.

Guidelines

• Occasionally, for a variety of valid reasons, there is not a second person available to pair with. Work must still go on and that one person will have to work on their own until a second person becomes available. All team members are encouraged to pair, even across specialties. Testers and developers should pair together to develop Cucumber steps, and at any other times in the development process when testers and developers need to communicate with one another clearly. Pairing is the most collaborative way to achieve a hand-off between functional specialists.
• Control of the keyboard/mouse should flow back and forth between the pairs throughout their working session. If one person is more familiar with the code than the other then the less experienced person should spend more time on the keyboard. This is to ensure that they learn the code faster. Explain what you’re thinking as you work. There should be an ongoing conversation, not two people working in silence.
• Switch pairs on a regular basis. At a minimum, switch pairs at the end of each story, if not more frequently. Make a point of pairing with people you haven’t paired with recently. Schedule regular breaks. Pairing is more intensive than working alone and will be much more tiring. Developers who are pairing must make a point of taking breaks at regular intervals.
• Avoid checking email and IM during pairing sessions. If something is truly urgent, someone will pick up the phone or walk over to talk to you. Email and IM can be checked on the regular breaks.
• If keyboards are being shared then hand sanitizer is mandatory in the team room.
• If someone offers you a breath mint, don’t say no. We are now working in closer proximity and personal cleanliness is now more important than usual.
• In the case where someone has to work alone for a period of time, make a point of rotating that so that it isn’t always the same person working alone.
• When working from home, collaborate with team mates using the most effective technologies available to you.

More information

While fairly old now, the book Pair Programming Illuminated is probably still the best book on pairing. It’s based on a huge amount of university research that the authors did on the subject.

The best way to learning about pairing is really just to do it. It will likely feel uncomfortable at first but keep it up. It gets better fairly quickly and once you’re in the flow, you’ll find that it’s not only effective, it’s actually enjoyable as well.

See also: Mob Programming