The case for simpler code reviews
Code reviews are one of the best ways to ensure code quality. A recent survey has found that 36% of the companies that do code reviews (84% of the total) think it is the best way to improve code quality. Too often, however, they are understood as an individual task, instead of a team effort. This article will delve into the status quo of code reviews and where the roadblocks lie.
We aren’t teaching enough how to do code reviews
The number of software developers working is increasing at an impressive rate. The number of people working in the field, both in the US and the EU, is quite encouraging from a marketplace point of view. In the US, for instance, the number has climbed from 3.4 million to 4.4 million in just a few years (2017-2019).
No complaints here.
However, this also means one thing: the proportion of junior to senior developers is also changing. People are entering the market much faster than they are being promoted. Code reviews, by and large, are not taught at University. They are something you learn on the job, ideally while being mentored by a more senior developer.
As that ratio changes, however, this becomes harder to achieve.
Code reviews aren’t being prioritised
Effective code reviews, as we have written in the past, need to be continuous. When the code is being developed without an effective integration of the reviewing processes, it often gets done last minute. Teams that are using agile techniques often end up bundling a lot of code reviews and doing them at the later stages of a sprint.
This will hurt your reviews even when you do have highly skilled reviewers. If you don’t… then you have a serious problem.
Code reviews are not an individual task
There are two aspects to doing code reviews. A part of it can, in fact, be an individual effort. The reviewing itself doesn’t imply working in pairs. But that’s only a small part of it.
If you aren’t assigning the reviews throughout the process and are, in fact, bundling them as we described, odds are you won’t assign them evenly. You will want the most skilled reviewers in your team to be doing them, to avoid creating massive bottlenecks.
Codegrip's survey Code Review Trends in 2020
The same study we quoted in the intro, focused on code review trends, has discovered that the Team Lead alone is responsible for code quality in more teams (38%) than those who share the responsibility (36%). In fact, a staggering half (50%) of teams assign this responsibility either to the Team Leads or senior developers alone.
Evidently, this is unsustainable. And the numbers show it. Only 35% of the companies that do code reviews are happy with their results. The others all mentioned they needed to improve them.
Code reviews need to withstand staffing changes
Let’s dive deeper into those numbers: 67% of the companies that aren’t doing code reviews yet say they would want to. So what’s stopping them?
Codegrip's survey Code Review Trends in 2020
Fewer than 50% of smaller teams had code review processes in place. 36% of all companies that don’t have these processes blamed not having enough staff.
This clearly indicates that code reviews are still seen as a separate process from development, something to be done afterwards, separately. The immediate result of this is that leads and senior developers end up doing most of the work, and junior developers don’t learn how to do reviews.
Worse: Leads and senior developers leave. Sometimes they’re absent. Unforeseen events happen, and the processes must be in place to deal with them. A continuous, code-review centric, development process will organise reviews so they are spread purposefully amongst the team in a way that mitigates this issue.
We need the right tools
We have also learnt that only 57% of teams are performing tool-based (or using a combination that includes tools) code reviews. The market is failing 43% of teams, who are performing code reviews without the help of the software that makes the task easier.
This will inevitably contribute to code reviews feeling like much more of a demand on time than they need be. I have tweeted recently about using Reviewpad for short sessions of pair programming followed by asynchronous code reviews. I found it to be a powerful way of working, and certainly something to explore further. It’s hard to develop better practices for code reviews if you don’t have an adequate toolkit.
Good and simpler
Gergely Orosz has written an excellent article about perfecting code reviews, and a lot of his suggestions ring true. He differentiates between good and better practices for code reviews. We would, however, suggest a different way of thinking about this: good and simpler practices.
At the end of the day, we believe in a code review culture that integrates this process into development in a way that doesn’t make them feel like a separate entity.
We want to switch the focus of the best practices analysis from what’s ideal to the code reviewer as a separate, individual, entity to what’s best for the team and the shared ownership of the codebase.
This usually means adopting simpler practices that make code reviews more lightweight. It means sharing the load, instead of demanding so much from senior developers. It means bringing junior developers in early, so they can learn from the best. It means doing code reviews continuously, instead of at the latter stages of a sprint. It also means having the right tools.
And this, in a nutshell, is why we’re building Reviewpad.
