The Code Review Quadrant
In this post, I introduce the code review quadrant. This quadrant is an abstraction helping teams identify areas of improvement for their code review practice.
Why, you ask? Well, code reviews do not only have benefits. Code Reviews can be bottlenecks and slow down a team’s productivity. In the worst case, the only thing developers are getting from a code review, after a long time of waiting, is questionable feedback that focuses on minor issues.
But which pitfalls are teams actually experiencing? What causes the poor code review experience? And, how can a team improve its code review practice?
These questions keep me busy already for a long time. And because code review, as a socio-technical practice, is highly complex, problems are often manifold. Similarly, most improvement strategies depend on the team and their circumstances.
Abstraction brings clarity
Still, while researching code reviews and working with many product teams at Microsoft and teams from all over the world in my code review workshops, I saw patterns emerge. The many pitfalls teams experience are either impacting the value of the feedback or the time it takes to perform code reviews.
And, code review speed and feedback value determine the benefits and drawbacks teams experience from code reviews.
This post focuses on visualizing the interplay of code review speed and feedback value. To do so, I introduce the code review quadrant below. Here you see that code reviews can be categorized into four types: blocking reviews, omissible reviews, value reviews, and power reviews. This quadrant helps teams to understand what to focus on when striving to improve their code review experience.
Let’s look at each category of the code review quadrant individually.
First, blocking code reviews
Such reviews happen when feedback value is low and review speed is slow (see the lower left side of the code review quadrant). This is the worst type of code review. Developers that experience such reviews are blocked by the code review activity, and in addition, do not get much value out of code reviews. This type of code review is common for teams that require cross-team code reviews, and teams that must follow strict policies and guidelines that do not reflect well their needs.
The second category of code reviews is omissible reviews
Those reviews happen quite fast. But, the value developers get out of the code review feedback is low (see the lower right side of the code review quadrant). Unfortunately, this type of code review is happing way too often. With the adoption of tools like GitLab and GitHub many companies now “do” code reviews. Well, what’s actually happening is that they pretend to do code reviews. It’s like a window dressing activity. Because the feedback speed is fast, the code review activity doesn’t block teams too much. Still, also this type of code review has a negative impact on the team’s productivity. So, teams are better off to stop this nonsense or to commit to actually do code reviews.
The third category is a common one: Value Reviews
This type of code review is common for teams that know and value the benefits of code reviews (see the upper left side of the code review quadrant). Reviews in this category are thorough, and developers get high-value feedback. Still, teams fell prey to the drawbacks of code reviews, and feedback takes too long. Thus, these reviews significantly reduce the productivity and the happiness of the team and the individual developers.
I love working with teams that are in this category because I know I can show them how to increase speed and feedback value, without having to convince them of the benefits of code reviews. Those teams already know. All they need is help to overcome the pitfalls they experience.
And with that help, developers enter the state of power reviews, where they give and receive high-quality feedback in a timely manner.
Power Reviews: The Crème de la Crème.
Code reviews in this category comprise high-quality and high-value feedback. In addition, developers deliver this feedback in a timely manner (see the upper right side of the code review quadrant). These are the code reviews teams are striving for.
Well, only one question remains: How can we reach the state of power reviews?
Getting to power reviews
The way to power reviews highly depends on where in the quadrant teams see themselves. That’s why I developed this code review quadrant. It helps highlight the main areas of improvement in an easy to digest way.
In upcoming posts, I will talk about each of the four code review types in more detail, including highlighting concrete measures of improvement.
Still, I do not want to leave you without some concrete and actionable improvements. So here are three foundational aspects that lead to fast and powerful code reviews:
👉 reviewing small, incremental code changes,
👉 increasing process speed to ensure fast feedback,
👉 and, reducing the reviewer’s burden as much as possible.
In my upcoming posts (and my code review workshops), I go into all the details of how to increase both, code review value and code review speed at the same time. I can send you an email once they are online. As a subscriber, you also get access to my exclusive code review e-book and valuable code review checklists.
