Achieving Longevity of Software

Achieving Longevity of Software

“Programs, like people, get old. We can’t prevent ageing, but we can understand its causes, take steps to limit its effects, temporarily reverse some of the damage it has caused, and prepare for the day when the software is no longer viable. ... (We must) lose our preoccupation with the first release and focus on the long term health of our products.”, D.L. Parnas

Software ages. Unlike physical and biological entities, this ageing is not time-based but depends on the relevance and usefulness of software to the business or domain it was written for. It is not uncommon to find freshly released software that ages much faster than the hardware it ran on.

For example, Windows Vista was eligible for retirement at its release because its bloat mandated expensive hardware upgrades for it to be useful. Conversely, Windows XP released much earlier still remains useful albeit with paid support from Microsoft now. Many businesses still operate applications written decades ago using technologies that are no longer mainstream. Such applications don't age as long as hardware and operating systems they depend on exist and are affordable to operate and maintain.

So, software ages because of the following reasons,
a) shifting business focus making software less relevant or useful,
b) inability to execute on or interoperate with its environment,
c) modifications without understanding the system (ignorant surgery),
d) reaching to a stage where further modifications are not possible or feasible.

Software ageing should be of considerable concern to most businesses as software development is expensive and laborious. Faster ageing of software systems results in much more frequent renovations leading to much sooner application rewrites. This translates to lost opportunities because of delays in delivering the required capability to the business.  Higher costs for products and services delivered result in narrower margins. In many cases, ageing leads to the host hardware becoming less useful or relevant requiring infrastructure upgrades which are expensive and can also be disruptive.

Much focus in software research and practice is on rejuvenating geriatric software. While several techniques and methodologies have been prescribed, post implementation anti-ageing measures can be costly, disruptive and risky if eventual longevity has not been a focus during initial design and implementation.

Listed below are some design and implementation principles that can bring longevity into perspective during system development phases. I refer to them collectively as DIPSy for convenient recollection

Domain Focus

Design and implementation of systems should target the domain they intend to support. A domain driven design and implementation focuses on using business abstractions at least at higher level layers. This generally allows a more convenient adaptation to evolving business requirements.

In-dependence

Reusing pre-developed components and libraries is an established and preferred practice in the technology industry. However, substantial care is needed to ensure only relevant dependencies are included in the resulting systems. Furthermore, cascading dependencies (dependencies of dependencies) must also be scrutinised to assess any impact on system's eventual longevity. Finally, dependencies should be isolated as much as possible from the domain as their permeation into domain level abstractions can make eventual modifications and migrations arduous.

Patternise Pragmatically

Design and architectural patterns when applied in their relevant contexts can significantly simplify design and implementation of software systems. However, overusing patterns, applying patterns outside their context or using them when their advantages cannot be realised can introduce unnecessary complexity in the code. This can make code difficult to modify or extend to accommodate evolving business requirements or to perform maintenance.

Simplify Aggressively

Sophisticated software that is rich in features and functionality need not have a complicated implementation. The 3 principles mentioned above go a long way in avoiding complexity within code and installation. Additionally,

  • simplifying and consolidating data and control flow,
  • avoiding unnecessary optimisations and
  • avoiding or removing unused or deprecated functionality

can help develop sophisticated yet simple applications. Simplicity, however, is a continuous pursuit and not just during development but also in maintenance.

Omar Bashir is a software professional who pursues simplicity and longevity of technology he delivers. 

The key to software longevity would lie in Strategic Agility, to be able to cope with the changing business strategy. Since technology is supposed to be business driven the key is to be able to add value while being financially viable at the same time.

In theory this works well Omar, I have worked on systems made in the 80's and believe it or not they are still working today ( i am sure you have to). Not because they were brilliantly designed, but because the cost and potential disaster of replacing them is just too much uncertainty. So wrapping functionality of these old system is the adopted way of rejuvenation.

Omar, good insights. Software aging can include memory leaks, unreleased file locks, accumulation of unterminated threads, data corruption/round-off accrual, filespace fragmentation, shared memory pool latching. Software aging in mission-critical systems, such as Patriot Missile software caused collateral damage and loss of lives. The solution was to reboot and re-start the Patriot systems software every 8 hours.

Simpicity is done by hiding complex data within it.

To view or add a comment, sign in

More articles by Omar Bashir

Others also viewed

Explore content categories