The vicious cycle of legacy code

2017-05-10 09:45:37 admin Perl Interests 1 comment

A one point or another in your career you probably worked on legacy code. It brings chills through every programmer’s spine, it creates nightmares and cold sweats in the night. Basically it’s a term that has a very bad reputation.

But what does it actually mean?

The definition:

Technopedia refers to legacy code as:

“an application system source code type that is no longer supported. Legacy code can also refer to unsupported operating systems, hardware and formats”

In the forward of Michael Feather’s book, “Working Effectively with legacy Code” we find this lovely picture about legacy code:

“It conjures images of slogging through a murky swamp of tangled undergrowth with leaches beneath and stinging flies above. It conjures odors of murk, slime, stagnancy, and offal.”

It’s not exactly a pretty sight.

In short, legacy code is a mess. It’s like a rundown house that you would rather just tear down and start fresh, but instead you have to renovate. It requires lots of work, time, stress and pain and almost always it seems that it’s not worth it. But you still have to do it.

I do want to make a few points here. First, legacy code is not necessarily something that was written when Reagan was president. It doesn’t have to be old to be hard to untangle. It could be just a couple years old and written by a lunatic. Second, legacy code is almost always someone else’s code.

The label

The fact is that legacy code means hardships, but the difficulty of untangling it and making sense of it varies from case to case. That being said I think we should be careful when using this label because, no matter the programming language, legacy code has become the boogeyman.

When do we use the label? When do we mark code as “legacy”?

Legacy code is not just something forgotten in the back of the closet. Legacy code is code that it’s in use. Code that you don’t use is not legacy, it’s retired.

Legacy code is working code, it’s not broken. But it works in mysterious ways. It’s hard to figure out because it was written in a way that “went out of style”.

Any code base that is written in your programming language of choice, but you can’t figure out/can’t upgrade/can’t change (easily) is legacy code. Any code base that didn’t went through proper testing, that lacked regular maintenance, that lacks documentation and transparency is legacy code.

Code that works, but can’t be read (easily) by any other developer, is legacy code. Legacy code works, that’s not the issues here, the problem is how it works. When you draw blanks trying to answer this question then you have yourself a legacy project on your hands.

This label “legacy” has devil like connotations for most developers, because it can bring hell to your life, but one can argue that it’s a normal situation to be in, because at one point your code will also become legacy.

The Cycle

Here’s how the cycle begins. You’re working on a project for a company. You may work alone or in a team. You stay there for a couple of years, then you change jobs, Your team members go each to their own. New developers come in. They keep on working. At one point your code becomes legacy and at one point some other developer, that might be in college right now (or in kindergarten) will have a look at it, scratch his head and wish you a very slow death.

Does all of our code become legacy one day?

I would say yes. And no. Yes in the sense that eventually one piece of code or another will gather up dust and the principles that were used on it will become obsolete. It will then cause pain to some other programmer. This is a matter of time mostly. But, as I said,  legacy code is not necessarily old. No, in the sense that in ideal situations, code that will be maintained (not patched) constantly, changed and upgraded when needed, could avoid the legacy label.

But that’s a big could, because, at least in a working environment, not on personal projects, your code is your own while you're there. Afterwards it’s just a part of the wheels that make everything work. What you’re working on today, clear as daylight for you, and your peers, might be a “murky swamp of tangled undergrowth with leaches beneath and stinging flies above“ (see quote above) for someone else in a couple of years. Because we don’t control the changes that comes. And once we’re out, we no longer control what happens to our work. Good code today can become bad legacy code in the future. It all depends on what happens in between.

Leave a comment


    This nailed it on the head for me: Its like a rundown house that you would rather just tear down and start fresh but instead you have to renovate It requires lots of work time stress and pain and almost always it seems that its not worth it But you still have to do it You want to start afresh but cannot do this as the legacy code is currently in production and you cannot just swap it out Going back to the house analogy its like there are folks living in the house and they cannot be moved you are therefore forced to fix the house roombyroom

Subscribe to our newsletter!

Make sure you never miss the interesting stories of Perl startups, apps and projects.