In a LinkedIn discussion about the mistake I shared yesterday, someone opined:

Whether you do your code review async or sync with pair programming is up to how the team wants to do things. Both are fine.

Are they, though?

I mean, on the one hand, sure. Valuable, well-crafted software is created using both techniques. But does that mean that both approaches are “fine”? Or simply a matter of personal/team preference?

I don’t think so.

To keep focus, let’s discuss just two approaches: PR-based, async code reviews, versus pair programming. There are many alternatives, and we could apply the following reasoning to them as well, but for simplicity, let’s stick with these two.

Both have pros and cons, strengths and weaknesses.

So perhaps, technically, one can say “both are fine”. Just as one can be technically correct by claiming that “both a bicycle and a 747 are fine.” Yes, each is fine, in its own context. But that in no way makes them equal, or interchangeable.

So what are the strengths and weaknesses of async pull requests, and pair programming and synchronous code review? Here are a few off the top of my head:

Pull requests

Pros

• Facilitates collaboration spanning incompatible schedules (different timezones, etc)
• Works well for vetting untrusted changes (i.e. opensource contributions from strangers)
• Ubiquitous—virtually every developer knows how to use the workflow. It’s “comfortable”. Tooling abounds.

Cons

• Slow cycle times (In some organizations, PRs often take weeks or longer to get approved/merged)
• Lots of context switching
• Encourage large batches of work

Pair programming

Pros

• Very fast cycle times—since code is reviewed as it’s written, it can be ready to merge and potentially deploy in minutes.
• Facilitates much tighter collaboration
• Improves knowledge sharing
• Improves work quality, according to the studies I’ve seen

Cons

• Requires compatible schedules
• Not comfortable to many people (although I suspect most of these people have never done good pairing—it can be a rarity)
• Requires a different set of tools (especially for remote pairing)
• Marginally slower. Despite the common, and superficially plausible trope that pair programming means you will produce code at half the speed, the best studies I’ve read suggest that pair programming is slightly slower than the more traditional scatter-gather approach, but only slightly.

So where does that leave us? How do we decide which approach is better for a given context?

I’ll be talking more about that. But for now, how do you decide? Which set of pros/cons is most important to your and your team’s context? And while we’re at it, which pros and cons have I left out that matter for you? Let me know.