Software developers are often regarded as architects, as their work somewhat resembles that of a civil engineer. They use numerous tools and technologies to build software, just like builders create high-rise structures.
But the reality often isn't that simple.
Sometimes an older, more janky system has to be fixed or improved, and so, now and then, developers have to step into the shoes of mechanics instead.
In today's article, we are going to answer the question of how a software developer can be a good repairman when working on legacy software. Are these systems really useless among today's software architectures? What do programmers have to prioritize when improving a legacy system? Keep on reading to find out!
What is Legacy Software and where to find it?
After 10 years of running and putting thousands of miles on the clock, a car is bound to have some issues. After all, every mechanical part has its limits when it comes to durability.
But does it mean it has to be scrapped?
Not at all!
All you need is an experienced mechanic with some time on their hand, to change the most vulnerable parts, like the timing belt or brake pads and the car can run perfectly fine for the next thousands of miles.
Software development is really quite similar in that regard. Legacy software is in many ways like a used car – it may have some problems and require a bit of refactoring, but generally it works just fine! All you need is a good “mechanic” to take care of it and fix all the most vulnerable parts.
Legacy software definition
On a more technical note, though, we can say that legacy software is a software architecture that is working in production but some of its parts don’t receive continuous updates or support from the manufacturer. We can differentiate three main types of legacy systems:
An older system with unsupported features, or incompatible with new drivers,
Software that’s non-compliant with recent standards in software development,
A software system that has problems with receiving security patches.
Stratoflow CTO, Arkadiusz Drysch, has rather jokingly defined legacy systems:
“Well, basically any system that has been deployed in production can be regarded as a legacy system, as it requires constant maintenance. There’s no such thing in software development as write-and-forget architecture”.
Of course, legacy software may still be in use due to the difficulty or cost of replacing it or simply just from pure convenience. However, legacy software can often cause problems due to its age and lack of support, which necessitates refactoring and redesigning parts of the system.
Why are legacy systems still used?
IT systems usually last for years, but in the meantime, technology evolves at a breakneck speed. That is why companies are often caught off guard when their old software architecture begins to lose support or updates, and it’s time for a more thorough maintenance job. Here are four reasons why most legacy systems are still in use after years of operation:
These systems still provide critical functions to businesses,
Companies lack resources for improving existing software architecture or changing it for newer systems,
The organization lacks the necessary IT skills and knowledge to migrate the legacy system or perform thorough refactorization,
Companies don’t have the technical specifications to create a new system with the same features as the legacy system.
[Read also: The Most Common Problems in Software Development]
Where can you find legacy systems?
Government organizations and public sector
Probably the most common place to find outdated software architecture is the public sector.
Recent research conducted by Dell revealed that approximately 70 percent of government organizations in the US, Germany, the UK, and Japan use outdated software in some capacity.
Furthermore, half of the public sector representatives surveyed said that their legacy operating systems have exceeded their end-of-life date. What’s even more surprising is that among federal governments worldwide, an ancient COBOL is the most popular programming language.
Curiously, in some public sector organizations, you can find hardware that is just as old as these programming languages and technologies.
Companies specializing in retrieving data from broken hardware have to store some key equipment, like hard drives, from as far back as 30 years ago. Why? Well, you never know when let’s say a nuclear power plant that is still running hardware from this age will be in need of a quick replacement.
Banks and corporate systems
Old computer systems and software can also be frequently found in banking sector companies.
According to the Financial Times reports, many well-established finance companies still use software architectures based on COBOL and currently suffer from the lack of developers with experience in this aged technology.
Why do these organizations use such an obsolete programming language? After all, shouldn’t the financial sector be all about high-performance computing?
These critical legacy systems are often responsible for core business processes at these organizations, usually involving large sums of money, and operating literally 24/7. Many managers see upgrading legacy software architectures as an unnecessary risk.
Retail companies
You will be surprised to learn that many retail, ecommerce, and manufacturing companies also use legacy systems. That’s odd since intuition tells us that being up-to-date with recent tech trends is an absolute necessity in today’s competitive market.
Where’s the catch, then?
This comes from the fact that to many ecommerce companies, profitability and sales figures are the top priority. A good chunk of these companies focuses solely on tools and solutions that will have an impact on their KPIs. Since their software architecture doesn’t have a direct impact on profitability, they constantly put it off.
Myths about Legacy software
There are many myths flowing around about legacy systems.
How real are they? Is there really any truth to the memes about legacy systems causing nothing but headaches?
Let’s now have a quick myth-busting session and take a look at the three most common things that people usually say about legacy software on the Internet.
1 Legacy software is unsupported
The IT market is definitely not uniform. In the case of legacy systems, that means that some of their components will become obsolete and unsupported faster than others.
In some situations, there will be little problem with contacting a support team or an account manager with some troubleshooting stuff. In others, vital sections of the system will lack the necessary updates to keep them compliant with the latest security standards.
So just like a car mechanic can have problems with parts’ availability for some vehicles, a software developer may struggle with outdated security measures and obsolete libraries in a legacy application.
Myth – Plausible.
2 Legacy software is useless
A 10-year-old car is still perfectly capable of transporting just as many people and cargo as it used to when it was brand new, even though it may now lack some new, trendy features.
Legacy systems are really similar in that regard. They may pose some risks (which we’ll dive into below), it doesn’t mean they completely outlived their usefulness. In many cases, a piece of legacy software is still in use because it is the most convenient option for ongoing business processes.
So in a nutshell, time doesn’t influence the system’s core functionality.
Myth – Busted.
3 Legacy software and legacy systems should be immediately replaced
Just like a used car, legacy software will work perfectly fine in the future as long as it is well-maintained.
Developers can modernize legacy systems by making sure which parts, tools, and functionalities lack support, or will lose it relatively soon, and update them gradually. Of course, the architecture won’t be as fancy and innovative, but it will work just fine.
Myth – Busted.
Why are legacy systems problematic? 3 most common problems
Of course, developers and product managers wouldn’t be talking about replacing or redesigning aging software architectures if they didn’t cause any problems. After all, in all horror stories about broken legacy code, there’s a grain of truth.
Here are three main issues caused by legacy systems in organizations.
[Read also: How to Build Low Latency Java Applications]
1 Cost
Just like Arek said in the first part, all software systems will require maintenance. Having said that, redesigning and refactoring legacy applications usually is much more resource-consuming, both in terms of time and money.
What’s more, as software solutions become outdated, vendor support decreases. That means that companies may charge premiums to provide support for databases, tools, and libraries that are no longer part of their main product portfolio. In some circumstances, software modernization is a much harder task than building something from scratch, requiring specialized IT expertise from fields that hardly anyone uses anymore.
2 Data Security
A lot of libraries and database vendors are ditching the security updates for older releases of their products and tools after some years. It shouldn’t come as a surprise that legacy systems based upon them are more susceptible to security breaches and dangerous data loss.
In the case of smaller software applications, this should not be such a big deal, but for software architectures storing and managing the private data of hundreds of thousands of users, this is an extremely valid concern.
3 Shortage of knowledge and experience
As the years fly by, and the company sticks to the same software architecture, it might face a real problem with finding software experts familiar with outdated technologies.
Technical universities, and developers themselves, are adapting to the changing technological landscape. Very few people these days are familiar with languages like COBOL, Fortran, or Deplhi even though they were the backbone of corporate-grade software architectures twenty years ago.
Living legacy systems – 3 tips from our experience
So, we’ve already established that even if sometimes problematic, legacy software is still of great use to organizations, and in many cases, new systems are just not necessary. Let’s now point out three tips from our experts on how to avoid headaches when dealing with legacy software systems.
1 Keep track of the most important updates
Since in legacy systems, the biggest concern is the lack of support for certain components, developers should do a risk analysis for update availability in each part of the application.
A development team should ask themselves questions like: How long will these systems be able to operate on the current version? For how long critical components and libraries of the system will receive updates from the manufacturer?
After that, they can plan out their work by giving the riskiest parts of the whole system a top priority in the maintenance queue.
2 Don’t rewrite what you don’t have to
We’ve already established that legacy systems are still perfectly capable of completing the tasks they were designed to do. Having said that, it is always worth doing regular refactorings and looking for opportunities for possible enhancements.
The important thing to remember is that the refactoring process of legacy code should be complete.
Let’s say, a developer decided to refactor the part of the codebase responsible for database access, but completed only 90% of it. Doing so would eventually lead to a situation in which 9 out of 10 times you would connect to the database using the new and improved method but sometimes the old and slower version would kick in.
Such actions are greatly increasing the project’s complexity and hurting the user experience. So the general rule of thumb should be that if you want to improve the legacy system, you can not leave half-completed work.
3 Maintain good documentation, gather the necessary knowledge
A good practice for all developers regardless of the technology and programming language is to maintain proper documentation of the entire software development project.
When working with legacy systems, this practice is even more important and should be taken to heart by all developers dealing with outdated software architectures.
The main reason for that is when different members of the team come and go, you need to have clearly and thoroughly documented what is going on in the codebase. In a legacy system, it is expected that fewer developers are familiar with the technologies used in these systems. So in a situation when the last developer abandons the ship and leaves the project without proper documentation, it is basically doomed, and it has to be rewritten almost entirely from scratch.
Interestingly, Twitter may have had this very problem recently when Musk decided to fire a good portion of the development team who didn’t subscribe to his idea of “hardcore work ethic”. Regardless of your opinion on Twitter’s new CEO this situation really underscores the need for good documentation and a proper knowledge base in legacy systems.
_[Read also: Practical Tips on How to Speed Up the Software Development Process]
_
Living with legacy system – summary
Maintaining legacy systems is considered to be a chore very few developers like.
After all, it usually involves going through sketchy documentation and dealing with solutions and programming languages that hardly anyone uses today.
Nevertheless, just like an old trusty car, it still serves a purpose, offering the same functionalities as when it was brand new. All it needs is some maintenance as it could serve customers for years to come. After all, we have to remember that more often than not fixing something is more cost-effective and convenient than throwing it away for something new.
Top comments (0)