What if I said you could:
- Develop features faster
- Find bugs earlier
- Have less context switching
- Increase overall developer happiness
What if I told you all it takes is to not require PR approval before merging?
I would not blame you for being skeptical. You should be skeptical. Heck, I was skeptical until I saw it in action.
BridgeCare: a case study
BridgeCare is a small but growing software organization. They develop top-of-the-line solutions for early childhood education providers.
They are an awesome group of people and I've had the privilege of working closely with them this past year. Their super power is developing quality software quickly.
The Problem: Code Review Purgatory
Code reviews were becoming a bottleneck in BridgeCare's development process.
"We were observing pull requests requiring cycling that didn't have any added value, e.g., someone "requests changes" for some trivial update--update is made, review is re-requested but now the person is OOO. Or upon reviewing again, has other small nits that don't have any meaningful import in terms of code quality or feature intent, but are more stylistic or preferential," said Hannah Briggs, director of engineering at BridgeCare.
"This led to a pattern of PR authors being used to not being able to ship code, and leaving PRs open for days and sometimes weeks," Briggs continued. "Then they'd have to be perpetually nudged to merge their code and/or had context switching costs by the time they got back to it."
I'm sure you can relate to this: Code review can be a slow and frustrating process. You first need to get someone's attention or even multiple people's attention. Everyone is busy juggling multiple tasks and deadlines of their own and may need to carve out space in their schedule. This problem is made worse if your team is spread across different time zones. It’s not uncommon to have to wait a day or two before someone can start reviewing your code, let alone finish reviewing it. If your reviewer happens to be on vacation, you could be stuck in limbo waiting for their return.
The frustration only deepens when your next task is dependent on the code under review. These delays not only slow down progress but also add to the mental load of managing dependencies in a project.
... branch[es] lives longer than anticipated. Because of the classic ping-pong happening between the reviewer and the reviewee. The reviewer is not immediately available. This causes the pull request to wait. Meanwhile, the reviewee starts new work to keep themselves busy. Once the reviewer has finally reviewed the pull request, it is now the reviewee who is not available.
- Thierry de Pauw - On the Evilness of Feature Branching - What about Code Reviews
The Experiment
BridgeCare wanted to try a different approach. While established norms tell us to wait for review before merging, they were like - what if - what if we didn't require PRs to have sign-off before merging.
Here's the experiment as it was shared with the team:
We are doing a science project for ~3 weeks to see if adjusting the way we deliver code increases productivity, value and joy 🧑🔬. Creating software should be fun - we want to eliminate things that reduce joy.
Hypothesis: Removing required PR review will increase velocity, accountability, and feelings of stewardship/ownership and MORE JOY!
- Code reviews are encouraged but not required
- Pairing or mobbing on large or nuanced efforts is encouraged
- Building trust with teammates through communication and consensus-building about key/structural updates is essential
- Automated tests are essential to earning trust. Changes without test changes are highly suspect. With less time delays on code reviews, we expect there to be more time to write thorough tests.
- All CI checks must pass before merge
The Results
At the end of the three weeks they ran a poll, and the response from developers was overwhelmingly positive. They loved that they were given the freedom to merge without waiting and that they felt trusted to know when a PR should or shouldn't require review(s).
Developers were still choosing to wait on reviews much of the time. Only small predictable changes were bypassing the PR review process.
Features were getting to QA faster thus allowing for shorter feedback loops and opening the potential for bugs to be caught earlier.
Not only that, but this process change didn't lead to downstream problems. There weren't any bugs or issues that they could point to and say "well if we had required code review on the PR this wouldn't have happened".
As of today, months after the change, the experiment is still running successfully.
What makes non-mandatory code reviews work for BridgeCare?
Here are some things I think contributed to BridgeCare's success:
- CI/CD
- Good test coverage
- Linters
- Linters and tests must pass before merging is allowed
- Trunk-based development
- Code is deployed to a pre-production environment on merge to main. It doesn't go straight to production.
- Anything user-facing will go through QA as part of the release process
- All code is eventually reviewed - at least skimmed before inclusion in a production release
- Not a ton of code to review between releases
- Production releases happen weekly
- Small dev team
- One of their core values is: "We respect and believe in each other"
I wouldn’t say all of these are requirements for making the process work, but they probably all helped at some level.
Conclusion: Should code review be mandatory?
BridgeCare is a great example of an engineering org that is willing to experiment and innovate. They are willing to question the established norms and see what works for them versus what doesn't.
I encourage all of y'all to try experimenting like this yourself. It may not always turn out, but you don't know if you don't try.
Also this has me thinking... Could a change like this work for everyone? Should code review be mandatory? See more here.
