Software Adaptability as medicine for Software Ageing

Software life cycle is similar to people, start babe with limited capabilities and limited skills and with time become older with more capabilities and more functionalities but after more time, it is capabilities start to decrease until it become useless and die.

Researches identify two main reasons for software aging, the first one is the failure to adapt to the new business requirements in other word the software cannot satisfy the business need any more by consequence the software users will try to find a younger alternative that can satisfy their need.

The second reason, is the increased complicity in software source code due to the continues changes and updates. With every update or change a new bugs are introduced to the system, in a lot of cases the software architecture itself become vague, the documentation become outdated and no one can understand the code any more.

With a deeper look in the 2 reasons of aging mentioned we will find that it is a closed loop, we update software to prevent aging, while updates itself are the reason of aging. The bad conclusion of this is that we cannot prevent software aging, we cannot prevent software death.

Only 2 ways are available to deal with aging, the first one is building software to live longer like human the practices used in building the software have direct impact on the aging. Someone who play sport, eat healthy food and not smoke will not get affected by aging as some who has an unhealthy life style.

Software must be built for adaptability, example when building a mobile app using the native user interface controls provided by the native sdk, it should get updated by itself for the newer version of OS by contrast when building the app using custom controls that will add for the team the responsibility of updating the user interface controls to match the new OS look and feel.

Another example of adaptability, when building a business Application, moving the business rules outside the application will guarantee that administrator of the application will be able to update the rules himself with no need to modify the source code.

The problem with adaptability is the limited imagination of the software developer, in a lot of cases there is no way to identify what can be changed in the future and what cannot be, but in a lot of cases we just need to handle the common scenarios (User interface controls, Business rules…)

DevOps provide a new framework to fight aging as now we can see how the users are interacting with the software, what they suggest to have and what features are not used anymore. With some analysis and predictions we can expect the user needs in the future, by contrast to the traditional software thinking about how to do the software update to satisfy the user future needs, we should think on how to update the software to allow it to adapt to the new user needs.

ERPs are the best example to describe the adaptability but in the majority of cases it require more resources than the needed functionality, that show the difficult tradeoff “adaptability vs resources management” may be the target customers segment will help achieving an accurate answer to this trade off.

When the adaptability cost is not affordable we can think of portability as alternative, portability guarantee that we can run our software in multiple environments with less modification in source code witch will delay the software aging.