The Issue

As a manager of a software development team, you are always under pressure to deliver value to the customer. In order to do that more effectively, you monitor your Cycle Time and work to keep it as low as possible so that features get into production as quickly as possible.

One of the issues that can be a bump in the road towards meeting that goal is Review Time. Review Time is defined as the time between the first comment on your code and the time it is merged back into the main branch. It’s the third phase of Cycle Time and keeping it inside proper boundaries is critical to keeping quality code moving through the pipeline.

Review Time is interesting because you don’t always want to make it shorter like Coding Time and Pull Request Review Time.

A good development team wants a solid review, one that is neither too short nor too long. A quality team will try to keep Review Time between one and two days. A Review Time much less than 24 hours likely indicates that an insufficient review has been conducted. A too-long review can mean a number of things, including the Pull Request is too large, the review is complex, or the review has been ignored.

LinearB provides an overview of Cycle Time for all your projects on the main dashboard that includes a clear indication of your Review Time status. This data-driven dashboard is based on the work committed to your code repository.

So how does this happen and what can you do about it?

Causes of High Review Time

Out of range Review Time can happen for a number of reasons

1. The team has too much Work in Progress (WIP)

2. The team has been distracted or pulled away by other work

3. Too few people are assigned to do reviews

4. The review has been forgotten

Too much WIP

If the team has too much work to do, they may tend to ignore Code Reviews in order to press forward with their overstretched schedule. This will lead to reviews taking longer than wanted, or for reviews to be superficial or ignored altogether.

The team is distracted by other work

Sometimes a senior leader or executive asks a developer for special work or to fix a specific bug, drawing them away from their regular work, causing Review Times to extend.

Too few people are assigned to do reviews

Some teams limit the number of people who can do Code Reviews, and this can cause a backup in getting them done.

We at LinearB recommend that everyone be encouraged to participate in Code Reviews. Obviously, the wisdom and knowledge of senior developers can help ensure that code is correct, but junior developers can also spot problems as well as learn from the process.

The review has been forgotten

Sometimes, just by error or happenstance, a review can be forgotten. Tracking Pull Requests through the review process is a manual process, with managers having to be alert for errant reviews. However, features like LinearB’s WorkerB can be used to automated team alerts and personal notifications for Slack and MS Teams in order to notify developers when a review has been forgotten for a configurable period.

How to Decrease Pull Request Review Times

Without a metrics tool, tracking Review Time and keeping code moving through the development pipeline can be a real bother. Reviews need to be tracked manually, emails need to be sent, and developers are bothered by flow-breaking communications.

This is where LinearB comes in — it can show you the information you need to see bottlenecks and automate almost everything involved with keeping Code Reviews moving. You can set up a custom dashboard explicitly for the purpose of tracking Pull Requests and Code Reviews.

Even better, you can set up WorkerB to immediately notify your team members about Pull Request events, helping them react more quickly to Code Reviews and drastically reducing Review Time.

If you are finding that your reviews are frequently too long, you can take these steps to shorten them:

1. Ensure that your Pull Request Size isn’t too big

2. Don’t allow reviews to languish

3. Ensure that completed reviews are merged right away

4. Reduce the team’s workload

Ensure that your Pull Request Size isn’t too big

Large Pull Requests make for difficult, and thus often long, code reviews. If a Pull request is large, developers will be hesitant to jump in and contribute. When they do, the size of the review may cause the review to take longer than desired. Our experience with customers at LinearB is that any Pull Request with over 200 changes will result in hesitancy by developers to do the code review.

Don’t allow reviews to languish

Sometimes a developer will pick up a review, but not act on it, possibly forgetting about the review altogether. WorkerB can warn about this via the Long Review notification.

Ensure that completed reviews are merged right away

A long review can occur if the review has actually been completed, but not merged back into the main branch.

Again, both WorkerB and the Pulse view can warn you about long reviews. Pulse is a view that shows you real-time updates for all your features in a single view by synchronizing your git branches and Pull Requests with your project management tool.

Reduce the team’s workload

Often a review will take longer because the team has a lot of Work in Progress (WIP) and thus developers feel they don’t have time to do code reviews. Perhaps the review gets started but never finished because team members are feeling the time crunch of too much WIP.

You can configure on a team-by-team basis how many tickets are considered too much WIP.

What to do when review times are too short

Monitor Review Depth

A factor in reviews that are too short is the notion of Review Depth. A too shallow review indicates that you either have a single contributor that only knows the code and that no one else understands the code, and the Pull Request simply gets approved without comment or too few comments.

Monitoring Review Depth can give you insight into why Review Time may be outside specifications. You can set up a WorkerB Team Alert to quickly notify everyone when a review is merged with the number of review comments below a level that you can determine.

Monitor PRs Merged with Basic Review

Another metric that can help reveal why reviews are too short is Pull Request Merged with Basic Review.

You can set up a WorkerB Team alert for this as well, ensuring that you are notified if a potentially insufficient review was merged.

The End Result

Keeping your Review Time “just right”, and thus keeping Cycle Time under control, is a critical means to continuously improving your software development process. By monitoring Review Time and ensuring it is within desired limits, you can see your Cycle Time drop like a rock.

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. Reduced Review Time means reduced Cycle Time, which means more value delivered to the customer sooner.

By ensuring timely Code Reviews and the proper processing of Pull Requests, you can create an environment where Cycle Time is low and value is delivered to customers in a timely manner. Tools like WorkerB can ensure that your team is informed about problems with respect to Review Time and take action accordingly.

LinearB can make such an environment happen, and happen fast. Our tool lets you recognize that there is a problem, dig in to find where the problem originates, and take the necessary steps to correct things. If you are not already using LinearB and want to do things like drastically reduce your Cycle Time and Review Time, sign up for a free demo of the product today!

Originally published at https://linearb.io on August 4, 2021.