Strumenta 
Your company depends on codebases older than the new intern hired last week. So what? Should legacy modernization be part of your strategy?
In this article, we discuss the implications of having a legacy codebase. Let me spoil the conclusions: in some cases it is just fine, while in other cases there are risks connected to this situation. We will discuss how to distinguish these situations and what to do about them.
Can you tell me if this is going to be fine?
When you ask the doctor if you are fine,they usually respond with a series of questions, starting from ‘Where does it hurt?’. Now, I am not that kind of doctor, but I will ask a few questions of that sort anyway. Based on your answers we can understand if you are fine. And there is no need to lie, as I promise that you will not get a shot in any case.
We can look at this from two points of view: the business perspective and the technical perspective.
The business perspective
From the business perspective we should consider:
- Are you spending a ton of money on hardware?
This could be the case if your code can only run on certain proprietary hardware that certain vendors rent to you for a substantial amount of money (did someone say IBM?). The question you should consider is: irrespectively for the absolute amount, is that cost making a difference for you? Is paying this price making your business less viable?
- Are you spending a ton of money on software licenses?
This could be the case if you run software depending on some software platform that is licensed to you for a non trivial amount of money (did someone say SAS?)
- Are you worried about the future of the platform you are using?
Are you depending on hardware or software that you think could not be supported a few years from now? This is a tricky one, as it requires you to be able to predict the future, to some extent. Because you cannot just wait for your vendor to go out of business or stop supporting a product, but you need to anticipate it. The reason is that, if you need to migrate, you will need some time and you do not want to do that under a crazy deadline.
- Do you have issues finding the right developers?
If you cannot find at all developers who can maintain your system, that seems a pretty clear sign that you have a problem. But, depending on your situation, you could have a problem also if you cannot find skilled developers and you need to train them yourself. In this scenario you may end up spending a lot of time and money to train your developers, just to have them leave for greener pastures as they get a bit of experience under their belt. This may be a problem, because it takes time to familiarize with your venerable code base.
The technical perspective
From the technical perspective we should consider:
- Do you have issues scaling the system to support more users or process more data?
Is your system having issues coping with a growing user base? Are batch tasks that used to run in one hour now taking the whole night to be completed? Is your system designated in a way that you cannot just throw an extra server and be done with it? If this is the case, it seems like you have a bottleneck preventing you to get more business.
- Do you have issues integrating your system with other systems?
Does your system need to integrate with web applications, with external APIs, or with some other solution and is this just a pain causing strategic integrations to be canceled or delayed?
- Does the speed at which development goes affect your business?
Does it take you quarters to develop features that your competitors can release in weeks or months? Is this putting you at a significant disadvantage?
- Does the cost of development affect your business?
Perhaps you can develop at the same pace of your competitors (or at a comparable pace), but you can do that by throwing way more money at the problem that they need to, and this is causing your costs to be way higher than theirs or just not leaving the margins you want.
- Do you have trouble keeping up with changes due to regulations?
Are you working in a field where changes in regulations have to be reflected in your software in a reasonable timeframe? This is the case for example for software for tax calculations, or software that needs to follow healthcare or financial regulations. If this is your situation, are you regularly facing challenges implementing the changes at the speed imposed by the regulators?
What is the response?
I hope the previous points helped you to look at the situation from different angles. If after this check up you feel that it does not hurt in any specific place, then it is all good. I think you can go back to look into other problems because your legacy code base is not the problem you need to fix right away.
However, if you encounter some issues after all, now we need to figure out what you should do about it. We will see that in the next paragraph.
Ok, so what can I do about this?
Well, I am an engineer, I can only answer “it depends”. The long answer is contained in a course on Legacy Modernization we created that is a few hours long, but here we want to look at this from a 10,000-feet-view.
- You need to understand if you have a technical problem or an organizational problem
As much as we would like to think that we can solve all issues “simply” by acting on the technological level, the harsh truth is that this is not the case. Some of the problems we identified in the section above could be either due to organizational challenges or to technical challenges.
For example, development could be way too slow not because of the technologies you adopted but because you cannot converge on the right requirements in a reasonable time.
This is something to consider, because as much as we would be happy to help you with legacy modernization, if your issues are organizational, it would not solve your problems and you would not be a happy client.
- Then you need to look at the alternatives
Assuming your problem is technological or it is also a technological problem, we can look into the specific problem to check which solution you can apply. In our studies we identified seven different techniques we can apply to solve problems with legacy code. Some of them are solutions to very particular situations and are rarely applied. In this article we want to keep things as simple as possible, so we will focus on the three that are most commonly used, as they cover well over 90% of the situations. In the section below we will look at them one by one.
We are ignoring one option that is often marketed as a “Legacy Modernization technique”. I am referring to the option that consists in keeping the code largely as it is, but spending some effort in documenting the old code base, refactoring it a little bit, maybe adopting a new IDE or buying some tool to help navigate the bowl of spaghetti code you have and be done with it. This technique is the “lipstick on a pig” technique.
The “lipstick on a big technique” has its role, and if your pain is not too big then it may work. However this is a rather obvious solution, and this is probably something you have already considered. So we only focus on the techniques that cut a little deeper, and take out the problem at its roots.
- You need to make a decision
Here is when the ball is on your side and you need to pick an option. We will share some suggestions below.
The three most common approaches to Legacy Modernization
Below we list the three ways in which you can go from a legacy codebase to one that you feel confident maintaining and evolving. They are going for a manual rewrite, or perform transpilations, either once and for all, or continuously. Let’s see what this means and what are the consequences.
Manual rewrite
This technique is rather obvious: you just pick your existing application and you rewrite it, from scratch. It is very interesting from a sociological perspective, how this is a very frequently chosen solution, while being the most costly and the most risky. But I guess we have an intrepid spirit, or we would have chosen a different career. What typically happens is that we look at a system that has been around for a long while and we:
i) vastly underestimate the effort that was put in creating the system and evolve it
ii) we think that we can do so incredibly better than the people who preceded us.
The result is that we try to recreate in 18 months what took 18 years to create. Often we just run out of money and time. I would suggest adopting this solution only if either the code base is relatively small (under 200,000 lines of code) or the requirements changed so dramatically that there is little value in the business logic trapped in the existing system.
One-time transpilation
Here the idea is that you take a module at the time of your application, you run a transpiler on it and you translate the business logic to a different programming language, for example you translate RPG into Java. You could also apply the same approach to move to a different framework, for example from Struts to Spring.
After the transpilation you throw away the original code and start maintaining the newly generated code. This means that you need to re-train your development team, or hire new developers to maintain the portions of your systems that have already been moved to the new technology.
This is typically something attempted after a manual rewrite has previously failed. The challenge here is to produce code that is idiomatic and maintainable, and not all solutions are able to do that. This made some people skeptical about this approach.
Ongoing transpilation
When going this route you keep developing using the old programming language, but you just insert a transpiler in your build pipeline, so that every time your developers write, let’s say, RPG, the code is translated behind the scenes in, let’s say, Java. Your developers only look at RPG code but you can actually deploy a Java application.
This solution is not that frequent, but it is useful when you are reasonably satisfied with the productivity of your team, you have many developers that are familiar with the old language, and your main problems are the deployment platform or the integration with other technologies.
Time to make a decision: what should we consider?
Now that you have looked at the alternatives (at least the main ones), you have a big decision to make.
The typical decision is “let’s wait a little bit longer”. You have many things to worry about, and perhaps if you do not think about your problems with legacy code they will go away. Or perhaps next year there will be more time and resources to deal with it. We are only human, after all, and this is how we typically react.
One part of the problem is that there is just too much uncertainty when looking at such a big decision, and either one makes an enormous leap of faith and just picks one route, or they stand where they are. I think we should instead make exploratory studies to reduce that uncertainty, which means, in our analogy, reducing the gap you need to jump over.
So I would start first of all studying your codebase: examining how it works, examining how much dead code there is, studying how interrelated components are, identifying recurring patterns, looking at how they could be migrated. This is work that can be done for the low tens of thousands of dollars or euros and can give the clarity to make an informed decision. The way we tackle this is through what we call Audit and Analysis. You may perhaps take a look to see what kind of information can be obtained on your codebase and how they can help assessing the situation, make a decision, and then a plan.
Summary
As someone who loves software development I resisted for a simple truth: Corporations are not successful because they have good software in good condition. These are successful despite having bad software in a bad state (thanks to Miroslav Diviš for expressing this so eloquently!).
However sometimes the bad software becomes such an hindrance that is canceling out the advantages the company has, and putting it at a disadvantage. If and when that time comes, it makes sense to examine the situation, understand where the problem lies (is it really a technological problem?), and what we can do about that. Then it is just a matter of looking at the options, assessing your situation and moving forward. This is something that can be done, and there are professionals able to help, so there is no need to ignore the problem and hope for the best.
