Maintaining Legacy Code

Since the beginning, we have been working with legacy code. Some things we didn’t write, other bits we did. Most of which is either extremely outdated now, or just doesn’t work anymore. This has been an uphill battle, considering the ever changing landscape of the technology and software world.

Working with new technologies can be nice, but only when they play well with legacy systems. Though, we are finding that not everything plays nice. Systems, new and old are being held together with duct take and bubblegum, just to ensure that they work.

##Code Maintenance

Maintaining the legacy codebase isn’t that difficult once you have a full grasp on what everything does and how all the pieces fit together into the enormous monolithic structure. Unfortunately this is not very efficient, especially when dozens of code changes happen each day, and have to redeploy to production. Rebuilding and redeploying a monolith is time consuming. Especially when it is in the hundreds of thousands, if not millions of lines of code.

Occasionally, something can be patched with a newer technology that allows you to easily maintain and deploy. Other times, you have to go back to the original codebase, shake your head, roll up your sleeves and pray that it doesn’t break.

##Monolith to Microservice

As time progresses, we realize that this monolithic structure just doesn’t work for us anymore, as a deploy can now take hours, and with as many changes as we make in a day, this now puts us days behind in the deployment schedule.

We have started to shift our “patches” to their own services, exposing an API to the monolith, and after extensive testing, we are slowly updating the monolith to reach out to these APIs for the information that is needed to keep that portion of code working.

##A Metaphor

Our legacy codebase can be likened to The Ship of Theseus. Small repairs over long periods of time, parts replaced with new, or completely rebuilt. Is this still the same ship, or is it a brand new one?

We have decided that it is definitely the same ship, but with a fresh coat of paint. At least for now.

As our monolith slowly deteriorates into a collection of micro services, we see that we are no longer maintaining the old legacy code, as we are relying more and more on the new codebase. When does the new codebase completely take over? This is unforeseen at this time. Migration efforts are extremely slow, as we have to continuously patch parts of the ship to keep it functional.

##A Continued Adventure

As we slowly migrate our monolith to these new services, and remove legacy code and replace it with API Calls, we are finding that now we need to eventually replace the front end application. This will be an adventure in its own right.