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.