8 Decreasing code review delays
This chapter covers
- Why code reviews take too long (and what to do about it)
- What to do about the “single senior developer reviewer” problem
- Knowing when to take discussions offline
- Uncovering gaps in other parts of your development lifecycle that result in gargantuan pull requests (and how to fix them)
Good code reviews take time—but not too much time, or everyone will hate them. It’s a fine line between giving a review its due diligence and delaying the whole development workflow altogether. Take too long to get a PR opened (or ready, which are two different things!), and code reviews become bottlenecks. Take too long during the review, and it delays the value to your people. It’s a lose–lose situation when you’re experiencing both.
It should come as no surprise that code reviews that take too long are a common reason [1] developers don’t like the process [2]. But why do they take so long? Most causes are within our control, some are not (but we can try to mitigate that), and others are just plain excuses (shock!).
This chapter focuses on all of those pesky stealers of time and offers suggestions on what to do about them. After examining each one, you may find that there’s actually a snag somewhere else in the process, with consequences only coming to light during the code review. In the end, we’ve been unfairly using the code review as the scapegoat for time delays.