"One business day is the maximum time it should take to respond to a code review request” - Google Engineering Guidelines

“Good, timely code review is vital to both the quality and throughput of a team’s code delivery… Pending code reviews represent blocked threads of execution.” - Glen Sanford, On Code Review

Code reviews need to be turned around efficiently - everyone who’s ever been blocked waiting for a code review knows the pain when this doesn’t happen. A developer who is waiting for their code to be reviewed either is blocked from future work or they have to context switch to a new project - and then switch back when the review is finished. Plus, the actual work being reviewed is delayed from being released. So you’d think that every engineering team would strive to get reviews completed in under a day.

But data we’ve collected from teams around the world paints a very different picture.

78% of developers said they need to wait more than 1 day for a review.

And that wasn’t the worst of it.

One in three teams expected to wait more than two days for a review and the slowest quartile expected it to take nearly three days for them to get their review.

If you are waiting three days for a review to get back to you then you’ll inevitably have switched to working on something else and the context switching costs of going back to your original work are extremely high.

Different teams, same problems

When I first saw this data I was sure that the way a team reviewed code would be somewhat linked to the size of the team or the maturity of the company. But that’s not what we see in the data.

Inefficient review practices are present at teams of all shapes and sizes - and have a negative impact on all of them.

For example - let’s look at developers from two different teams:

	Team 1	Team 2
How long do you wait for the typical review?	72 hours	72 hours
How many PRs do you open per week?	5	5
What percentage of your PRs are approved with no requested changes?	35%	40%
Company size	4 people	350 people

The root causes of the delays for their code reviews might be different, but developers at both of these companies are being massively slowed down by how long it takes

Shifting the perspective on reviews

We know that the current review process for most teams isn’t ideal - but it feels like we’ve accepted it. In our survey, one developer said their biggest frustration with the review process is “how long it takes to get reviews, but it’s understandable that others are working on their own features”.

On the one hand this makes sense. We can often think of the new code or new features as the most important piece of our work. But this winds up neglecting the bigger picture of how we need to work in a team to help everyone move forward efficiently.

As teams we need to adjust our perspective and see that pending code reviews are blockers that need to be dealt with as soon as possible and that reviews always need to be a priority.

Do you have your own experiences with code reviews? You can add to our survey on the state of code reviews.

---

At Sourcery we’re trying to make the code review process more effective by providing automatic reviews for every code change. Try it out for GitHub, or sign up for our waitlist for other platforms.