Avoiding the Developer Productivity Paradox

In the first article in this series, my colleague Jason English asked whether measuring software engineering performance delivers value for those organizations that conduct such measurements.

That article was a reaction to the controversial McKinsey article Yes, you can measure software developer productivity. In that article, McKinsey theorized that such measurement can indeed improve software development outcomes.

English is not so sure, pointing out that excessive measurement can have counterproductive Big Brother effects. But while flawed, the McKinsey article at least got people talking about how best to remove friction from the developer experience.

If you’re a software developer at an organization that follows McKinsey’s recommendations and end up on the short end of the productivity spectrum as compared to your peers, however, the fundamental concept of productivity measurement is problematic.

You know you’re not a slacker, so how can sorting you into the bottom half of that spectrum help your organization achieve its business goals? Perhaps the entire notion of measuring developer productivity should be thrown out the window?

Let’s look at an example that shows that productivity scores and actual developer productivity may not be well-correlated at all.

When Less is More

Let’s say an organization has two developers on its team. Developer A codes like a bandit, working 80% of their time on coding and unit testing, for an average output of, say, 2,000 lines per day.

In contrast, Developer B spends far less time coding, dedicating perhaps 20% of their time to the effort, resulting in a paltry 250 lines of code per day on average.

Which developer is more productive?

At first glance, it looks like Developer B is slacking off. Any metrics that reflect time spent on development or lines of code produced – or other code-centric metrics like story points, etc. – would clearly rank Developer B lower than Developer A.

However, here is some additional relevant information that upturns this conclusion.

• Developer B is far more senior than Developer A. Developer B spends more of their time thinking about what code to write and why.
• Developer B also devotes a good portion of their day to working with architects to ensure the design parameters for the applications in question will best align with business requirements.
• Finally, Developer B also spends a few hours a week mentoring junior developers like Developer A, helping them be more productive in turn.

Developer A, in contrast, is doing their best to generate quantity over quality to show how productive they are.

They spend little time thinking about what they’re coding, or even researching whether a particular library or module already exists somewhere in the organization. As a result, they generate a lot of redundant or otherwise useless code.

Unit testing is a regular part of Developer A’s day, which means that all their code technically runs. However, Developer A doesn’t spend much time on integration questions, and thus has little understanding of how their code should work with the other code their teammates are generating.

McKinsey Misses the Big Picture

McKinsey’s analysis of developer productivity breaks down software development into two sets of tasks, as the diagram below from the article in question illustrates.

According to McKinsey, the inner loop above – build, code, test – should be how developers ideally spend their time. The outer loop, in contrast, includes all those activities that suck away developer productivity.

Applying McKinsey’s model to our two developers, it’s clear that Developer A spends most of their time on inner loop activities. Good for them!

Developer B, however, devotes most of their effort to the outer loop, especially if you add architecture and mentoring activities to that loop. (McKinsey’s footnote points out that tasks are missing from the diagram. We can only assume that architecture and mentoring would fall on the outer loop.)

Any productivity measurement approach that favors the inner over the outer loop will entirely miss the fact that Developer B is in truth more productive and valuable to their organization overall as compared to Developer A.

Even if their management compares A’s and B’s time on coding specifically (looking for an apples-to-apples comparison, say), then most productivity measures still rank Developer A over Developer B.

Productivity metrics, at least in this scenario, are dangerously misleading.

The Big Picture of Developer Productivity

The key takeaway here is that blindly focusing on individual productivity metrics without considering the roles and responsibilities of developers with different levels of seniority doesn’t accurately reflect the productivity of the team – or the development organization at large.

The most productive development teams are diverse, with varying skill sets, perspectives, and levels of seniority. Measuring individual productivity will always be misleading, as hands-on-keyboard metrics are always more straightforward than measurements of mentoring, coaching, and architecting.

Software engineering intelligence platforms like Faros.ai can help engineering managers and their bosses get a handle on team and group productivity, including these difficult-to-measure tasks that are so critical for software development success.

The Intellyx Take

This article has only scratched the surface of the issues inherent in measuring developer productivity.

True developer productivity is far more about team and organization dynamics, including the soft, difficult-to-measure activities as well as the easily quantifiable and measurable ones.

I’m not saying that measuring developer productivity is pointless. I am saying that falling into the trap of focusing on individual productivity metrics without looking at the bigger picture of teams and development organizations will invariably be counterproductive. Don’t make that mistake.

Copyright © Intellyx LLC. Faros.ai is an Intellyx customer. Intellyx retains final editorial control of this article. No AI was used to write this article.