Can Pair Programming & Code Reviews coexist?
A common assumption with Pair Programming is that it lessens the need for Code Reviews since it serves as a review on-the-go. While I understand the premise of the assumption, it often conflates the goals of Pair Programming and Code Reviews. In this article, I’d like to re-evaluate this assumption by examining the relationship between Pairing and Code Reviews with regards to quality.
“Pair Programming can lessen the need for Code Reviews”
At first glance, this masquerades as a strong, sensible argument. I’ve used it many times myself. It makes sense that as the number of eyes increase on code, so does catching bugs and improving quality.
Yet, it’s not as straightforward as it appears. To understand why, let’s step back and examine “Refactoring vs Adding new features” as a parallel. Martin Fowler wrote one of my favorite articles on this topic. In the article, Martin runs through different refactoring workflows while adding new features. He uses a metaphor of wearing different hats for different contexts and goals.
Builders and Explorers
As an example, the developer wears the Builder’s hat when adding a new feature. Here, the mindset is focused on feature progress rather than on cleaning up flying dust (messy code) in the process of “building.”
But then she wears the Explorer’s hat when refactoring. Here, the mindset is to explore areas needing attention to readability, easy-comprehensibility, and maintainability.
“The rule is you can only wear one hat at a time, but you’re allowed to frequently swap hats” — Martin Fowler
This highlights the difference in the Builder’s mindset and approach from the Explorer’s. The metaphor is easily mapped to Pair Programming and Code Reviews.
Depending on the Pairing style, developers may wear a variety of hat configurations. For example, when adding new features, the dev pair may wear the Builder’s hat together. If the dev pair is working on refactoring, they may wear the Explorer’s hat, also together. In other Pairing styles, one may wear the Builder’s hat while the other wears the Explorer’s. This is also known as the Driver-Navigator Pairing Pattern.
Investigators
Now when code reviewing, I argue developers wear a new hat; the Investigator’s hat. In this case, the mindset and approach require suspicion and curiosity.
The goal here is to find conflicts with one’s understanding of the work and the code. The main motive is driven by what constitutes correctness. This pushes developers to 1) hunt down bugs and 2) improve the quality of the code.
The Relationship
Now, going back to the argument of more eyes means catching more issues. This assumes that the goal of the Pairing activity is quality. But, the true goal of any Pairing activity is either adding features or refactoring, much like doing the work alone. When done well, Pairing does influence quality positively. However, it is not the goal of the activity itself. It is merely a side effect. Therefore, quality is indirectly assumed as an outcome.
As for Code Reviews, the goal is to explicitly catch bugs and improve the code. Essentially, the goal and output of Code Reviews are, in fact, to directly achieve higher quality. Therefore, Pairing shouldn’t lessen the need for Code Reviews. If it did, quality would also lessen.
Code Reviews and Pair Programming go hand-in-hand. More of one shouldn’t take away from the other. Instead, they compliment each other by influencing quality directly and indirectly.
Closing thoughts
- On my current team, we pair often and review code often. We noticed this approach served us well in keeping a fairly low technical debt.
- We find issues reviewing code, even if we paired on it, that didn’t surface while pairing. This illustrates the shift in mindset between the activities — Building, Exploring, Investigating.
- Our Code Reviews don’t follow the pull-request model to avoid creating a bottleneck and to Continuously Integrate (CI) code. They also don’t fit the classic model of “team reviews code on a screen.” Instead, they are asynchronous most of the time and one-on-one some times.
- Code Reviews can’t prevent issues in code pushed in a trunk-based development approach/Continuous Integration (CI). They will, however, help maintain and increase quality over time.
- Some nuances worth mentioning: Pairing and Code Reviews may have ancillary goals. For instance, you could Pair Program to onboard new developers. Alternatively, you could use Code Reviews as a knowledge-sharing platform for devs and other tech-minded roles. In these cases, it’s not so much about direct software quality.
Additional Reads
I find myself going back to read these articles on Pair Programming. They are as thorough as they are insightful.
- On Pair Programming
- Pairing, are you doing it wrong?
- Pair Programming — a most uncomfortable working situation
Acknowledgments
Big thanks to Megan Lusher, Smitha Ajay, Yujie Wu, Saleem Siddiqui, John Haines, Elliott Branecky and Sarah LeBlanc for reading drafts of this article and providing crucial feedback on improvements.
