Async Code Reviews Are Killing Your Company’s Throughput

Speaker: Dragan Stepanović
Recorded: 2021-12-14
00:00 Intro
05:22 The Talk
59:14 Questions & Answers
"Never had a PR over 300 LoC that didn't look good to me". We've all been there. The PR is so big you don't even bother commenting. It's already too late to build the quality in. You make a sad face, comment "LGTM", and click approve.
That's still the case in lots of teams but feels like after a long time the industry, on average, learned the value of the Small Batches idea from Lean applied to PRs. And that's a good thing; it's a step in the right direction.We do a bit of coding, raise a PR and then ask for feedback. People are more likely to engage on smaller PRs. It takes them less time to review it, and they have a feeling that they can still course-correct if something goes astray. PRs go sooner out of the door, and we feel productive as a team.
But, here's the surprise. What if I told you that teams doing small PRs (with async code reviews) actually have way lower throughput than teams doing big PRs.
"Wait, what?!" Yes.
I got this surprising systemic insight from analyzing PRs across a bunch of very active repositories and I'll present you with the results of the study.On the bigger PRs side of the spectrum, we tend to lose quality, while on the smaller PRs end of the spectrum we lose throughput. We're forced to make a trade-off between speed and quality.
But! There's a parallel universe of ways of working where you get to have your cake and eat it too. Where you can have both throughput and quality. That universe is called co-creation patterns (Pair and Mob programming).
Join me on a journey where I'll show you data invalidating the assumption that two or more people sitting at the same computer will hurt our throughput and why the opposite is actually the case.
Dragan is currently a principal engineer at HelloFresh, one of the unicorns of Berlin's thriving start-up scene. Before HelloFresh he helped Careem/Uber build the largest loyalty program in the MENA region, drive architecture, technical strategy, and shape engineering culture.
Typically on the search for better ways of working, exploring ends of the spectrums, and helping teams and organizations try out counter-intuitive ideas that initially don't make a lot of sense, but end up as completely opposite of that.
It's been a long time since he fell in love with eXtreme Programming, Domain-Driven Design, and software as a craft (founder of Software Crafting Serbia community).
In last couple of years he enjoys endless discussions connecting the Theory of Constraints, Systems Thinking, Lean and socio-technical topics.
Twitter: @d_stepanovic
Organized by: Java User Group Switzerland and Software Crafts Romandie
www.jug.ch/

[@anitsh]

Interesting and insightful conversation on PR sizes.

[@BerndGoetz]

@d_stepanovic - thanks a lot! Great work to support pair and mob programming practices to speed up product development time. Awesome!
There is one caveat though I try to bend my head around: There's not only writing code - there is analysis work, understanding the business background, developing domain models, planning release and Sprints, onboarding of new team members, running retrospectives, doing line management activities, attending top down company communications, etc. How to weave this into the overall picture?
Don't get me wrong, I'm a big fan of lean, flow, WIP limitation, etc. - that all makes total sense. I just need solid content to explain to my product managers that humans are bad at multi-threading and that it's bad for the overall productivity.

[@draganstepanovic472]

Thanks, Bernd for the question. This talk, even though it talks about async code reviews, is actually a talk about the async work in general. We, as an industry, and when it comes to the way of working have moved to the far extreme towards the async end of the spectrum. And the conclusions of the study here would be my conclusions of that way of working.
I'm not saying that every company needs to work fully sync, but being at the far end of the async spectrum is something that we wouldn't want to have.
The core reason of chocked flow, low throughput and quality in async way of working is the amount of inventory that piles up between people involved in the process (documents, PRs, backlog items, user stories, bugs, etc.). All of these serve to decouple in time sender and receiver(s) and they represent the inventory in the system, which causes huge problems with delays, which incentivize increase in the batch size ("If I'm waiting long to get a hold of another person, next time when they become available I'm going to batch a lot of things because I don't know when's the next time I'll get a hold of them") and pulling in more WIP ("While I'm waiting let me start something else"), delayed feedback loops, failure demand, chocked flow, low quality, etc, etc.
The answer is collapsing the dependencies and getting people to work more together. Meaning starting, doing and finishing work together, which accelerates the feedback loops, thus builds the quality in and also prevents inventory from piling up.
It sounds as a generic answer, but that's the general idea and it's valuable to consider what these means for your own context and how to apply them.
Hope this helps.

[@BerndGoetz]

It might be you're starting a new movement - the "Work Sync" movement 🙂 - I'm part of many PR and I can confirm that with PRs wait time/waste is dramatically increasing.

[@draganstepanovic472]

@@BerndGoetz I think we're headed toward the async work extreme end of the spectrum, which has been somehow accelerated by remote work.
Sadly, there's a huge confusion in our industry where remote has very often been conflated with the async work (we can be both remote and work sync), while not understanding the impact on the whole system.