Async code reviews are reducing company throughput. Engagement is lower on larger pull requests due to delayed feedback. Wait times increase significantly as pull request size increases. Continuous code review through pairing or mob programming would improve throughput by providing immediate feedback and keeping pull request sizes small. The goal should be to optimize for constant cost of code review per line of code to maintain throughput.
8. “Never had a 300+ LoC PR that
didn’t look good to me”
~ Anonymous Developer
9. Why was I curious about the engagement?
● Feedback delayed and ‘choked’ by the system
● High-latency, low-throughput feedback
vs
Low-latency, high-throughput feedback
● Engagement by size?
○ Only counting non-trivial comments (no LGTM)
15. A couple of important assumptions and facts
● Processing Time and Flow Efficiency on the bigger size PRs end of the
spectrum inaccurate because of git rewrite practice
● Wait Time way more accurate
● Wait time can have processing time
● Processing time can have wait time as well
● PR size is measured through simple LoC changed
45. We’ve been told all along that
we’ll achieve more if we limit
and delay our interactions
Hope you now have (also)
a data-informed reason to
not believe that
We’ve been told all along that
we’ll achieve more if we limit
and delay our interactions
46. ● If you’re interested in trying out the tool for free?
dragan.stepanovic@gmail.com
● The idea of the tool is to provide you value to change your process so you don’t need the
tool anymore
● Only Github supported currently
● I’m writing a book (intersection of XP, Lean, ToC, Systems Thinking)
● If you’d like me to speak to your community about this topic, Small Batches and/or Intro to
ToC, Systemic Advantages of co-creation, let me know