The Benefits of Pair Progamming

February 15, 2022

I came across this tweet the other day arguing why pair programming is bad. I responded in a series of tweets, pointing out the flaws in the original author’s arguments. Here they are, in long form, for your enjoyment, dear reader.

In my org at MSFT our default modus operandi is pair and even mob programming. Each of the points made here are flawed. Let’s walk through one by one.

“One writes the code, the other observes and offers suggestions”

There is a frequent swap of “drivers” in pairing. It’s not clear that the author understands this convention from some of his follow-up points.

“Output needs to be greater than 2x the output of a single programmer”

We’re not in a factory, when thinking of how many people are working on a task, you have to take into account the overhead of breaking work for multiple concurrent streams as well as the overhead of integrating those concurrent streams. The benefits of pairing plus the decrease in overhead makes it worthwhile.

“Pairs give feedback appropriate in a code review”

In pair programming, the code review is built in. In Lean terminology, we’re building quality in rather than bolting it on after the fact. So if you’re doing code review, you can remove that step.

But let’s address the idea that “the only feedback that’s left tends to be bikeshedding or stylistic”

When you run into a bug or get stuck on logic rather than stopping and disturbing someone else’s flow, you have someone you can discuss the issue right next to you. That’s far more important feedback that “bikeshedding”.

“It kills velocity”

Faster isn’t always better again we want to build in quality. It’s the same reason why TDD is recommended (or at the very least including unit tests as part of a story) even though it takes longer to add tests to your code, the quality and the benefit of test coverage leads to better velocity than coding freestyle. What dampens velocity more? Getting feedback as you code, or waiting for a code review, revising your code based on feedback, then having a follow on review repeat as necessary).

“Pairs devolve into least common denominator performance”

By pairing a highly experienced programmer with a less experienced programmer, there is inherent learning, thus the less experienced programmer will become more proficient and effective. Rather than separating working and training into separate activities, pairing allows both to happen. Dismissing this benefit with “there are more effective ways to share knowledge” is flawed logic. You HAVE to do work, learning as you work is more effective than extemporaneous learning.

Also your first argument that you lose capacity when pairing. If the less experienced programmer isn’t able to work as fast as the one with more experience (which you argue right here) then it’s not 2x benefit that you need. Also the progress won’t drop to the least proficient, it will be more like the average of the two. If the less senior programmer struggles with implementing their story on their own, their flow stops and they have to interrupt another programmer to get help, causing another person’s flow to stop. So the flow present in pairing is better inherently than individual flow.