Can pair programming replace code review?
It’s almost inevitable that when I participate in a conversation about pull requests and code review, someone suggests pair programming as an alternative.
For those unfamiliar:
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
— Wikipedia
These days there are also many tools for remote pair programming, with a shared screen.
At first blush, this does indeed sound like it should solve the problem of code review during the course of writing code. And to some extent, I think it does. In fact, pair programming is far better than code review in addressing some of my reasons for code review:
- Mentoring Pair programming probably does this far better than after-the-fact code review. What better experience than to have a more experienced developer interacting with you as you code?
- Reduced bus factor By pairing, you guarantee that two people are familiar with the code. This is also probably better done with pairing, than post-facto code review, since it’s impossible to do a superficial code review while pairing.
However, there are other areas where I think a post-facto code review is superior to pair programming:
- Higher quality code No doubt, a certain number of WTFs will be found and prevented while pairing. But many code WTFs are the kinds of things that make sense at the moment, but are unclear out of context. Two brains in context aren’t likely to catch these. You need a fresh perspective to catch these.
- Better communication The communication that happens during pairing will naturally be improved by pairing. But written communication is also important—the kind that happens when discussing code in a pull request. And lest you think that if you eliminate PRs this skill is no longer necessary: developers write about their code all the time, and many are terrible at it.
Perhaps on a sufficiently experienced team, where communication about code, and contextual WTFs are low, pair programming can completely replace post-facto code review. But for the majority of teams, I prefer to retain traditional code reviews, even when using pair programming.
Does your experience differ? I’d love to hear how pair programming has worked for you.
