This is the third installment of our Cycle Time Breakdown series on the most effective tactics to speed up your development Cycle Time. The other posts are:
- Tactics For Reducing Coding Time
- Tactics For Reducing Pull Request Pickup Time
- Tactics For Reducing PR Review Time ← You are here
- Tactics For Reducing Deploy Time
Table of Contents
- The Issue
- What’s A Good Review Time?
- Causes of High Review Time (And How You Can Address Them)
- The End Result
The Issue
Before a delta can be merged into the source code, it needs to be reviewed to find defects and to ensure that it conforms to a team’s general principles for style and organization. In practice, reviewing code can often end up being a bottleneck. A developer will start a review, then get pulled into another task. They can end up forgetting about the review all together. This means that instead of new code being deployed and improving the application, it just sits there, doing nothing.
Review Time is one of the four components of Cycle Time. When teams start using LinearB, they are often surprised to see just how long reviews are taking.
What’s A Good Review Time?
We got this question a lot from our customers. So we went out and got the answer.
We analyzed data from almost 2,000 teams and over 847,000 branches to establish benchmarks for key engineering metrics, including Review Time. You can see the results in the table below.
Elite teams typically take less than 6 hours for PR code reviews; strong teams take up to 13. A good rule of thumb is to keep your review times to less than 12 hours. If a PR is created in the morning, it should be reviewed by the end of the day. If it’s created in the evening, it should be reviewed the following morning.
Causes of High Review Time (And How You Can Address Them)
There are four main causes of high review times:
- The pull request is too big
- The team has too much Work in Progress (WIP)
- The team gets diverted into other work
- Too few people are assigned to do reviews
- The review has been forgotten about
Pull Request Is Too Big
As we talked about in the post about pull request pickup time, people are reluctant to review big PRs, and with good reason. A big PR means that there are going to be lots of code changes to go through. Not only that, but a big PR usually signals that the reviewer is going to have to parse multiple kinds of changes. For example, instead of just making sure the author updated the design of one button in all the right places, they have to check that and whether the author also properly handled errors in a new authentication flow and improved logging and properly added tests cases and…Keeping track of all these different kinds of changes makes it harder to conduct effective code reviews.
Here’s the mantra to keep in mind: Commit small, commit often. The more precisely you scope a PR, the easier it is to review and the faster it can get into production. Based on our analysis, the best teams keep PR sizes below 225 lines of code, and strong teams less than 400 lines.
LinearB can help your team drive down the size of your PRs. You can track PR size in a custom dashboard and you can set up WorkerB alerts so that you know when a big PR has been created.
Too much WIP
Reviews are often de-prioritized in favor of other work, like creating your own pull requests that have changes that you’ve made.
This is because engineers are misunderstanding how reviews fit into the broader software development lifecycle (SDLC). Code that needs a review is at the finish line, waiting to be allowed across and to start adding value. Every hour a review is put off, is an hour less that a new chunk of code has to improve the application.
In addition to resetting your team’s understanding of PR reviews, as a team lead you should also make sure that your developers have the bandwidth for reviews. Otherwise, your efforts to get them to conduct reviews more quickly may lead to resentment because it’ll feel like you’re just asking them to do more work. You can help them to meet your expectations by introducing a standard code review checklist.
You can also leverage LinearB. With LinearB’s People metrics, you can see where your team members are spending time so that you redistribute work or help individuals better allocate their time. Burnout is a serious concern among fast-moving development teams, which is why we built out functionality to alert you if a member of your team has maybe taken on too much work.
Diverted into other work
A bug is discovered, and a patch needs to be made. A high-priority feature request comes down from the CEO. There are million and one things that can arise out of the blue and demand immediate attention from your team. When this happens, all other work, including any reviews they may have been working on, get put on the back burner.
Too few people are assigned to do reviews
To maintain high quality code, PR reviews are an indispensable tool. But this pursuit of quality can sometimes go too far.
Some teams limit the number of people who can review PRs, usually the more senior members of the team. This is well-intentioned. It ensures that only high quality code gets pushed into production. It also helps reviews serve as learning tools.
But it can result massive bottlenecks, with review requests piling up on just one or a few people. You improve code quality, but this comes at the expensive of much slower cycle times.
On the Dev Interrupted podcast, Maria Gutierrez, VP of Engineering at Slack, explained how she learned the importance of “diversifying responsibility” in engineering orgs. By making it easier for the rest of her teams to review and deploy code, she transformed how they worked.
There’s a reason many teams call PR reviews “peer code reviews.” When peers review one another’s code, you help everyone broaden their knowledge of the code base, empowering them to work on more areas and making your application more resilient.
The review has been forgotten about
It happens…a lot. A developer starts a review, then has to jump to another task, and forgets to come back to the review until either they randomly remember or more likely the PR submitter pings them. Days and weeks can fly by as a review is still “in progress.”
This is a serious problem but an avoidable one. LinearB’s WorkerB automation bot can send out alerts to let people know that a review has been sitting idle. This ensures that the review gets completed, greatly reducing code review time, and it saves time for the other members of the team because they don’t have to do the reminding.
The End Result
The PR Review stage is a bottleneck for lots of engineering teams, but it doesn’t have to be. By ensuring that your team understands the value of prompt reviews, distributing responsibility, and leveraging a tool like LinearB, you can improve your code review process, drive down your teview times, and speed up your cycle time.
One of our customers, Unbabel, an artificial intelligence-powered human translation platform, saw a 40% decrease in review time when following these principles while using LinearB.
Want to learn how to implement custom dev workflow automation to cut code review time by up to 40%? Watch this hands-on workshop to set up the free gitStream tool to automatically:
Classify and route pull requests Add estimated review time to PRs Apply custom rules
gitStream product lead, Ofer Afias, will take you through a live demo of the three core functions when getting started with gitStream workflow automation to scale your team efficiently and improve your developer experience.
