Non-Blocking Continuous Code Reviews - a Case Study

The problem with the current most common way of implementing code reviews using Pull Requests is that they have the nasty habit of blocking the flow of delivery.

The usual way to achieve fast Continuous Code Reviews without disrupting the flow of delivery is through Pair Programming or Team Programming. But not all teams or individuals are open to this for various good reasons.

In this session, I’ll explain how, in 2012, a novice team practising trunk-based development found an efficient uncommon way to implement continuous code reviews on mainline without ever blocking the flow of delivery.

Transcript

1. in/tdpauw @tdpauw.bsky.social @tdpauw@mastodon.social thinkinglabs.io Non-Blocking Continuous Code Reviews Thoughtful Thierry 2021 Ghent lightening festival Kunsthal Gent Lange Steenstraat
2. Why are we doing Code Reviews? 🤔
3. But few teams have made a conscious decision about what they want to achieve with their code reviews. – Pia Fåk Sunnanbo, I Hate Pull Requests
4. My reasons … • Mentoring, learning • Knowledge sharing • Check on readability and maintainability • Maintain consistency in design My reasons … • Mentoring, learning • Knowledge sharing • Check on readability and maintainability • Maintain consistency in design (that was a mistake, should have been a design workshop)
5. Other reasons …
6. 4-eyes principle Killer argument to slow everything down and drive down quality. Pair or Team Programming are more effective
7. “Sense” of security. I don’t trust my code. Dilution of responsibility. -> won’t be fixed by a process
8. What Code Reviews should not be?
9. • By seniors missing mentoring skills • Blaming or harming • A miserable experience • Gatekeeping • A must • Exercise power
10. Non-Blocking Continuous Code Reviews
11. A Team’s Tale
12. Two key ideas … Establish a continuous review process.
15. If we commit changes directly to the remote mainline, we have unreviewed code alongside reviewed code.
16. Second key idea … Stop the code review being definitive for release.
17. Unreviewed code could end up in production, whether the feature was finished or not.
18. Unreviewed code ≠ a bug !! => automated and exploratory tests catch bugs
19. The unreviewed code is code that works. It passed all tests!
20. Benefits
21. Transaction Cost the cost of sending a batch to the next stage
22. thinkinglabs.io @tdpauw@mastodon.social @tdpauw.bsky.social It it takes 10 min to make a change, the change is blocked until it is reviewed and it takes 2 hours to get a review … 92.3% wait time 😳 High cost of code review! => ask less often for a review 🤷
23. Expensive process works against making small changes -> less refactoring -> less incremental development
24. the wait time incentivises Work in Progress
25. Little’s Law the higher the WIP the more delay
26. To get something out sooner … need to reduce the transaction cost! Minimise the cost of code review.
27. Benefits (bis)
28. Transaction Cost is nearly zero. => work in small increments
29. With Non-Blocking Code Reviews we never slow down, changes are never blocked for delivery. No gating!
30. With Non-Blocking Reviews we have early, fast feedback.
31. With Non-Blocking Code Reviews no new work is started before finishing. => less Work in Progress => because Little’s Law: less delays
32. With Non-Blocking Code Reviews no pressure to improve code quality. Nobody is waiting.
33. With Non-Blocking Code Reviews there is high trust.
34. Tooling
35. • We used: Atlassian Crucible (discontinued)
36. • JetBrains UpSource (discontinued) • Facebook Fabricator (discontinued)
37. • Gerrit (review Git repo in front of main Git repo)
38. • Auctionet Ex-remit (barsoom/ex-remit on GitHub) • ReviewBoard (similar to Crucible)
39. • Or … no tooling at all 🤷
40. Gotcha with Non-Blocking Code Reviews
41. It does not work for regulated industries. => Pair or Team Programming is the better solution
42. Conclusion
43. Pair or Team Programming are still a superior delivery option. But can be a cultural stretch.
44. thinkinglabs.io Non-Blocking Review strategies are significantly better than any of the alternatives. • No gating • Deliver faster without delays • Less WIP • No context switching • No urgency to fix quality issues • Features grow incrementally, commit by commit • Encourages refactoring
45. in/tdpauw @tdpauw.bsky.social @tdpauw@mastodon.social thinkinglabs.io Acknowledgments: Stefan De Moerloose (https://linkedin.com/in/stefandemoerloose/) for having been that amazing team manager open to try out all our crazy ideas. Dave Farley (@davefarley77) for nudging me to write this down. Giovanni Asproni (@gasproni@mastodon.social) for poking me to turn this into a positive story. Lanette Creamer, Wouter Lagerwije, Diane Gombart, Falk Kühnel and Steve Berczuk for reviewing the slide deck. Laphroaig and Bunnahabhain for the creative support. The Article: https://thinkinglabs.io/articles/2023/05/02/non-blocking-continuous-code-reviews-a-case-study.html Hello, I am Thierry de Pauw
46. Resources Optimizing the Software development process for continuous integration and flow of work, Martin Mortensen The Article: Non-Blocking Continuous Code Reviews, a Case Study, Thierry de Pauw Code Complete, Steve McConnell Facts and Fallacies of Software Engineering, Robert Glass Joel on Software, Joel Spolsky What is the purpose of Code Reviews, Thierry de Pauw, a discussion on LinkedIn I’ve found something better than PRs, the video from Dave Farley on the topic From Async Code Reviews to Co-Creation Patterns, Dragan Stepanović I Hate Pull Requests, Pia Fåk Sunnanbo Problems with Pull Requests and How to Fix Them, Gregory Szorc On the Evilness of Feature Branching - But Compliance, Thierry de Pauw How to make sure tests are of quality, Thierry de Pauw, a discussion on LinkedIn