Stop painfully long code review turnaround times
Read my five tips to boost your turnaround times
Long code review turnaround times drastically reduce developer experience. When developers wait long to get feedback on their code changes, cycle time increases, and developer productivity and well-being decrease. It’s painful when you only get feedback when you already forgot what you did in this code change.
Long turnaround times lead to large reviews.
In addition, long turnaround times often lead to large reviews. If developers know they must wait days or weeks before someone looks at their code changes, they cannot afford to submit small, coherent changes. Then, instead of breaking up user stories and working iteratively and incrementally, developers implement the whole user story and ask for feedback only once they are done. Also, they might add more and more commits to the user story while the pull request is open because time passes, nobody looks at the PR, and they have to get on with their work.
Large PRs lead to long turnaround times.
Developers have difficulty giving valuable feedback when the code review size increases. Several studies show a direct correlation between review size and feedback quality. The larger the review, the lower the review feedback quality. In large reviews, fewer bugs are detected, and fewer readability or maintainability issues are discussed.
In addition, large reviews also lead to an increase in review times because reviewers have a hard time understanding this large code change, and problems that are found might be hard to resolve. So, the vicious circle of long waiting times and large reviews continues.
So, how can we break this cycle?
5 Tips for faster code reviews
To increase the code review turnaround time and still keep your review process thorough and effective, I recommend the following five tips:
Break Up User Stories: In my experience, user stories tend to be too large. So, break them up into smaller pieces. Make sure each user story can be reviewed independently and, as a rule of thumb, does not take you more than two days to work on. This means that instead of waiting for an entire feature or project to be completed, break it down into smaller, more manageable user stories.
Code Review Checklist: Using a code review checklist does not only boost your problem-detection power but also streamlines the process of reviewing. By using a checklist vetted by the whole team, you ensure everyone knows what issues to look out for. This clarity also comes with a nice boost in code review turnaround time.
Integrate Linters and Static Analysis Tools: Tools like ESLint, Flake8, or SonarQube can automatically catch common mistakes and enforce coding standards. To ensure you are not cramping up your CI/CD pipeline, use pre-commit hooks to ensure that only code meeting these criteria is pushed to the repository.
Clarity for code review duties: All team members must clearly understand their expected role in code reviews. This fosters accountability and a collective commitment to code quality. Further, the team should work out a schedule around code reviews to help people plan and make sure they have the time to do a proper review. So, a code review should never (or very seldomly) come as a surprise.
Select fewer code reviewers: Yes, you heard that right. Instead of adding more potential reviewers, I’d advise selecting only a few. If too many reviewers are listed on a code review, you might find yourself experiencing the “diffusion of responsibility” phenomenon. This means that everyone thinks that someone else will do the review. Because everyone waits for another person to do the review, the code review turnaround time increases.
More stats to convince you
In a recent study, which I’ve conducted together with Nicole Forsgren, Eirini Kalliamvakou, and Brian Houck from Microsoft, Dr. Storey from the Univeristy of Victoria, and Abi Noda from DX, we could clearly show the impact a fast turnaround time has on team and business outcomes.
As you see in the illustration below, a faster turnaround time increases innovation by 20%, boosts creativity and learning by 15%, and even reduces technical debt by 10%.
Cool, ha?!
To know more about this study, read my previous issue on measuring developer experience here.
So, what are your best tips for a faster turnaround time?
Hit reply and let me know, or share your thoughts on Twitter with me: https://twitter.com/mgreiler.