The hidden risks in legacy code
Many organizations rely on computational or scientific software that was written long ago. In the daily rush, no-one stops and thinks about this code. The risks that are inherent to such legacy code remain unaddressed. In this blog, we highlight the most important risks in legacy code and what to do about them.
Risk 1: The knowledge walks out the door
We often encounter a situation where there is only one expert who knows everything about the code. Often, this is the original developer. Whenever there’s a problem with the code or some new feature needs to be built, everyone turns to this expert who will solve the issue quickly.
But as the code gets older, so does the developer. At some point he or she will no longer be available. Even if this developer is in good health, at some point this person retires. And then what?
If the code is indeed important, then someone will have to take over the role of this developer. But this is not necessarily easy. For one, legacy code is typically poorly documented or the documentation is outdated. Also, the code may be incomprehensible for anyone other than the developer. And if the code is written in a language like Fortran or Java, it can be hard to take over by younger developers that are only familiar with Python or C#.
Risk 2: The code is unmaintainable
Many code bases start out as small pieces of code that, over time, grow into large software systems. The original structure is typically not capable of supporting all the additional functionality that is stacked upon it. Even if there was an original structure to speak of. The nice term for this is technical debt. But more plainly spoken: the code has become a multi-headed monstrosity which nobody dares to touch anymore.
This is fine until it no longer is. New features can no longer be added. Bugs cannot be solved anymore. And nobody can really explain how the code works anymore. Even if no changes need to be made, it is typically unacceptable for an organization to rely on software that nobody understands.
Risk 3: It’s no longer possible to make new versions
In extreme cases, the code base itself got lost leaving only the executable that is still used. Then new versions cannot be generated anymore. But even if the code is still there, it may be very hard to compile new versions.
This can suddenly become a problem. For example, if one of the libraries that is used in the application no longer works with a new version of the operating system. If there is no current version of that library, then generating a working version of the executable becomes an acute problem.
This can be even more of a problem if there are no longer compilers for the version of the programming language that was used. For example, code written in Pascal/Delphi has limited tooling support these days.
What to do about the risks in legacy code?
The number one advice when dealing with legacy code is to address the risks in time. If you wait for a crisis, then fixing things may be much harder or even impossible.
If you rely on a single developer and something happens to that developer, all his/her knowledge may get irretrievably lost in the blink of an eye. Or the software may become suddenly unusable if someone discovers that the code is wrong somehow, and fixing it is impossible due to the spaghetti nature of the code.
If you want to address the risks in legacy code, the first thing to do is to assess how serious the situation is. At VORtech, we regularly do what we call model scans, which are basically audits of legacy computational software. Our report gives an assessment of the situation on all relevant aspects, given an overview of the risks and how serious they are and will highlight the issues that really need to be addressed.
Typical mitigation measures are to document the code so that the knowledge of the developer is captured; to refactor the code to bring out the structure; to build proper tests so that the validity of the code can be checked after a change. Only in extreme cases is a complete rewrite of the code necessary: a pragmatic partial rewrite or refactoring is sufficient to improve the code quality to an acceptable level in most cases. But even if a rewrite of larger portions of the software is necessary, the use of AI-assisted programming allows us to do that much faster and more efficient than before.
Are you ready to take on the risks in your legacy software?
We are ready to help you. Feel free to contact us and discuss your situation. For further information, you may want to check out our whitepaper on legacy code and our blog.