Are Code Reviews Killing Your Delivery Speed?

Picture this: you have a task to deliver a feature that takes a day to code. Let's say that on average it takes your colleagues a day to open your pull request and an hour to do the review. This is what the visual representation of the process might look like:

Not bad. Now, let’s imagine a scenario that happens all too often: your colleagues reject your pull request and leave some comments. As a result, you have to address the issues and request a review once more:

As is shown in the picture above, a significant amount of calendar time is being spent waiting for your code to be reviewed. In reality, the actual time spent waiting within your team may differ from the 8 hours provided in the example (it could be less or it could be more). However, it more often than not still remains a significant part of the overall development process. And it’s not a reflection of your colleagues’ incompetence or lack of responsibility. Like you, they prioritise completing their own tasks with minimal context switching.

While eliminating code reviews entirely might seem like a good idea, it’s generally not a wise decision, as it would compromise software quality in favour of short-term speed gains. Here are my top 3 strategies to help you reduce the time spent waiting for your colleagues to review your pull request:

Ensuring Your Pull Request Doesn’t Get Rejected

How do you ensure your pull request doesn’t get rejected before the code review is even requested? Start by discussing technically challenging tasks with your colleagues before you begin coding. This approach reduces the chances of missing something significant that could lead to your pull request being rejected and require substantial rework. Plus, it familiarises your colleagues with the changes they will have to review later.

To further minimise the chances of rejection, conduct a thorough code review yourself after writing the code. Take a break and pretend you’re reviewing someone else’s work. The more issues you address, the lower the chances of your pull request being rejected.

Finally, consider using AI code review tools before asking others to review the code. Once AI gives you the green light, only then should you request a human review.

Pair Coding

Pair coding offers numerous benefits, including improved software quality and faster code delivery. Additionally, when you pair code, you don’t need a separate code review because your code is being reviewed by someone else while you’re writing it*.

While pair coding may reduce individual developer productivity (2 developers working on the same feature simultaneously), it’s arguably one of the fastest methods for delivering features.

* Of course, there are exceptions, where the changes are highly intricate, and you might still want to have your code reviewed by another unbiased person. But, in my opinion, this is the exception rather than the norm.

Live Code Reviews

This method is similar to pair coding, but instead of coding, the original author and reviewer review a pull request together and resolve issues on the spot. Although this type of review takes a bit longer, you avoid the “reject-fix-wait-review” cycle. Additionally, you sidestep long back-and-forth discussions via pull request comments, which can often be time-consuming.

Summary

While code reviews are a valuable tool, they come with a cost. This cost, however, can be significantly reduced by ensuring that your pull requests are approved on the first go. Additionally, collaborating with your teammates through pair coding or live code reviews can further decrease this cost.

Thank you for reading! I would love to hear your thoughts in the comments.