BrainBlog for Faros AI by Jason Bloomberg, Managing Partner, Intellyx
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?
On 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.
Click here to read the entire article.
