Legacy Code: Rebuilding Working Software


Legacy Code: Rebuilding Working Software

Do you find that in recent times, it’s become increasingly more difficult to support your company’s system? Are you struggling to find developers who can get the job done? Have development rates over the years grown progressively more alarming? You could be relying on outmoded legacy code.

Yes, gloomy though the thought may seem, it doesn’t matter how cutting edge or top of the line your product once was — eventually, it is bound to become outdated and pose far more problems than actual solutions.

This is why it is so vital to approach your legacy systems with a well-informed dosage of both foresight and caution. So to help you in this regard, Software Planet Group would now like to outline below some of the commonest approaches for dealing with this nagging issue.

Legacy Code Rebuilding Working Software Img


Rebuild and Replace Legacy Code

Perhaps the most popular approach of all, the rebuild and replace method posits that businesses should simply do away with their old, decrepit systems and instead hire new programmers who will start again from scratch.

This is definitely an understandable move, as on the positive side, it is certainly plausible that eventually, some day in the future, you could end up with a modern solution even better than the one you had before.

On the other hand, of course, this is also never a guarantee. Instead, the only things that can be said for certain are that your software solution will likely take much longer to reform than what you had originally anticipated and any valuable business knowledge that was gained through your previous system will all but unequivocally forever be lost — a price that many companies would be disinclined to pay.

Bite the Bullet

Of course, simply doing nothing is always a conceivable option, and as misguided as this non-solution may immediately appear to be, many companies today have resigned to waving the white flag.

The obvious problem here, however, is that as time goes by, not only will it become harder and harder to support your company’s system, but you will also be condemning your users to a perpetually subpar experience.

Accessing data, for one, is sure to become clunky and unintuitive and simple tasks such as generating reports could take days instead of just minutes!

Autogenerate Code

Yet another prevalent way to tackle your legacy systems is to simply make use of conversion tools that will automatically translate your code.

In this way, for instance, if a company with an older PHP system would like it to match their .NET upgrades, they could easily rely on conversion tools to accomplish the task with just a few clicks.

But alas, things are not always as they seem, and in this case in particular, speed and convenience are entirely farcical, as supporting such a system might be even more complicated than rebuilding the program from scratch!

This happens because unlike human programmers, computers keep naming conventions as intended for the original language. As a result, to any software engineer, the final source code will be virtually unreadable.

Rebuild Legacy Code Bit by Bit

The last approach that we would like to highlight is Software Planet Group’s route of choice. Essentially, we propose something very similar to what our company were able to achieve while working on our reliable, but ever-ageing Hercules system.

Because at the time, Hercules’ backend was in need of a massive upgrade, rather than immediately doing away with our older system at once, we instead decided to make gradual improvements that would steadily enhance our system. Consequently, with this fresh new mindset, a couple of things became clearly apparent:

1. It doesn’t matter if your company are running a multi-page application (MPA)

Even though our goal was to turn Hercules into a single-page application (SPA), this in no way interfered with our company’s iterative approach. By building a web server for our eventual SPA, we were able to run it side by side with our old-time legacy server and thus slowly replace each page with a newer single-page equivalent. In the end, after enough pages had been redesigned and developed in the newer format, we merged all of them together into a modern SPA system — and finally did away with our older MPA code.

2. You cannot make big UI changes from the start

Of course, it is important to note here that by very nature, this approach does not lend itself towards any big, initial UI revamps. However, from the user’s point of view, this is actually a major advantage!

After all, instead of all of a sudden gifting users with a shiny, but unavoidably disruptive experience, you can slowly ease them in by reconnecting with your target audience. In the case of Hercules, for instance, we made multiple announcements about smaller, gradual improvements being put out here and there, and gently warmed our users to the concept of great changes to come.

3. Your legacy code will be given new life

Above all, the best thing about a bit-by-bit approach is you can rest in the knowledge that your program will be back on track. In fact, even though throughout a good portion of development, your customers will probably believe that no changes at all have taken effect, under the bonnet, this will certainly not be the case. Just as with any other active phase of development, you’ll continuously be blessed with newer features and fixes. Even better, should your business priorities change, we can make the adjustments you need and shift our focus towards whatever it is that you would like us to develop first.

Knowledge Is Power

Though the legacy code problem is undeniably a tough nut to crack, in the end, it proves mainly an exercise in caution, as it is not always the obvious choice that will lead to the finest conclusion.

At SPG, for our part, we have seen firsthand that a gradual, iterative approach to development is by and large the optimal way forward. Nonetheless, we also recognise that this may not be the path for you. By equipping yourself with a thorough awareness of the tactics, side effects and potential results of approaching outdated systems, you are able to uncover the best course of action that will suit your company’s needs.

Until then, as always, we stand ready to assist you in any way we can. 

Related Stories

So Your Application Has Finally Been Delivered. What Comes Next
January 30, 2018

So Your Application Has Finally Been Delivered. What Comes Next?

For first-time entrepreneurs, the logistics of adequately maintaining applications can often be surprising and even a little confusing.

March 11, 2019

POC vs Prototype vs MVP — Steps to Market Readiness

Though POC vs Prototype vs MVP will often get thrown around by techy developers all the time, deciphering what they mean can often be a challenge.

SPG Slava Ukraini cover image
August 24, 2022

Happy Ukrainian Independence Day!