Pair Programming, the Good, the Bad and the Ugly

Reading http://phinze.github.io/2013/12/08/pairing-vs-code-review.html has made me consider again what I think of as "pair programming". It’s a phrase that is misinterpreted, so let me clarify what it means to me.

I’ve worked on different teams where, none, some and constant pair programming was done.

Not doing any is dangerous, and leads to the classic rock-star/lone/hero programmer situation where, by the time you realise you have a codebase consisting of a series of opaque but clever hacks, it’s too late to change anything.

Pair programming all-day, every-day can be liberating to begin with, but degenerates into absurdity e.g. pair reading of documentation. It’s not as bad as none at all, but it covers up the benefits, and provides plenty of ammunition to those who are against it entirely.

So, I definitely come down in the favour of ‘some’ pair programming, but if not all of the time, then when? Rather than prescribe a schedule, it’s important to realise why you might be doing it, and apply it as a tool.

During pairing for knowledge transfer, between an expert and a learner, then you can expect the task to take longer, because the primary goal is learning, not fast completion of the task. These sorts of sessions are best triggered as a result of a planning session conversation, where it’s obvious only one person on the team can do the task. The pairing session is ‘done’ when it becomes clear the learner can now do the task on their own. It’s important to realise that pairing for knowledge transfer is not always the best way to pass on knowledge. Repeated pairing is effectively a very slow ‘flood fill’ algorithm. Sometimes, it’s good to spend time doing a short one-to-many presentation on what you know.

If we are instead pairing to solve a problem, then the expectation is that one half of the pair is stuck in some way, or a larger problem needs to be discussed. Here, ‘done’ is when the person becomes unstuck, or a plan has been reached that looks feasible. These sessions can last seconds, minutes, or hours. Some of my most useful pairing sessions have lasted a few minutes, ending as soon as it becomes clear I’ve missed something obvious.

That last example is one reason why I mis-trust code-review, since it can too easily come at the end of a unit of work. The right feedback at the start of a task can totally change how it’s done. Once you have a functional bunch of code that’s ready to check-in or to deploy, it’s hard to push back on a bad design. A lot of the differences are down to social context. Code-reviews typically happen in a context of challenge, where one programmer presents a completed artefact for others to find fault with, whereas pair programming is typically collaborative, where you work together to share knowledge or solve a problem.

In conclusion, "pair programming” for me is a tool, not a way of life, and should be applied based on a clear statement of why you are doing it.