(This article is written and published in conjunction with Nigel Beighton)

By far, the number one reason I see companies start to fail, when heavily dependent on technology, is the burden of technical debt. Technical debt is already well written and talked about, although not as well researched as I would like, and generally accepted as a significant issue. Sadly, organisations only acknowledge it as an essential issue when technical debt has stalled the company's progress and savaged the balance sheet when it is too late.

In simple terms, technical debt diverts critical resources, eats up tech budgets, restricts innovation, slows down projects and demotivates employees. If it were a car, we would scrap it; if it were a generator, we would replace it. Although the analogy does open up the question of vintage game software, I will leave this out as the one case that breaks the rule.

Applications live for how long?

This is not an article about why excessive technical debt is damaging; it is more about what you can do to avoid it, but if you want to read more about it, there are many good articles and books, including 'Managing Technical Debt' by Philippe Kruchten, Robert Nord, and Ipek Ozkaya (published in the Communications of the ACM) and, although older, still relevant is 'The Financial Aspect of Managing Technical Debt' by Tom Mens (published with 'IEEE Software').

The average lifespan of commonly used software is a topic that is not straightforward to quantify due to the massively varying nature of software types and their respective industries. However, a few years back, the average lifespan of business software was generally quoted at something around 5 to 10 years. To quote Managing Partner Andrew Jardine at Faptic, “Typically, we’ve seen the faster application life cycles being across North America, with an average life span of 2 years, increasing on that is the United Kingdom at 5 years, on average, and further again, West Europe with Germany ranging from 5-7 years”

In most businesses, other than those heavily regulated and restricted, I strongly suspect this timescale has shortened significantly and will continue to shorten. Not because of new development languages, in fact, we are in a rare extended period of development language maturity and stability. There are a few new entrants, such as Kotlin and Rust, but generally, the likes of Java, Python, SQL, Typescript, C#, etc., are all well-established and supported, and here to stay. Even the old enfant-terrible, the React framework, has now grown up and acts with a high degree of maturity.

Note: if you want to see how development languages and frameworks are maturing (and some heading to obscurity), I highly recommend a quick review of the always-interesting Stack Overflow annual surveys, 2023 and earlier (https://survey.stackoverflow.co/2023/). Not only does it help with planning your future, but it also gives a good insight into the availability of skills in the market and, consequently, future costs.

I suspect the shortening lifespan of applications is now less down to changes in technology and more due to just the speed of change organisations and society have to deal with.  The inability to accommodate critical changes in underlying functionality, coupled with the loss of detailed knowledge of how it was initially structured (who documents anything any more!), is why I suspect applications become technical debt more quickly.

Back to planning for no technical debt

There are various formal and subjective approaches to identifying, quantifying, and classifying technical debt; however, I almost never see anyone at the start of their inception and roadmap assign a shelf-life to the software solution. Virtually all the roadmaps I see show only delivery blocks and optimistic implementation dates, with the assumption that once something is live, it will just work forever, will need no attention and will have no impact on any part of the future part of the roadmap. There is no end point for what will be implemented, no end of life, and no consequence or dependency. There may be a v2 on the roadmap to cover what realistically will be descoped from v1, but there will be no end of life. In simple terms, we don't assign a shelf-life.

For those unfamiliar with the term, Wikipedia lists a shelf-life as: "the length of time that a commodity may be stored without becoming unfit for use, consumption, or sale. In other words, it might refer to whether a commodity should no longer be on a pantry shelf (unfit for use), or no longer on a supermarket shelf (unfit for sale, but not yet unfit for use). It applies to cosmetics, foods and beverages, medical devices, medicines, explosives, pharmaceutical drugs, chemicals, tyres, batteries, and many other perishable items". Interestingly, Wikipedia does not include software in that definition, and it should.

Assigning shelf lives would enable proper forward planning and budgeting, reducing the risk of substantial unplanned investment requests - the most awkward situation for any CEO, CFO and CTO (excluding company Christmas parties where someone left the bar tab open all night).  Equally as important, assigning a shelf-life helps an engineering team work out the optimum technology and approach to use, reducing cost and saving time. Knowing the required lifespan of a software project is often the key to deciding if the software should be outsourced, built in-house or not built at all (bought in), in addition to what technology should be used and how it should be operationally supported. In hindsight, we all know too many software projects have been excessively formal when they needed to be a hack, and others were hacked when they needed to be more structured and formal. Assigning an upfront shelf-life would go a long way to reduce these hugly impactful and costly situations.

Final comment

So, besides getting Wikipedia approval to edit the definition of shelf-life and adding "software", my recommendation is simply to all Product and Tech Leaders assembling roadmaps: assign and show shelf-lives - to save yourself so much frustration, embarrassment and pain in the future! It may even keep your company from stalling - stalls always come quicker than you think.

The iconic and insightful Marilyn Monroe famously said, "Nothing lasts forever, so live it up, drink it down, laugh it off, avoid the drama, take chances, and never have regrets because at one point everything you did was exactly what you wanted". Although I am not sure that "drink it down" and "laugh it off" appropriately apply to software, "because at one point everything you did was exactly what you wanted" seems highly appropriate; it is just that "what you wanted" now changes so much quicker.

(Thank you Andrew Jardine, and www.faptic.com, for the input and sanity check)