Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Non-Blocking Continuous Code Reviews - a Case S...

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.

Thierry de Pauw

February 06, 2024
Tweet

More Decks by Thierry de Pauw

Other Decks in Technology

Transcript

  1. 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
  2. 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)
  3. 4-eyes principle Killer argument to slow everything down and drive

    down quality. Pair or Team Programming are more effective
  4. “Sense” of security. I don’t trust my code. Dilution of

    responsibility. -> won’t be fixed by a process
  5. • By seniors missing mentoring skills • Blaming or harming

    • A miserable experience • Gatekeeping • A must • Exercise power
  6. If we commit changes directly to the remote mainline, we

    have unreviewed code alongside reviewed code.
  7. thinkinglabs.io @[email protected] @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 🤷
  8. To get something out sooner … need to reduce the

    transaction cost! Minimise the cost of code review.
  9. With Non-Blocking Code Reviews no new work is started before

    finishing. => less Work in Progress => because Little’s Law: less delays
  10. It does not work for regulated industries. => Pair or

    Team Programming is the better solution
  11. 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
  12. in/tdpauw @tdpauw.bsky.social @[email protected] 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 (@[email protected]) 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
  13. 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