Pair Programming Is More Than Code Review

Pair programming, that deceptively simple practice introduced to the masses by Extreme Programming, but done by everyone at some point or another, is one of the most divisive issues that I have come across.  Some people hate it, others love it. Like any other practice though, it serves a purpose and must be understood to be used effectively. I think that one of the most deceptive things about pairing is that it looks easy, when viewed from the outside. Two people sitting at the same computer working on the same problem. What more is there to it?

I’ve practiced pair programming quite a bit during my career and always found it to be a useful and interesting way of working. My default stance on the question of “When should you pair?” has always been to respond with “pair, unless you have a really good reason not to.” My statement is purposefully opposed to the way I often hear it stated, “pair when you are working on something hard.” My reasoning is that we as people are incredibly bad at deciding beforehand if something is going to be “hard,” just take a look at our ability to estimate tasks. I also find that the latter way of stating the response brings to many macho tendencies to the fore. Admitting that something is hard opens you up to the possibility of your peers perceiving weakness. In the end I want to lower the number of hurdles that team members need to overcome to engage in a useful practice.

Like most useful things, pairing takes practice. It requires compromises from both parties. It requires understanding and acceptance from the organization around that pair. It also takes an understanding of why you are putting yourself through, what is for many, a very uncomfortable, tiring, demanding activity. Considering the effort that needs to go into it, the benefits had better be pretty damn good.

There are the normal advantages that you hear about pairing: continuous code review and knowledge sharing. I think there is an often overlooked advantage to a team that consistently practices pairing: slack. If the norm on a team is to work in pairs, then there is built-in slack to deal with the unexpected. Someone is off sick? No problem, the other half of the pair can continue the work on the task without interruption. Sudden rush of unexpected work? Don’t worry, you can reduce the amount of pairing for the short-term in order to respond and not adversely affect delivery of commitments too much.

The second use of the slack is probably the most controversial. Why don’t we just always reduce our pairing and get more done? Well, then you’ve reduced your slack, not to mention your code reviews. The next time someone is sick and you get unexpected work and you need to train up a new member of the team, which in my experience happens more than most people are willing to admit, you have now put yourself in a position where the team has become spread too thin, quality goes down, stress goes up, and it has now become more likely that unexpected work will suddenly appear in the future. Of course by that point you will need to eat into even more of the slack to deal with those problems, and so the cycle continues.

Breaking that cycle requires having the courage to say “we need to put some slack back into our system.” Using a practice that allows for higher quality, better knowledge, and improve team responsiveness just seems like a no brainer.

Join the Conversation


  1. Nice post. This kinda assumes that pairing is slower, though. I’ve been wondering lately whether that’s always true. I had a case this week where it took 2 pairs of eyes to keep us on the path. One person alone would have got lost and it would have taken longer.

  2. I’m starting to think that the “faster” and “slower” debate is missing the nuance needed to fully explore the tradeoff much in the same way that talking about the speed of a network connection without taking into account latency vs. bandwidth misses important considerations. I agree completely with you that I feel faster when pairing, if for no other reason than that I keep on task better.

    I think that for a given team, pairing will reduce the latency between work requested and work completed. Not pairing will, for a short time, increase the bandwidth of the team but at the expense of increase the latency. So for a short time the team might be able to burst out some extra work. If this situation is continued for long, however, the other factors of not pairing such as lost information spreading, reduced code quality, and no more slack will take its toll and latency will continue to increase causing overall throughput of the team to decrease.

    I think that the time that it takes to get from usefully using slack to the team digging itself a hole is much shorter that most people would think. In my experience it seems to happen in a matter of hours or days.

Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: