It’s time to have an Expiry Date for the Software(s) & Source Code(s)
Everything in this universe comes with an expiry date, including the universe itself (as per the Physicists)
Whenever we talk about any object which we intend to use, the age factor comes into play.
As much as we want everything to last longer, we know that sooner or later, things will be expired.
Software and the source code are an exception to this. No Software is sold with an expiry date and no one is even thinking or talking about it.
It’s also true that given the competition, it’s highly likely that a software will get killed by other software before it can have a chance to expire, but still we need to talk about it as who knows, the reason for being killed might be the legacy code itself.
What’s a Legacy Code?
In simple language, a Legacy code is one which was written long back, but still occupies a prominent place in a production system.
As a software developer, we all have seen or worked on the codes written 10+ or even 20+ years back and still in use.
So, what’s wrong?
Nothing, Let me be clear that it’s not wrong to use the old legacy code, as long as the product works and there is a limited need to expand the offering.
As an example, have a look at the iconic NOKIA 3310 phone
It’s the classic case of legacy product which works well and there is no problem with it. However, we can’t expect it to work like an iPhone, and frankly no one will even try that.
However software is not something where we can perceive the characteristics physically, and that's why we keep on using it, expanding it, and maintaining it without realising it’s limitations due to age.
Over a period of time, when newer requirements, newer frameworks and newer systems comes into picture, then sooner of later we face the issue of “Legacy Compatibility” and believe me it’s big.
领英推荐
The issue of Legacy Compatibility
It’s a prevalent opinion in the software development industry that changing legacy code is problematic to the core, and it’s better to live with it to the extent possible.
This assumption requires compatibility layers to be built (Directly or Indirectly) by the new functionality.
Unfortunately, these compatibility layers exert a significant cost (directly or indirectly) to the software. Whether it’s a prudent choice or not, depends upon multiple factors, however, with the passage of time, it becomes obvious.
How to Decide the Expiry Date of the Software / Source Code
Software and source code are a unique beast, unlike most of the thing where you can calculate or at lease sense the possible expiry date, it’s not possible to do the same with software or the source codes.
Because source code doesn’t age by itself, it’s age is purely determined by the external environmental circumstance, be it be hardware(s), other software(s), or the IT infrastructure.
There is an old saying that, don’t belittle the line by erasing it, draw a bigger line.
This is what precisely happens most of the time in the software industry.
Please note, I’m not saying that the code will expire as soon as a new bigger line has come into the market, no organisation can sustain this kind of approach.
To properly gauge the expiry date of any software, you need to look into multiple factors. Here are a few signs which may help you to identify when you should worry about your code being aged.
The list below is not exhaustive, but indicative
Hope these points will help you in evaluating the age of your code and thereby take a better decision
Thanks for Reading…!!!
Daksh