Code reviews taking too long? Here are 7 ideas for preventing PRs from getting stuck

Long code review times are a common problem in teams, and if tasks are left in the "Review" column for several days, it can be a red flag. Often, this happens due to poor code review culture, insufficient focus on delivery, or a lack of understanding of Work in Process (WIP). In this blog post, I will offer some ideas for addressing this issue.

Idea #1 - Limiting Work in Process (WIP)

Work in process (WIP) refers to partially completed goods that are typically turned from raw materials to finished products within a short period of time[1]. In the context of software development, WIP refers to tasks that have been started but not yet completed. Long code review times can lead to a buildup of WIP, which can be detrimental to productivity. One way to address this issue is to impose limits on the number of WIP items.

For example, a team I read about added limits to their Kanban board for the number of tasks that could be in progress at any given time[2]. For a team of 10 people, there were only 6 slots for "in development" tickets, with one of those reserved for hot fixes (such as dealing with a new vulnerability). This rule encouraged more pair programming sessions and greater focus on finishing existing work and unblocking others, resulting in faster code reviews that were typically completed within 2-3 hours.

Idea #2 - Making PRs easy to review

One way to address long-running code reviews is to make the PRs easy to review. This can be done by keeping them short (ideally under 400 lines of code) and providing clear explanations in the PR description of why the changes are needed and what they do. Additionally, including screenshots or short videos for visual changes can be helpful. By minimizing the cognitive load and risk of the unknown on the reviewer, you can speed up the review process.

Idea #3 - Marketing your PRs and communicating with your reviewers

Marketing your PRs can also be effective in getting them reviewed. For example, you could say "who wants to review a 10-line code change to fix..." or "this small PR introduces a feature that will...". Communicating with your reviewers is also important. Using a template for each task can help facilitate this communication:

[DX1-1111: Refactor interface types in right panel](https://gitlab.com/project/mr)

Estimated review time ⌚️: 30 min | Files 📁: 2 | Lines 🗒️: +53 -13 | Commits ⚡️: 2

Effective communication is crucial for success. If a review is taking longer than a day, consider privately nudging the engineer. For large PRs, offer to talk through the code with the reviewer to make the review process easier.

Idea #4 - Analyse root cause

Slow PRs are only symptoms of underlying problems. There are several points to consider when trying to identify the root cause of slow PRs in your team:

• Ask developers individually what is the reason for the delay.
• It could be that only a few teammates are doing most of the code reviews, and the workload should be distributed more evenly. You could try using a round-robin approach to distribute reviews more evenly.
• It could be that one toxic reviewer is making endless nitpicking comments and blocking merges.
• PRs might require a lot of contextual knowledge that only the author maintains, which could slow down the review process.
• Feedback might often be argued over or ignored, making the review process a waste of time.
• Developers might perceive their work to be more important than that of others, leading to delays in the review process.

Identifying the root cause of slow PRs in your team can help you solve the problem more effectively.

Idea #5 - It doesn't need to be asynchronous

One potential solution to slow PRs is to conduct synchronous reviews, where the reviewer and author go through the changes together in real-time and only stop when the PR is properly reviewed. This approach can be faster than asynchronous reviews, as it allows for immediate feedback and discussion. It also helps to spread knowledge, as the review process becomes a learning experience for the coder. However, this approach may require more meetings, which could be time-consuming.

Idea #6 - Prioritize

Prioritizing code reviews is essential for ensuring timely reviews and addressing any issues before they become larger problems. Teams should make code reviews a top priority and focus on reviewing any open PRs before starting new tasks.

To make this approach effective, teams should allocate specific time for reviews and set expectations that reviews can interrupt other work. This may mean conducting reviews early in the morning or at times when the team is not working on other tasks.

Using a kanban board can be helpful in making reviews visible and ensuring that team members feel pressure to complete them. This can prevent reviews from feeling like invisible work and give them the attention they deserve. It's important to communicate to the team that this work is valuable and contributes to the overall success of the project.

Idea #7 - Avoid pingpong

Endless discussions in GitLab threads can be frustrating and slow down the review process. One potential solution is to avoid ping-pong discussions by ensuring that reviews are thorough on the first pass. This can be achieved by enforcing formatting rules and having a clear style guide that everyone on the team follows. This can minimize unnecessary discussions and help to streamline the review process.

Another way to avoid ping-pong is to have a clear set of criteria that PRs must meet before they can be approved. If the criteria are not met, the reviewer should clearly explain why and what needs to be done to meet them. Additionally, it's important to avoid blocking PRs with nitpick comments. If a comment is not essential to the review, it may be best to avoid it altogether to prevent ping-pong discussions.

Short Summary

By taking these steps, you can help to ensure that reviews are thorough and completed in a timely manner, without slowing down the process with endless discussions and nitpicking.

If you want to change the code review culture, start with yourself. Review PRs promptly, and provide actionable feedback such as "I'll be happy to review your PR" or "It would be helpful if it's less than 50 LOC next time". This can help set an example for the rest of the team and encourage more efficient code reviews.

In this blog post, we have explored 7 ways to prevent code reviews from getting stuck and speed up the process. This includes limiting work in progress, making pull requests easy to review, using effective communication and marketing techniques, analyzing the root cause of slow code reviews, conducting synchronous reviews, establishing clear guidelines and expectations, and investing in tools and automation. By implementing these strategies, teams can improve the efficiency of their code review process and avoid delays.

Bullet points summary:

1. Limit work in progress to prevent code reviews from getting stuck
2. Make pull requests easy to review by providing clear explanations and visual aids
3. Use effective communication and marketing techniques to attract reviewers
4. Analyze the root cause of slow code reviews and address underlying issues
5. Consider conducting synchronous reviews for faster feedback and knowledge sharing
6. Prioritize code reviews.
7. Establish clear guidelines and expectations for code reviews to streamline the process.
8. Limit pingponging. Don't block PR's with nitpick comments. Invest in tools and automation to improve the efficiency of code reviews.

[1]: Work in Process vs. Work in Progress: What's the Difference?
[2]: Reddit thread
[3]: Move faster, wait less: Improving code review time at Meta