I recently attended Dan North’s Accelerate Agile course. One of the things he talked about was why measuring productivity is such a terrible idea in software. Although I’ve always known this in my gut, I really enjoyed Dan’s explanation. I think it made the kind of sense that would appeal to people who traditionally think this metric is a good idea. So here’s my recollection of his explanation.
Let’s start by looking at productivity. Wikipedia has the following to say about productivity:
Productivity is the ratio of output to inputs in production; it is an average measure of the efficiency of production. Efficiency of production means production’s capability to create incomes which is measured by the formula real output value minus real input value.
That’s a lot of words I know, but what is important is ‘capability to create incomes’. The word productivity comes from the industrial era of production lines, where more productivity, meant more products, which meant you could sell more, and therefore create more income. So for factories: more productivity usually means more income. Great, why wouldn’t we measure something that is clearly a leading indicator for revenue?
Well, revenue in software is not related to the number of units produced. In fact I can sell the same bit of software several times and make lots of income without producing more software. The digital nature of software means that income is no longer related to productivity.
Okay but wait if we can sell a piece of software 1000 times for each bit of it we produce, then surely we can sell each bit we produce 1000 times, and productivity is still good?
Well lets consider if software is an asset or liability. Consider a problem you have in your business that needs to be solved. Imagine you could solve it with a large enterprise piece of software, lets say SAP. But you could also solve the problem with a small piece of software that does only what you need. Given the options which of these two systems would you rather manage. I imagine most of you would rather manage something small and simple.
Now imagine you could solve the same business problem without software. Would you rather manage the solution with some software or the one with no software? Again I’m gonna imagine that the no software solution looks pretty appealing assuming it solves the problem as well as the software would solve it.
So what does this mean? Well it means that large software systems are harder to manage, take more time and effort to do so, and all things being equally we would all prefer less software to solve our problems. Thinking like this helps you see that software is in fact a liability.
Now let’s go back to that productivity measurement. If productivity measures how much stuff we create, and software is a liability, then measuring productivity in software is essentially the same as measuring the rate at which we are accumulating liabilities. We already know that for software more units do not equal more income.
So if productivity goes up, then liabilities go up and income remains the same….
Does that sound like a good business model to you?
In fact doesn’t it suggest you should send your developers to the beach?
Go on, send them to the beach for today. I guarantee it will not lead to a loss of income. In fact it might just be the start of something interesting 🙂
In a future post I’ll explain what Dan recommends as a better metric for software instead, so stay tuned.