1 Comment

Code Reviews Are a Mistake – Try Pair Programming

Recent projects have made it crystal-clear to me that formal code reviews create waste and provide no value in return. By relying on pair programming, my project teams are delivering more effectively and efficiently than before.

The core of my perspective is that pair programming is an extreme code review and therefore a formal code review is a waste.

By formal code review, I’m referring to a specific step within a feature’s lifecycle. A typical lifecycle looks something like this:

  1. A feature is defined but not started.
  2. The feature is started and in active development by a pair.
  3. The feature is complete and ready for review from three perspectives:
    • Exploratory test or QA review by a tester
    • Product review by a product owner
    • Formal code review by another developer via a pull request or a similar mechanism
  4. Any necessary refinements are made.
  5. The feature is now complete.

The core of the problem is that we’ve asked development teams to work in a throughput-based model, but the formal code review also requires the team to be responsive. The team cannot perform in both fashions at once.

Throughput vs. Responsiveness

The development team is the bottleneck on most software product teams as the majority of time and effort are spent writing software. As such, we ask development team members to keep up as much throughput as possible.

In contrast, we ask non-development members to be responsive to the development team. If a question comes up, we hope they’ll answer it as responsively as possible. If a feature is ready for test, we encourage them to test it right away.

The above modes of operation ensure that we’re getting good throughput of features while also minimizing work in progress.

Image of a more formal code review process.
Image credit : Nikolai Avteniev

Formal Code Reviews Require Split Personalities

The problem with formal code reviews is that they are handled by the same team members who are doing the development. They have to ask themselves–should we continue working in a throughput-based model?

If so, a code review has to wait for an in-progress feature to be complete. This could mean that a feature is stalled for hours or even days just waiting for review. After a period of time, context about the feature is lost, and jumping back into it can be challenging.

Should the developer be immediately responsive to code reviews? This helps ensure features are quickly finished when they’re close to completion, but it also means that the developer needs to stop working on whatever they were doing before. Incomplete work will be left in-progress, which creates waste.

Pair Programming is the Answer

My favorite aspect of the Extreme Programming discipline is that we actively identify known good practices and then take them to the extreme.

We know that, at a high level, code reviews are good. If you take a code review to the extreme, you end up with pair programming: constant code review.

Therefore, pairing makes a formal code review obsolete. Thanks to the process of pairing, the code has already been reviewed.

Image of two people pair programming.
Pair programming is your real code review. Image credit: Beanstalk.

Pairing results in higher-quality code than a formal review

Code that is formally reviewed is typically batched into dozens, hundreds, or possibly thousands of lines of code changes.

When faced with many lines of code, it is difficult for a reviewer to differentiate between signal and noise. Many changes are inconsequential and can be ignored; it is the semantic changes that are important. But how does one tease out and fully vet semantic changes when faced with a wall of red and green diff?

The reality is that it’s hard to deeply understand the semantic changes. As a result, code reviews can turn into nitpicking on inconsequential changes. Correcting these further increases the cycle time for a feature and generates even more incomplete work-in-progress.

In contrast, code created by a pair has been interactively created and reviewed line-by-line. Important semantic changes are actively discussed and reviewed in the moment. Syntax is agreed upon immediately. The result is high-quality code that does not require yet another processing step. Waste is reduced.

Conclusion

Formal code reviews can be a good thing, but Extreme Programming has shown us that we can do better. My advice is to flush formal code reviews down the toilet. Instead, pair up your developers, and you’ll automatically have code review, higher-quality code, and a more effective team.