This is the third article in a series about the challenges legacy bespoke software presents for businesses which depend on it to manage their processes.
The first article, Bridging the Past and Future: AI-Driven Strategies for Legacy Software Overhaul, highlights how AI is starting to provide tools we can use when modernising legacy codebases, e.g., explaining what a piece of code in an unfamiliar technology does.
The second article, From Old to Bold: Managing Change and Skills in Legacy System Overhauls, touches on some of the human issues, like upskilling teams, while also reminding us of the knowledge that existing teams have even if some of their technical skills aren’t quite up-to-date.
A simple definition of legacy software is that it refers to any software or application that continues to be used past its prime. But what does that mean, and how does it happen?
Note that while this definition does not explicitly refer to the age of the software, age is clearly a factor in deciding whether an application is legacy or not.
Operating systems like Windows and Android have components that haven’t been updated for years and years. Why? Because they still do what they were built to do, and there hasn’t been a need to change them. Having said that, if the technology used to build that code is obsolete and unsupported or if an application only runs on an old, unsupported operating system, then this is a problem.
Having legacy software is fine, right up to the point when it isn’t. Older technologies sometimes are incompatible with newer tools, potentially preventing a business from taking advantage of new opportunities. Security vulnerabilities in legacy applications can introduce a risk from malignant actors. Finally, software developers like to use modern tools, and at some point, it becomes hard to find people with the skills and desire to work on older codebases.
The cost of maintaining legacy software is often estimated to consume between 60% and 80% of IT budgets. A report by the US Government Accountability Office found that 80% of America’s IT budget was spent on maintaining software systems, many of which are outdated. So, how do we get to this point, and more importantly, what steps can we take to avoid our software becoming legacy?
The ever-increasing rate of innovation means it is almost impossible to keep up-to-date with the latest versions of any tool. With minor updates often every week and major updates sometimes only a few months apart, it’s not surprising that applications rarely use the latest versions of any 3rd party dependencies.
Leaving aside the technology aspect, in order to respond to changing market demands, businesses often need to adapt their processes or the data they store. Unless the software is kept up-to-date then it will eventually not be able to support these new processes, thus rendering it obsolete.
Ultimately, most businesses simply view software as a cost centre. Once they have paid for it, finance directors rarely want to keep paying, and CEOs would much prefer to pay for something to support the new thing they want to do rather than update something that mostly works ok. This leads to a lack of investment in existing software, both third-party systems as well as any bespoke software. What they forget though, is that the longer they wait to upgrade to a newer version, the more difficult and more expensive it will be.
Having defined the problem, what steps can we take to avoid our software becoming legacy?
Building software with longevity in mind involves a commitment to modular design, open standards, and an architecture that anticipates change, allowing for updates and enhancements without foundational overhauls.
Where in the past, developers often built rigid monoliths that were hard to deploy, we have moved to a world of services which can be deployed multiple times in a day. New functionality simply involves either creating new services or updating existing services, ensuring any interfaces remain unchanged.
A key component of future-proofing software is simply keeping existing software up-to-date. Development teams should be encouraged to follow the old Boy Scouts rule of leaving the code better than they found it whenever they open a piece of code. This may involve a small amount of refactoring, renaming variables or methods to improve readability, but just as importantly, updating any dependencies to the latest versions and, when appropriate, updating the language of the component to the latest version. This also applies to tools like databases. These small incremental changes will ensure the software doesn’t depend on obsolete technologies.
Some components are not updated very often. To ensure these stay up-to-date create a maintenance schedule where each component is reviewed and updated at regular intervals, perhaps every 3 or 6 months. This also applies to any third-party tools such as databases or queuing systems. If you are using a managed service from a cloud provider like AWS or Azure, these will be kept up-to-date automatically, but if you are managing a tool like SQL Server or Mongo yourself, it is important not to allow it to become very out-of-date. It is also important to keep track of cloud providers retiring services so you can move off them early if necessary. Doing so will lead to developers not being able to use the latest libraries to interact with them and prevent your team from benefiting from improvements and new features.
As well as keeping software up-to-date, we need to support developers to stay abreast of industry trends, emerging technologies and best practices.
When times are difficult, training is often the first thing to be cut. However, when it comes to technology, this can be a false economy. While ideas like setting aside Friday afternoons for developers to study may seem expensive, the benefit comes when the learnings make their way into what teams are working on.
This also has the benefit of motivating the team. While software developers obviously want to be paid well, at heart they tend to do the job because they enjoy solving problems and playing with technology. Countless developers attend meetups where they share their knowledge and experience, free of charge, with other developers. Supporting developers with training will help make them loyal and motivated.
In conclusion, while the challenges posed by legacy software are significant, they are not insurmountable. By embracing a forward-thinking approach that incorporates scalable architectures, regular updates, and continuous learning, organisations can effectively mitigate the risks associated with outdated technologies.
Investing in these areas not only preserves the operational efficiency and security of business systems but also ensures that IT infrastructures can evolve in tandem with industry advancements. Moreover, such investments contribute to cultivating a motivated and skilled workforce, capable of driving innovation.
As the technological landscape continues to advance at a rapid pace, the commitment to maintaining and updating software systems becomes not just a strategy for avoiding obsolescence, but a fundamental business practice that supports sustainable growth and competitive advantage.