Legacy Apps
In his latest post, App Dev Manager Timothy Baillis shares his perspective on legacy apps through insights he has drawn from working with various Premier developer customers.
Many developers have had the opportunity to inherit code and applications. When that happens the first response is often to want to rewrite, refactor or kill it if it is using older or unsupported technologies. Oftentimes, we also have to consider modern design and improvement to existing technologies that have made the application obsolete or no longer as useful.
As cloud-based computing has started to reach it real potential, the pressure to do something drastic about legacy code can become truly overwhelming. It’s easy to say we must make a change to the application and code with all this pressure. Certainly, a technical debt will eventually need to be paid. However, taking a deliberate view of the application and code can really help understand the right course of action.
This post isn’t going to be about how to update legacy applications, there are plenty of those online. This post is discussing when and why.
When? Â
A lot of times legacy apps function as intended and continue to provide business value. These apps may use older technologies or platforms but otherwise have only minor issues. Many times, the main issues of these apps are the platform they run on will become obsolete at some point.
In cases like this it is difficult to decide when to do something. Clearly there is a time when the platform could dictate a change. These cases are a chance for organizations to embrace things like DevOps and improve their general level of development maturity to both avoid the issue entirely in the future and to help catalyze a reason to start earlier on the change to the app. However, in the field these are the apps that generally are ignored until the situation becomes critical for the business and the teams involved.
The other possible scenarios generally have more focused end dates. Like the application is already on a completely unsupported platform or written in language no one can support. I don’t want to spend too much time going through them but the main idea is that even if the other question of why has been answered it’s useful to start thinking about when in terms of now. Practically speaking now may not be an option but acquiring the skills, planning for a change, and understanding the risks and benefits of waiting are things that can happen as soon as you inherit the legacy application. Â
Why? Â
I think most people would start with the why when discussing rewriting, refactoring or killing legacy applications, but I think the idea that you will have to deal with them at some point is so strong that really when is the first question. The why often seems like the easiest question, but I would be saying practice it is the hardest. I think it’s too easy to get in the habit of doing things to do them and many times this applies to legacy applications.
If the application is still valuable to the business or the business is not ready it equipped to pay the technical debt required to modernize it starts to make the why a little less clear. Say we use the same example as the when. The application is operating fine but is on a platform that will be discontinued in a known timeframe. The value to the business immediately is low to make a change and even though there is a looking technical debt there may be a way to avoid it by paying someone to support the platform past it’s end of life.
The why is not so obvious until you can’t the cost to the business becomes too high. If you consider that the real why is eventually you will be forced to make a change, you can use the time between now and the re-platform to accomplish a shared goal and gain the skills you need to take this application into the future. That is why in the when, it is useful to always assume when you should be doing something.
Clearly, this is a simplification of all that happens when dealing with legacy apps and their life cycle. Really, it’s something working for Premier Services I encounter regularly. The immediately answer isn’t just to change but the reality is change will be required and approaching it with an attitude that is positive and deliberate can allow legacy applications to drive positive change without being an immediate burden.
Light
Dark
0 comments