“I can see why measuring productivity is so seductive. If we could do it we could assess software much more easily and objectively than we can now. But false measures only make things worse. This is somewhere I think we have to admit to our ignorance.”
Martin Fowler CannotMeasureProducivity, 2003
According to the developer productivity article from McKinsey, we now live in a world where developer productivity can be measured and controlled. While this article has caused some outrage among the consultant community, it has a certain feeling of inevitability. It’s almost like we set ourselves down this path years ago and this is the expected result.
If you genuinely believe that developer productivity is the goal, and therefore that delivering software is the goal, you’re most likely not thinking closely enough about the products you’re creating. You’re thinking too deeply about the “How” rather than the “Why”.
Because when we build software, we are confronted by the “How” all the time and not many of us get the privilege to spend a lot of time thinking about the “Why”.
What “Accelerate” Told Us
A vital part of the context is what the wider consulting community has been saying for many years. These are the words that the Accelerate reports and the book told us.
Accelerate shows that “higher performing” organisations utilise structured approaches to software delivery. Structure means iterating quickly in small batches utilising the machinery of choice (CI/CD, automated testing and advanced instrumentation). These systems lend themselves to measurement.
From measurement, DORA metrics were born. DORA and, latterly, the SPACE framework ensure we measure the right aspects of software delivery and performance. How is this not Taylorism by the back door? It is a structured approach to people management.
But we, in the community, know that Taylorist approaches only get us so far and in these times they are seen as essentially dehumanising. While we need a scaffold of automation and systems to deliver our software, these should be the liberating constraints which enable us to create and deliver the best software.
Therefore, perhaps perversely, through the well-intentioned creation of the DORA and SPACE metrics, the world of Accelerate has become closer to that of a fully measurable, closed system. The McKinsey article is simply the icing on the cake. Perhaps this is why it is such an uncomfortable truth for many in the community?
So What Should We Call Our Measures?
Ideas come and go in cycles. There is no useful way we can measure developer productivity. Perhaps Henry Ford might have been misattributed as saying: “I know that half of my developer budget is wasted, I just don’t know which half”.
So rather than Developer Productivity, perhaps we can call it something else – Software Pipeline Fitness perhaps? But more than that, it helps us to remember the real reasons we want to measure anything in the first place.
Because:
- Software Delivery isn’t the Goal
- A Happy Customer is the Goal
- How You Make the Customer Happy Is Your Competitive Advantage
Your software delivery is more often than not your entire business strategy.
There is another Martin Fowler quote which is apt here – from What Is Failure:
“Rather than saying that a project is failed because it is late, or has cost overruns – I would argue that it’s the estimate that failed“
Similarly, find the right thing to worry about rather than obsessing about developer productivity. Worry about your customer. And if you don’t know who your customer is then perhaps you can make sure you find out more about them.
Remember that measures will always be misused or misconstrued. Remember Goodhart’s Law or, more correctly, Marilyn Strathern’s interpretation of it:
When a measure becomes a target, it ceases to be a good measure