Decoding Developer Productivity
From Lines of Code to Lines of Thought: Evolving the Measurement of Developer Work
The topic of measuring productivity & developer experience has become a hot discussion ever since McKinsey published their report on developer productivity.
Without diving into details about the quality of the report, let’s focus on the two essential questions related to developer productivity & estimates:
1. Why is it so tricky to estimate software development work & productivity?
2. Why does everyone want to measure it?
Why is it so tricky to estimate software development work & productivity?
The Unknowns
If you are old enough, you may remember the pre-smartphone era when navigating unfamiliar roads was a challenge. The travel plans got more unpredictable and complicated the more distance one had to travel.
The shorter the run, the more predictable the drive. But if you were going cross country, you'd get lost, take detours, ask for directions, and your journey would be filled with unforeseen twists and turns.
Do you think a driver’s productivity is best measured solely by miles traveled?
What about their mastery of roads, navigation ability, or car troubleshooting knowledge?
No points awarded for that?
Change is the only Constant!
The ability to change is what constitutes “soft” in software.
It changes while you are developing it and after you are done developing it.
Being adaptable is crucial in software, but it makes measuring productivity a real puzzle. Keeping your arena wide open to change makes it hard for someone to estimate & measure productivity!
Why does everyone want to measure it?
Money makes all abstract concepts concrete!
When it comes to buying and selling stuff, we like things to be clear. Whether it's setting a price for goods you're selling or figuring out the value of your old car, clarity is key.
Before the money exchanges hands, you know what you are getting. $4 for a gallon of milk or $5000 for your old car!
But with software, there are so many unknowns and changing requirements. We want to know what we're getting for our money, so we keep trying to measure productivity, even if it's tricky.
It is the human need to know the exact value of something before bartering it with something of value(money in this case), and this need is unmet. As long as this need remains unmet, the urge to try and estimate & measure continues.
Changing Perceptions
So, is this how the world works?
Not necessarily!
You don't measure a doctor's productivity by the time they spend in surgery. You don’t measure a lawyer’s productivity by how many words they write (or character count).
Why?
Is it because you trust them more?
Is it because they are always learning?
Why do we insist on measuring developer productivity with lines of code?
I don’t know, but it seems that software developers are often equated to assembly line workers rather than professionals.
But it's time to rethink that idea. Developers are creative problem-solvers, not code-generation machines.
In the end, we need to ask ourselves: How can we look at developer productivity differently? How can we move away from old-fashioned ways of measuring and appreciating the actual value of what developers do? It's time to recognize the artistry and skill behind software development.
I'll leave you with this question: What should we do differently to change this perception?
Subscribe to the newsletter to read the follow up articles on different levels of productivity and what measures you can take to increase your organization’s software delivery productivity.
Managers only worry about measuring programmer productivity because programmers are often the bottleneck on what the organization can achieve. If programmers were no longer the bottleneck, the focus on measuring productivity would shift elsewhere.
In _Extreme Programming Explained_, Kent Beck related the story of an XP team that was extremely productive, hit all their targets... and was then disbanded by management. The team had been so productive that the bottleneck shifted to other departments in the organization, and those departments didn't like being in the spotlight. Maybe they had gotten used to the idea that *their* productivity couldn't be measured... and now someone was trying to measure it.
Until we realize that we are all in the same boat, and will go fastest if we all row at the same speed, distrust and the "measure or be measured" attitude that comes with it will prevail. When we all work together, there's no need to measure productivity, because the whole organization is by definition working on its highest priorities as quickly as it can.