How to speed up the code review process and prevent pull request from piling up

This week, MPJ addressed a question from one of his patrons:

How to manage pull requests in a team?
How to maintain the pull requests pile as low as possible while keeping the team focus high?

From one hand you want it to be reviewed as quickly as possible from the other hand you don’t want to create too many context switches to your team members…

Code reviews are a vital practice that helps to improve code quality, prevent bugs and share knowledge, however, it also could be an annoying bottleneck. In this post, I share my experience addressing this problem.

Is it worth it?

Once on a retrospective, a member of the team where I was the team lead, raised a concern: “pull-request reviews take time and slow down the process, maybe we should make it optional?”.

You probably had this problem too: once a ticket is “done”, an engineer sends a pull-request to review and immediately switches to another ticket in the backlog. Other team members are also busy: they’re working on they own issues, so review doesn’t happen immediately. When someone finally submits a review, the pull request author is already busy on the new task, so they postpone addressing the review. In the worst case, the author will have a question to the reviewer. The reviewer is also busy or already left his workplace. The conversation takes days, pull-requests pile-up, engineers have to switch contexts back and forth which breaks the flow. So it’s valid to ask: is it really worth it?

Limit work in progress

Instead of agreeing on the most obvious solution I’ve proposed to introduce the work in progress limit. That is a technique that limits the number of issues the team can work simultaneously. To encourage collaboration and pair programming, the limit is usually less than the number of team members. Once an engineer sent a PR they have to review open pull-requests, help someone to finish their work or ask them to review the pull-request instead of switching to another task.

Despite the doubts, it helped to make not only a habit of reviewing pull-requests but also brought pair-programming into our day-to-day lives. My team was spread across a wide range of time zones, from Brazil to Indonesia. If someone submitted a pull request at the evening, there would be a great chance that it’d be reviewed when they wake up. Another side effect of the limit in progress was shared ownership. It was a common practice to address review comments to another team member’s pull request when they were away or busy.

Once pairing became a standard practice for us, we also adopted the pair reviews technique: the pull request author creates an ad-hoc call and invites other team members to it. One of the team members shares the screen, and they read the diff all together, ask questions and raise concerns to the author. It improved the quality and dramatically speeded up the process.

The actual problem

So that slow code reviews highlighted a bigger problem: we didn’t collaborate and did focus on our own piece of work, not project as a whole. Once we changed the mindset the problem disappeared and we have become better as a team.

If you want to see more stuff like that, follow me at Twitter!