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?
Top comments (6)
About rewriting.
At some point in time you need to rewrite or reengineer parts of your system to remove the cruft which is no longer used, and is basically in the way of making things better.
Remember,
Great share here! definitely one of the most common situations for a developer is to come across legacy code.
I think that a good practice to follow to eventually help others devs to deal with legacy code is "modularize your code" - keep the code encapsulated and abstracted according to their functionality can help to understand and refactorize the code in an easier way than if everything is in the same bowl since always is easier understand small pieces of code instead of trying to see the whole tree.
Legacy code is not necessary a bad thing. Some times a piece of software is working as expected and does not need to be changed in a significant way. So it makes sense to just "leave it" at that.
It does become an issue when the software, or parts of it, needs to be changed and maintained on regular basis. This could be because the roadmap or business needs suddenly are focusing on a legacy part of the software. Then is when more care needs to be taken.
When this happens I would usually recommend to "refactor as we go along". Meaning writing tests and refactoring code with as minimum scope as possible. There is no need to rewrite a big part of the application when what we are really after is updating or changing a smaller part of it.
Overall it should be taken in a pragmatic way. My view is that technical debt should be constantly repaid as work requires it. But not necessarily going on a "which hunt" just to conform with arbitrary targets or standards.
Legacy code is by definition a liability. Code always has to change and if you leave parts of it unknown your developers will work around it, growing the problem by warping the code around their limited understanding.
Entire companies have folded under the liability of unchangeable code, don’t be like them. Work against it with tests and aggressive simplicity
True. Technical debt is a liability when not handled properly. There are several approaches you can take to repay technical debt. My preferred approach is to repay constantly as we work on the code that is affected by it.
The important aspect of this IMO is to be pragmatic about it. By addressing technical debt as we encounter it. And by keeping it within the scope of the work we are doing. We make sure that we get the best balance results. Technical debt is repaid, and no "unnecessary" (to the eyes of stakeholders) work has been undertaken.
Totally agree! We should stop seeing legacy code as broken code. It’s usually just old or hard to understand, but it doesn’t mean that it can’t be improved one step at the time.