“What improves developer productivity?” is the wrong question
I’ve noticed people sharing this Google paper “What Improves Developer Productivity at Google? Code Quality”.
I didn’t find it that interesting.
Product development productivity is not just the sum of the productivity of individual participants
The simplest model to explain this comes from the Theory of Constraints.
Let’s imagine a simple scenario with 3 participants (A, B, C). The work flows through person A to person B and finally to person C before it is completed. However, for whatever reason, it takes longer for B to complete their activity than A. This means that a bottleneck will appear at B.
So, what can we do?
- Focus on improving productivity and utilization of bottleneck B;
- Limit incoming work from A to avoid overwhelming B AND make sure B is never having to wait for anything;
- Work on improving the capacity at B: A and C can pitch in and/or take over lower priority tasks, add more people at B, etc.
What doesn’t matter?
When there’s a bottleneck at B, any productivity improvements to A or C will have no impact on overall productivity. Overall productivity is constrained by the performance of B.
Increased coding activity is a poor proxy for measuring productivity
Let’s imagine the overall product development system as a black box. What does it mean for that box to be “productive”?
Productivity is the rate of output per unit of input.
Roughly the input is the number of people involved and the output is how many valuable things come out, aka throughput.
Productivity is higher when there is more throughput for the same or fewer people involved OR the same throughput for fewer people involved.
Generally increased coding activity doesn’t mean higher throughput, especially given potential bottlenecks.
So, what’s worth measuring if you want to measure productivity?
- Cost (aka the number of people involved) (INPUT)
- Throughput (# of things delivered) (OUTPUT)
- Quality (so you’re not fooled by increased throughput of things that don’t work) (OUTPUT)
I’d also suggest measuring lead time, which isn’t technically productivity, but is valuable to measure responsiveness.