10 facts about code review quality

In this article:
Subscribe to our blog:

This is a short and sweet story about important facts to know and share about code review quality. Join the discussion on reddit and hacker news.

680 companies were asked about their code quality and code review practices. Below are some of the learnings.

A Soviet inspector reviews a BGM-109G Tomahawk ground launched cruise missile.
A Soviet inspector reviews a BGM-109G Tomahawk ground launched cruise missile.

Fact 1:

We spend a significant amount of time reviewing code. In fact on average, we spend 5 hours per week reviewing code or 12.5% of our week looking at code.

Fact 2:

As a developer, spending more than a day a week reviewing code doesn’t correlate with improvements in perceived code quality OR in more time shipping new features (as opposed to fixing bugs or paying back tech debt).

Diminished returns: spending more than a day per week reviewing code does not correlated with better perceived code quality
Diminished returns: spending more than a day per week reviewing code does not correlated with better perceived code quality

Fact 3:

45% of developers say ‘Lack of Time’ is the real obstacle to reviewing code while 34% say ‘Pressure to Ship’.

Fact 4:

72% of developers say their code reviews are blocking (don’t ship a line of code without being reviewed).

Fact 5:

66% of developers require 1 person to approve their pull requests. 25% require 2 people. Less than 5% require more than 2.

Fact 6:

53% of people monitor code coverage but 65% don’t have a minimum threshold of code coverage to approve a pull request.

Fact 7:

29% of developers say the biggest problem in their project is “Workload” while VPs of Eng and Directors say “Delivery speed”. The third biggest problem for developers is “Management

Who gets to review code? Two thirds of companies prefer the all hands on deck approach to code review.
Who gets to review code? Two thirds of companies prefer the all hands on deck approach to code review.

Fact 8:

Regarding who gets to review code, having everyone in the team do it is the most common practice. Other alternatives are having owners of projects or modules or having senior developers review most of the code.

Fact 9:

Stricter code reviews lead to less time fixing bugs and more time delivering new features. Less strict code reviewers spend 31% of their time fixing bugs whereas stricter reviewers spend 24%. Regarding time focusing on new features: 43% and 54% corresponding.

Fact 10:

Developers spend 45% of their time fixing bugs or addressing technical debt vs of building new features.

Time spent on average per activity during development
Time spent on average per activity during development

RELATED
BLOG POSTS

Open pull request: what would happened if you merged all open PR?
We really don’t know what would happen if we merged all open pull request (PR).
Git & the impact on software development
Computers have only been around for a short while, but a lot has already happened. While there has been milestones along the way (eg the internet,...
7 Best Practices: Working with Freelancers & Outsourced Developers
Freelancers and outsourced developers have become more regular parts of the team for many using Codacy. There are some best practices we learned to...

Automate code
reviews on your commits and pull request

Group 13