Pair Programming Doesn't Scale

Pair programming is where two programmers work together on a single computer. One writes the code, while the other observes and offers suggestions. I'm not talking about debugging or brainstorming together, but this post is about the (sometimes organizational) practice of Agile Pair Programming. Unfortunately, I think it is a bad practice.

The bar is already set high since pair programming is a synchronous workflow with two programmers. The output (read: quality, knowledge sharing, feature velocity, etc.) must be greater than the alternatives (e.g., asynchronous work streams with code reviews).

As an alternative to code reviews. Many advocates of pair programming believe that it replaces the need for a code review since the partner can review code as it is written.

• Anyone can do code reviews at any time. This means perspectives outside your pair and, most importantly, outside your team. Code reviews are documentation for future engineers.

• Pairing creates opportunities for the wrong type of feedback like bikeshedding and stylistic feedback. Does intermediate code need to be reviewed?

• Reviewing code is much quicker than writing it.

• Direction should be agreed on before any code is written. Iteration is much faster on ideas than code. Design documents are documentation.

As a knowledge-sharing mechanism. Pair programming sessions are 1:1 interactions that are neither documented nor persisted for future engineers. This often leads to codebases with a bus factor of 2. Pairs can be rotated, but that leads to various issues like administrative (managing pairs) and skill-mismatch (expert-novice).

As a mentorship tool. There's value in 1:1 knowledge sharing between an expert and a novice. But should this involve writing code? Would a walkthrough of the codebase make more sense? Maybe it's helpful to an existing employee's developer environment, but only as a one-off. And if setting up a development environment is that difficult, perhaps some structural changes could be made to reduce onboarding time for future employees.

For existing employees, pairs are often stuck at the speed of the least senior pair. While pair programming might achieve some goals as a pedagogical tool, there are more time and cost-efficient ways to share knowledge between team members.

For scaling, alternatives like code reviews, design reviews, and general documentation are better 1-to-n ways to share knowledge instead of 1-to-1. In addition, most of these alternatives are done asynchronously. If you're looking to level up your code review process, check out my Ten Things I Look For In a Code Review.

Addendum: With the proliferation of CRDTs and Remote IDEs, maybe there's a future for collaboratively writing code. Maybe AI-powered code suggestions like GitHub Copilot play a role as well. Unfortunately, I don't see Google Docs-like real-time collaboration on code can be that useful right now. But if it were effective, it would still have to look a lot different than Pair Programming does today.