Yes, you can measure software developer productivity… but are you sure that’s what you’re measuring or want to measure?
McKinsey wrote an article “Yes, you can measure software developer productivity” (Aug 2023).
Gergely Orosz and Kent Beck responded in 2 parts: Part 1 and Part 2.
Dan North responded.
Here’s my response.
Argument: We should use quantitative measurement and not just rely on expert opinion to assess developer performance.
The long-held belief by many in tech is that it’s not possible to do it correctly — and that, in any case, only trained engineers are knowledgeable enough to assess the performance of their peers.
One of the overall arguments McKinsey makes is that we should use quantitative measurement and not just rely on expert opinion to assess developer performance.
This seems reasonable.
“Facts” over “data”
This does remind me though of something said by Taiichi Ohno:
Data is of course important in manufacturing, but I place the greatest emphasis on facts.
What Ohno is talking about is the importance of direct observation, not just looking at numbers in a spreadsheet, to be able to interpret what is actually happening.
Quantitative data might be useful to assess developer performance, but I’d also want direct observation, including from the developers themselves, to be able to interpret what is actually happening.
Argument: Different productivity metrics are required for different levels (individuals, teams, systems)
To use a sufficiently nuanced system of measuring developer productivity, it’s essential to understand the three types of metrics that need to be tracked: those at the system level, the team level, and the individual level.
McKinsey suggests that productivity should be considered at the individual, team, and system (aka organisation) levels.
I’ve made a similar argument with some posts I wrote:
