The delusion of non-developers
Do you know that funny moment when someone talks about a topic and tries to sound smart, but you actually know more about whatever they’re talking about?
I usually get this feeling when talking to consultants or people in similar fields when they start talking about software development. I think they literally are the embodiment of fake it until you make it. Maybe after reading the following article by McKinsey, you’ll know what I mean.
NOTE
If you want to read it by yourself, here is the online version and here the pdf.
In the article, they write about their opinion on how to measure software developers’ productivity. This is obviously a very hard task, as even they acknowledge.
But with a title like Yes, you can measure software developer productivity, they seem convinced they’ve found the solution.
But let’s dive in.
Their approach
With their approach, they promise
- 20 to 30 percent reduction in customer-reported product defects
- 60-percentage-point improvement in customer satisfaction ratings
I’m not sure how that is feasible, or even relevant to the title of the article. Weren’t we supposed to be talking about metrics? Has McKinsey just solved two problems at once? Maybe they just confused different observations.
Before telling us about their approach, they want us to understand why it’s hard to measure developer productivity in the first place. They casually drop this sentence:
For instance, while deployment frequency is a perfectly good metric to assess systems or teams, it depends on all team members […]
That is an insane sentence to say. How does the number of deployments correlate in any way with a developer’s productivity?
A developer could deploy after a tiny change or after a huge new feature. This has nothing to do with the amount of work that went into it.
Contribution analysis
Read this part of the article:
For example, one company found that its most talented developers were spending excessive time on noncoding activities such as design sessions or managing interdependencies across teams.
and
In response, the company changed its operating model and clarified roles and responsibilities to enable those highest-value developers to do what they do best: code
The most talented developers were spending time on non-coding activities such as design sessions?
Yeah, I hope so!
The hardest part requires the most senior developers. Why wouldn’t an experienced developer design new systems?
You want the novice to do that? It’s one of the most important parts of any system.
Delusion
Not sure whether this article tells us more about the delusion of non-developers or the incompetence of consultant firms.
Probably both.