The Challenges of Legacy Code
When processes and people are working well together and everything is running smoothly, few problems arise that are worthy of a shudder-inducing name. After all, things couldn’t be better…until something comes to a screeching halt. In the software world, one of the increasingly common causes of that is legacy code.
Variously defined as “spaghetti code”, “ball of mud”, and other less polite terms, legacy code tends to have these or a combination of a few of these five trouble spots.
- People can’t understand it.
- The automated tests are not adequate or don’t exist.
- It is hard to debug.
- Deploying is difficult and may take a very long time.
- The code won’t run because the feedback cycles are so slow.
Oh, and this code is usually holding up some highly important aspect of the software that in turn is essential to the business. Compounding the issue perhaps is the fact the the people who originally wrote it are not with the company anymore.
Maybe the underlying code needs to be dealt with in some way or another so that even more things do not come to a rocky halt. Or the system itself is now so unwieldy that changes are a given. Sometimes, it’s just a question of what has to be changed and where is it? What can we do with it?
Work Around It
It is tempting to just add another layer (if possible) of code to fix the issue. The problem is that, depending on the circumstances, it won’t be a long-term fix. By and by, someone else will have to go back through and add yet another layer to the situation.
One of the places that the work around it method does solve problems is when the issues are smaller and somewhat centralized. In these cases, huge fixes aren’t required or necessarily needed by the software. As long as the solution is well-documented for others who may need to work with or on it in the future, working around it in this case is a viable option.
The most drastic of the possible solutions, a rewrite of the code may seem the worst or the best course of action. When the infrastructure is seemingly impossible to work with any more and every attempted fix creates a host of new problems, a rewrite may seem to be the only solution.
This solution must be approached very carefully in order for it to work. No matter how generous the time estimates may be or how good the developers’ skills sets are, rewriting the code from scratch will always take more time, resources and effort than anticipated. And a rewrite in its turn has the potential to become more legacy code which would compound the problem. This is not to say that rewrites don’t have their time and place–but approach with caution!
Work With It
Perhaps the most frustrating solution of all for the developers involved is to work with the legacy code itself. Though it may seem impossible (and, again, maybe the situation is impossible), this code was originally written by and made sense to another human being. At some point in time, it did work and worked fairly well. What changed and how do you find it?
Yes, this does mean some days will seem endless as you work on changing one tiny thing at a time only to have it blow up in unexpected directions. Lots of people won’t understand what is going on and may challenge the need for these changes. However, despite the drawbacks and frustrations, this is one good way to ensure that you are not creating more code that will be the legacy code of tomorrow.
These are far from the only solutions available to deal with legacy code. In fact, since legacy code itself is wildly diverse from project to application and everything in between, you could say that a different solution exists for every situation.
Here at Swan Software Solutions, we understand the challenges of dealing with legacy code and the frustrations of trying to make something work once again. With thirteen years of experience behind them, our team of architects, project managers, developers, and quality assurance managers are ready and willing to help you solve your software issues. Contact us today to learn more and begin your solution!