About the series

This is part of a series of posts dedicated to talk about the biggest fears that we face as developers.

What is legacy code?

I’m sure that most of us have heard of legacy code, usually associated to something bad.

You probably have your own definition for it, just like everyone else. But let’s (try to) put a face on it.

I went through a lot of different pages looking for a standard to define what’s legacy code, and I came across with this definition and immediately felt identified with it:

Legacy Code is valuable code you’re afraid to change.

or written differently

Legacy Code is the code you need to change and you struggle to understand.

The important thing about this definition is to understand that every person has its own way to see legacy code and that it will depend on how familiar you are with the code and how do you feel about changing it.

Why code becomes legacy?

No longer maintained

There are many reasons to stop maintaining a piece of software:

• It was successfully delivered
• The business priorities changed
• Limited budgets

Regardless of the reason, it’s imposible to keep updated a code that is no longer maintained, and it’s meant to become legacy.

Has no tests

This is a trick one.

It’s clear that anyone would be horrified of changing a piece of code that has no tests, specially if it’s a sensitive part of the software. And based on the initial definition, if you don’t feel comfortable, then it’s legacy code to you.

However, tests can give a false confidence if we assume that they are as good as they should be. And as I see it, that’s even worst than coding worried because there are no tests.

Developer is not around

The reality is, software is built through extensive periods of time, and usually it involves a lot of people working on the same code.

On one side, that’s something good! The more people involved with the code, the more people that can help to work on it.

However that’s not always the case. Sometimes, parts or even the whole software was in charge of a single person and, guess what? That person is no longer around, and it’s not documented, and has no tests... should I keep going?

What can we do?

It’s not always bad

Even though legacy code is considered to be a bad thing, that’s not always the case.

Most of the time, legacy code is still production code and it’s doing it’s job. The only problem is that no one wants to touch it.

What happens when the legacy code is no longer working as expected? That’s a whole different deal!

Your code will be legacy some day

The truth is, you probably won’t be on the same place you are forever. And even if you do, you won’t remember every single piece of code you have written.

Here are some things you can do to avoid nightmares to developers coming behind you:

• Write tests: that would give people some confidence when changing it later.
• Follow standards: understanding code written with the same standards, make the task way easier.
• Document: yeah, probably you hate documenting too. But being honest, there’s no perfect code, and sometimes it’s just hard to read.

Reinvent the wheel or not?

Some people, specially on the business side, might think that re-writing a piece of software will cost the exact same effort and money than the first time. It’s not always the case.

You might want to balance both options, since each case is different from the other, redoing things sometimes is not that bad.

In summary: legacy code is there and will continue to be there, it’s relative to each person and we just can do small things to make it a little less painful.

How do you deal with legacy code?