arrow_backAll articles

Code review best practices: how to speed up reviews without hurting quality

· Josef Chmel

Code review best practices: how to speed up reviews without hurting quality

Pull requests wait for days, reviewers argue about formatting and bugs still slip through. What Google and Microsoft learned about code review, and how to set it up so it stops slowing your team down.

Almost every software company does code review today. Few know what it costs them. A pull request waits two days for a reviewer, then twenty comments arrive about variable names, the author has meanwhile started something else, and the whole cycle repeats. The head of the company only sees the outcome: a feature that was due on Tuesday reaches the customer next week. Let's look at what large studies say about code review best practices and how to set reviews up so they protect quality without slowing the team down.

What fast code review looks like: data from Google

Google has been using code review for decades. The study Modern Code Review: A Case Study at Google (Sadowski et al., 2018) analysed logs of 9 million reviewed changes and added interviews and a survey of developers. The results surprise most companies:

  • the median latency of the whole review process is under 4 hours; for small changes, the median wait for first feedback is under an hour,
  • the median change modifies 24 lines; over 35% of changes modify a single file and over 10% a single line,
  • the median number of reviewers is 1; fewer than 25% of changes have more than one reviewer,
  • over 80% of changes need at most one round of comments, and 97% of developers are satisfied with the process.

Code review at Google: median review latency under 4 hours, the median change modifies 24 lines, one reviewer in the median and 97% of developers satisfied

The key is not that Google has better developers. The key is change size. A reviewer reads a small change in a few minutes between two tasks; a large one gets postponed until "there is time" – which never comes. According to the study, Google developers spend an average of 3.2 hours a week reviewing (median 2.6 hours), roughly half a day of the working week.

What reviews actually deliver (and what they don't)

Most teams justify reviews by saying they "catch bugs". Microsoft researchers Alberto Bacchelli and Christian Bird therefore looked at what reviews really do. They observed and interviewed developers, ran a survey (873 developers and testers and 165 managers responded) and manually classified 570 review comments.

  • 44% of developers and testers ranked finding defects as their top reason for code review,
  • yet only 14% of comments were actually about defects,
  • the largest category (29%) was code improvements – readability, naming, structure.

Microsoft research: 44% of developers expect reviews mainly to find defects, but only 14% of comments are about defects; code improvement suggestions are the largest category at 29%

That does not make reviews useless. They spread knowledge, keep the team aware of what is changing in the code and make the code more readable for the future. For the head of a company, two things follow. First: a review is not a substitute for tests. Bugs should be caught by automated tests and CI; the review should check design, readability and whether the change does what it was meant to do. Second: the study names understanding why the change is being made as reviewers' biggest challenge. When a pull request does not link to the requirement, the reviewer spends time reconstructing the intent instead of judging the solution.

Why review speed matters

Google's public guidelines for reviewers (Google Engineering Practices) are clear: one business day is the maximum time it should take to respond to a code review request. At the same time, a developer should not interrupt focused work to do a review – they should wait for a natural break, such as finishing a task or coming back from lunch. And when a huge change arrives, the reviewer should not postpone it for a week but ask the author to split it into smaller ones.

DORA research confirms this is not just about comfort. Nathen Harvey, who leads DORA at Google, said about the findings of the 2023 report that speeding up code reviews led to 50% higher software delivery performance. He added an important caveat: if your reviews are already fast, don't try to make them faster. The big opportunity is where reviews are slow.

How much code at once: rules of thumb

For the act of reading code itself, SmartBear summarises useful numbers in its peer review guidelines:

  • 200–400 lines at a time – beyond 400 lines, the ability to find defects diminishes,
  • under 500 lines per hour – at faster rates, the number of defects found drops significantly,
  • no more than 60 minutes at a time – after that, reviewer attention drops,
  • according to SmartBear, reviewing 200–400 lines over 60–90 minutes should find 70–90% of defects.

Four numbers for setting up code review: 200–400 lines at a time, at most 60 minutes in one sitting, first response within one business day and 50% higher delivery performance after speeding up slow reviews

How to set up code review in your company: six steps

  1. Small tasks, small pull requests. Change size is the biggest lever on review speed. Split work into tasks that can be finished and reviewed on their own.
  2. Every PR links to the requirement. The reviewer needs to know why, not just what. Ideally the task has acceptance criteria the change is judged against.
  3. Tests catch bugs, people judge design. Leave formatting and style to the linter and regressions to tests and CI. Humans should focus on design and the purpose of the change.
  4. Agree on a deadline. A response within one business day is a sensible ceiling. Review during natural breaks, not at the expense of focused work.
  5. One reviewer is enough. Google's median is one. More people on every PR multiply waiting, not quality.
  6. Measure the wait. Track how long a PR sits from opening to first response and to merge. Without a number, "slow reviews" are just an opinion.

How mcptask.online helps

In mcptask.online you break work into Epic → Story → Task with scrum points that automatically produce an hour estimate, so small tasks with acceptance criteria become the default rather than the exception. A GitHub or GitLab webhook pairs commits and pull requests with tasks; a commit with a task reference logs time, and merging the PR can complete the task – so the reviewer always has the requirement at hand and you see where work is stuck. Tasks from Jira, Trello or Redmine can be imported.

The same task queue can also be worked by an autonomous AI developer (the runner). It creates a branch from the task, writes code and tests, runs them and opens a pull request. In manual mode the PR stays open for your review, and the runner can also address review feedback on it; in auto-squash mode it merges only after green tests and checks. Your developers then review small, tested changes with a clear requirement – exactly the kind of review the data shows works best.

Want fast reviews and a clear view of the work? Sign up at mcptask.online – the first 30 days are free, no credit card required.

Sources

Related articles