Service Life Expectancy
It's increasingly rare to see services or apps designed with a defined lifespan. Traditionally, significant effort goes into building a product, and businesses often try to extract every last bit of value from it, even when newer, more secure technologies are available. This tendency is often reinforced in large organisations, such as banks, where financial considerations and short‑term measures of value can overshadow investment in the long‑term health of software systems.
However, large software manufacturers rarely start from scratch or completely abandon popular software when upgrades are due. Instead, they typically follow an evolutionary model, gradually rewriting or re-architecting portions of their systems with each major version release. While still fitting within a 'service life expectancy' model, their lifespans are generally tied to the period during which a major version receives security updates and bug fixes.
The biggest need for this approach, I believe, lies with smaller to medium-sized apps and services – a mobile app, a web service – particularly those heavily reliant on third-party software, especially in volatile areas like front-end web development. These factors can quickly make an app or service built just three years ago feel outdated, using older architectural patterns and frameworks. Even large software systems can face similar issues over longer periods if they lack ongoing innovation and simply remain "kept running."
It's important to clarify: the service life expectancy model isn't about constant, knee-jerk refactoring or rewrites simply because something new and trendy becomes available. That’s not a sustainable approach. Instead, it's about proactively planning your software's life cycle – estimating its potential decommissioning date and planning a safe transition. This planning should consider factors like personnel availability, budget constraints, and the overall risk appetite. These factors can change over time; for example, the sudden loss of specialized skills (like COBOL developers) can significantly impact a system's longevity.
Defining a service life expectancy during development offers several advantages. It allows engineers to make informed technology choices. If the anticipated lifespan is ten years, they might be more cautious about relying on third-party code that might become unsupported. Conversely, a two-year life expectancy for a small mobile app justifies the use of more readily available, fast-track technologies, speeding up initial development.
Without a defined service life expectancy, even well-planned, large, and mission-critical software can lead to future problems. Engineers and owners are often left scrambling to decide whether to rewrite or heavily refactor aging systems – conversations that typically arise when maintenance becomes difficult, new features take too long to develop, or the system struggles to integrate with newer systems. Fixing these problems can be incredibly challenging, especially when the original developers are long gone and the technology is obsolete.
Hopefully, I’ve inspired you to consider your software's life expectancy the next time you build something new. It’s a benefit to you, the business, and the developers who follow.
As always, maintainability remains key to good engineering.