Why don't we assign a shelf-life when building software?
Software should also have a shelf-life

Why don't we assign a shelf-life when building software?

(This article is written and published in conjunction with Faptic Technology)

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)

Simon Roberts

Lead Cloud Pre-Sales Manager

1 å¹´

Sage advice from those who have faced this dilemma many times.

Steve Whistlecroft

Technology & outsourcing consultant, helping companies optimise their investments by accessing the right technlogy skills for their situation.

1 å¹´

We don't because half the world at least would be running on software that should have been retired years ago - indeed whole industries are sometimes running on software that is long past its sell by date and no longer fit for purpose but nobody will make the often major investment to change.

Joseph Emison

Cofounder and CTO at Branch Insurance

1 å¹´

What shelf life would you assign to grep?

要查看或添加评论,请登录

Nigel Beighton的更多文章

  • Why Do Tech Organizations Still Fail, Despite the Ease of Modern Technology

    Why Do Tech Organizations Still Fail, Despite the Ease of Modern Technology

    I may upset a few battered CTOs here, but believe it or not, rolling out technology has never been easier. With mature…

    3 条评论
  • Three Essential Questions To Ask Before Launching Your AI Project

    Three Essential Questions To Ask Before Launching Your AI Project

    Full open disclosure - I am starting to dislike the term "Artificial Intelligence". I am irritated and frustrated with…

    1 条评论
  • AI's New Kings: The Ascendancy of Math Geeks

    AI's New Kings: The Ascendancy of Math Geeks

    This article stems from an unusually fruitful academic chat I had with my teenage son this morning - for many parents…

    3 条评论
  • Engineering a Successful SaaS Product: Three Tips for Engineers and CEOs

    Engineering a Successful SaaS Product: Three Tips for Engineers and CEOs

    I recently read The SaaS Playbook by RobWalling (published by Amazon, https://saasplaybook.com/), an excellent and…

    3 条评论
  • In the CTO World, Reputation is Everything

    In the CTO World, Reputation is Everything

    In the fast-paced, interconnected realm of technology, the role of a Chief Technology Officer (CTO) stands out as a…

    2 条评论
  • Tech Due Diligence - What Gets Frequently Overlooked

    Tech Due Diligence - What Gets Frequently Overlooked

    { Following on from my article The 5 Quick Indicators of a Good Tech Org, I wanted to cover what is frequently missed…

    1 条评论
  • The Common Vacuum Between CEOs and CTOs.

    The Common Vacuum Between CEOs and CTOs.

    I have wanted and needed to write this for many years, primarily for my own cathartic reasons. For a long time, I've…

    2 条评论
  • The Five Quick Indicators of a Good Tech Organisation

    The Five Quick Indicators of a Good Tech Organisation

    In the dynamic and ever-evolving realm of technology, assessing the health of an organisation quickly is often a…

    2 条评论
  • The Three Best Qualities I Want in a Tech Leader

    The Three Best Qualities I Want in a Tech Leader

    In the realm of leadership, Napoleon Bonaparte once faced criticism for winning battles seemingly due to luck. Unfazed,…

    1 条评论

社区洞察

其他会员也浏览了