This is the start of a new mini-series looking at Legacy software. The term "legacy" is often seen as positive - yet within computing it is a negative term generally uses to indicate the need to replace hardware or software. In this episode, I'll give you an introduction to Legacy software.
Or listen at:
Published: Wed, 13 Jul 2022 15:58:38 GMT
Links
- The FBI removed hacker backdoors from vulnerable Microsoft Exchange servers
- Episode 129 - Handling Failure
Transcript
Hello and welcome back to the Better ROI from Software Development Podcast.
This is the first in a new series looking at legacy software - what it is, how it occurs, and various strategies to deal with it.
In this episode, I'll give you an introduction as to what legacy means within software.
Generally a Legacy has positive connotations. One dictionary definition has it defined as.
"an amount of money or property left to somebody in a will"
For example,
"My grandmother died and unexpectedly left me a small legacy"
When we talk of a person's legacy, it is often seen as a lasting statement of somebody's work. As you rise up the organisational ladder, it's not uncommon to be asked to consider what legacy you will leave behind.
And I'd like to believe that my podcasts will be a lasting legacy that I provide it to the wider community.
However, within computing it is often seen in very negative terms. The same dictionary definition defines legacy as:
"Related to computing, as denoting or relating to a software or hardware that has been superseded but is difficult to replace because of its wide use."
In these cases, any legacy can be seen as a problem for the owning team department or organisation.
However, it can often be difficult to really determine what is legacy and what isn't. There is no specific test - and indeed, it could be very easy for one software developer to describe a system as legacy, yet another to say it isn't. It can be hugely subjective based on the individual's familiarity and experience.
And in truth, I'd be inclined to say that being legacy or not is not a binary proposition. Rather, any system could be considered to be somewhere on a sliding scale of legacy. And indeed, different parts of a system could be at different places on that scale.
So that begs the question, how do we know if our system is legacy?
Maybe it's easier to describe a system which wouldn't be considered legacy. For such a non-legacy system, I would suggest that the system should be able to:
Implement any critical security patch for your operating system or dependent libraries within 12 hours.
Regularly implement any latest versions of any dependent software or library within. With your software always being close to the latest version, and definitely using versions that are supported and actively maintained.
You are rarely seeing production errors - and when you do, you're able to identify them quickly with minimal impact, and if needed, resolve within 2 hours.
You have no problems recruiting staff knowledgeable in the technologies and use.
While this list is hardly exhaustive and is largely subjective, I personally think this gives us a clear idea that the software is active and healthy.
Let me go through my thinking.
- Implementing any critical security patch for your operating system or dependent library within 12 hours.
Security is critical in our software systems. It always has been, but there is much greater emphasis on it in recent years. Daily, new security vulnerabilities are identified in the operating systems and libraries that our software relies on. Microsoft, Apple, Google, etc, all the technologies that we rely on, are constantly releasing security patches. Why? Because vulnerabilities are constantly being found - sometimes in new software, sometimes in software that has been in use for 5 to 10 years.
Finding vulnerabilities is big business - be it the black market for selling it to the unscrupulous or the security researchers trying to get ahead of them - it's an active arms race.
Thus, when a new vulnerability is found, it's an arms race between the good guys to patch it and the bad guys to exploit it. For one Microsoft vulnerability, the FBI considered it so important they actually used that vulnerability to access privately held servers and patch them on behalf of the owners - all in an attempt to avoid the vulnerability being used by cybercriminals - I'll include a link in the show notes.
Thus is your software process and teams in a position to:
- Be aware of a critical security patch in a timely manner
- Test the patch with your software
And release to production in a controlled and confident manner.
- Regularly implement any latest versions of any dependent software or library within, with your software always being close to the latest version and definitely using versions that are supported and actively maintained.
It is critical that any software or library you depend on is actively being maintained and supported - otherwise, the dependency itself is legacy - and by extension, if you are relying on legacy, then your system will at least be somewhere along that legacy scale.
But even falling behind too many versions can leave you open to problems. It can often be difficult to fix or support older versions. You may find that you identify a problem or even a security vulnerability in an older version, and the first option you're provided with is to upgrade to the latest version. In some cases, you realistically get no assistance until you've done so.
And it can be very easy to fall behind with the fast pace of software development. It can seem a difficult business case to invest time just to achieve the same thing - leading to such activities often being deprioritized over adding new features.
Thus keeping us up-to-date has to be considered good hygiene.
How up-to-date will likely depend on how much of a dependency you have on that software or library, and how critical is to your organisation. If it's at the heart of how your organisation collects cash into the business, then it is likely to have a much higher criticality than something used to produce quarterly reports.
- You are rarely seeing production errors and when you do, you're able to identify them quickly with minimal impact, and if needed, resolve within 2 hours.
Production errors are expensive, both in cost and in reputation. Thus, you want a robust and reliable method of minimising them.
But when, not if, they do occur, how quickly are you aware of them? And then how quickly can you resolve?
At minimum, you should know as soon as your customer, ideally before them. And for the most critical problems, you should be able to do something about it within 2 hours, even if it degrades the customer experience.
While that 2 hours may seem extreme, and it could be argued would differ between organisations, I personally want my most valued customers to be dealing with the errors for a shorter time as possible. I'd rather give them a degraded service - maybe a notice telling them that they will not be able to view their previous orders - than the website visibly erroring or showing incorrect data. I'd rather use something like graceful degradation that I talked about in episode 129.
- You have no problems recruiting staff knowledgeable in the technologies in use.
Any software product will only be as good as the team developing and supporting it. And if you cannot recruit or retain staff because of the technology, then you have a problem.
For quite some time now, software development is a candidate driven market, and good developers will vote with their feet if they feel the technologies, practices or even the tasks they're being asked to do do not meet their expectations.
This can often become reinforced by the recruitment market, with software developers choosing roles based on how it will look on their CV. And while previously this may have been the organisations, now it is much more about the technology and the practices in use.
Thus, as a technology or practice gains popularity, you see a shift in the recruitment market, in the developers chasing them, and the employers trying to recruit them. It can often feel like a popularity contest, almost a beauty pageant for technologies and practices.
But regardless of the correctness, the market will follow its trends, leaving a dangerously low quality or quantity of those technologies and practices that have fallen out of vogue.
In this episode, I've started to introduce legacy software.
I've started this mini-series talking about how it isn't a binary proposition - your system being legacy or not legacy. Rather, it's likely to be on a sliding scale, possibly with different parts being at different places.
And I've talked about four key indicators that your software isn't legacy, based on:
- Speed to implement critical security patches
- Keeping up to date with dependent software and libraries
- Minimising production errors and being able to rapidly handle those critical errors when they occur
- And being able to recruit and retain the software developers in the technologies in use
In next week's episode, I'll take more of a look into the impacts of running legacy software.
Thank you for taking your time to listen to this podcast. I look forward to speaking to you again next week.