James King

I was in a meeting where we spoke about estimating technical value.

I said it was a great idea and so we gave it a go. We did a good job of estimating how much effort would go into our new technical piece of work (say, 2 sprints for 2 devs).

We then looked at how much effort we would save the team each sprint (say, every week we get 2 requests to do a data report that is used to clean up our workaround. It takes 1 person 1 hour each time).

We were able to say that we should be able to save some time, if we spend some time cleaning up.

But it go me thinking – In the old manufacturing world, people debated how much money to spending building new things (product or services) and how much money to spend on machinery.

I am sure that they had a lot of robust conversations each time the engineers claimed that the needed a new mechanical horse or something to speed up production.

Then they would buy the new machine, run and maintain it, and eventually have to replace or upgrade it.

Since they know that they will need to replace the old horse in a few years, they estimate how much it depreciates per year and then treat this as an expense. That way they are actually recognising that one day, they will need to re-invest.

This is conceptually the same to me as buying a licence that we will need to upgrade or replace in 5 years time. It is also the same as if we build something in Silverlight or Java version 2 … knowing that support will run out one day and we will need to do an upgrade to stay in business.

Yet when we look at software, we seem to cost it assuming that it will go on forever (like the code in the Voyager spaceships). Then when the technical crew want to do a software upgrade, or retire an old mechanical horse (metaphor), they suddenly have to pitch for the money.

I agree that we should do a business case when we want to replace a mechanical horse or a Lotus Notes database, but I don’t know why the manufacturing people see it as something predictable while the software people seem surprised that their asset depreciated.

I don’t have any answer, but I am wondering – rather than calling old licences and software versions a kind of “technical debt”, isn’t it sometimes a predictable type of “technical depreciation”?

I don’t think we could ever convince a tax office that we should get a discount for depreciating software assets, but maybe we should actually consider them to have a limited lifespan.

Then if we have an asset that reaches end of life, we write it off and either do without or upgrade/replace it, recognising this looming decision by looking at how much value (scrap value?) an asset is worth.

Does anyone predict the demise of their shiny new (software) mechanical horses and build some concept of depreciation into their planning?