Taking the long view: Or, Don’t Float Your Bloat

Bob Frankston pointed me at this Dan Bricklin piece a few days ago, suggesting it was good background for a discussion that a number of us were having about infrastructure. [Thanks, Bob. And thanks to Dan as well, great piece. Something to discuss over dinner next time we meet.]

Dan draws out a number of themes in the essay, each worth analysis in its own right. And that is not what I intend to do in this post. Another time, maybe even another place. Instead, what I want to concentrate on is the implications of one particular aspect of Dan’s essay, depreciation:

Today, hardware is capable enough that software can be written that will continue to run unmodified as hardware is changed. Computers are no longer new alternatives to other applications — they are the only alternative. Despite this, old thinking and methodologies have remained.
Computers and computer software have been viewed as being valuable for no longer than common short-term durable goods like an automobile or sometimes even tires. In accounting, common depreciation terms for software are 3 to 5 years; 10 at most. Contrast this to residential rental property which is depreciated over 27.5 years and water mains and brick walls which are depreciated over 60 years or more.

I’ve known about this for many years, yet somehow I haven’t appreciated something about depreciation. This may be because I’ve tended to work in environments where the preference is to treat software investment as cash rather than as something to be capitalised.

There were many reasons for this: the avoidance of burdening future generations, a sins-of-the-father variant; the frustrations of reviewing software asset portfolios at year-end, and having to cope with material swings in annual outturns driven by write-offs; the apparent illogic of bothering to capitalise software that was not going to be fit for purpose in less than two years.

I’ll say it again. The apparent illogic of bothering to capitalise software that was not going to be fit for purpose in less than two years.

Probably influenced by Nicholas Carr’s seminal article and book, many people have already classified IT as a utility: standardised, commoditised, scalable, infrastructural, available on tap. I only wish it were true. It will be one day. But we’re not there yet. [Incidentally, he’s written a very interesting mini-piece on Amazon and AWS here, a segue on this Wired article, something I will comment on in a few days.]

Reading Dan’s essay, I realise there is a simple way of my finding out when “IT won’t matter”. A leading indicator, as it were.

IT “won’t matter” when software depreciation periods start pushing out to reflect the periods prevalent in construction industries and utilities.

This has already begun to happen, particularly in infrastructural IT, an area where opensource software is dominant. [And no surprise!]

And it’s going to accelerate with the arrival of software as a service. When you’re providing a quality service at a competitive price, you’re not going to be fiddling around with the gubbins of the service every time it rains. Nobody can afford to.

Sure, we have forces operating in the other direction. People still get paid to design and deliver “planned obsolescence”. Even worse, bloatware is common, even endemic.

This will change. It has to. More and more of what we call software today will become infrastructure, reliable, consistent, with a long shelf-life. Carr will be proved right, as far as this is concerned.

But it doesn’t stop there. Because infrastructural software is necessary but not sufficient for a sustainable business, particularly one which relies on knowledge workers.

Innovation will continue, even thrive, “at the edge”. And at this edge, we will still build software. Mayfly applications that last for a day, a trade, a project. Disposable software. Radioactive software with a short half-life. And these applications will be built on a “cash” basis. Markets will move faster, not slow down. Exciting times, where software is both a utility as well as the engine of creativity.

For all this to happen, we need to see changes. Particularly an end to Bloatware.

Don’t Float Your Bloat. Because that don’t float my boat.

Let me know what you think

This site uses Akismet to reduce spam. Learn how your comment data is processed.