Are You Afraid of The Code That Smells?
I worked on quite a few large long-running projects in my career. There were times when I’ve been with a team right from the start of project and there were times when I’ve joined in the middle of project. In both cases project had its “legacy” part. That’s how people call it.
What is that “legacy” code? Usually “legacy” is perceived as something bad, nasty, something that people avoid. But why is that?
Legacy code might have been inherited from a previous similar project. Or there might have been a part that had to be refactored at some point, but it didn’t happen for some reasons, making this part smelly. This doesn’t sound pleasant and doesn’t cause good feelings. Hearing that makes one eager to throw away everything and start from scratch. And I can understand it.
But legacy code also may be a well-tested solution people spent dozen of time on. It may be a little bit (or completely) outdated.
Throwing away such code would be a big waste.
It may seem ridiculous, but just think about it: even smelly code is tested at some degree. It’s dirty, non-extendable, hard to understand, but it works. Throwing away such code could be a huge waste too. It depends on particular situation, but simple estimation of rewriting “legacy” part could give a better picture.
Besides everybody should keep in mind how bad programmers are in estimation.
Is legacy code so bad?
Legacy code or technical debt
Often people misinterpret the term “legacy code” as “bad code”.
If we think about cases I’ve mentioned earlier, legacy code may be pretty useful and decent. So why would one want to rewrite it?
There are two primary reasons for it:
- One found the code hard to maintain.
- One failed to understand the code
Only former is an objective reason for rewriting the code, but I often find developers motivated by the latter. Though they don’t even realize it or can not admit it.
The only good reason to rewrite some code is a technical debt.
So if code works and is maintainable, it doesn’t matter whether it’s legacy or not. This means that prior to deciding what to do with the code, you have to spend some time to evaluate its current state.
In order to come up with an objective decision, you have to understand the code. This is the part where the most of developers fail.
Fight with technical debt, not with old code.
It’s not mine
When was the last time you thought something positive about the code written by other people? Think about how many times you gave positive feedback vs negative? Developers tend to criticize code just because it wasn’t written by themselves.
Unfortunately arrogance is a pretty common sin among developers. It makes one think that he/she is better than others. I occasionally catch myself on arrogant thoughts, but I force myself to stop and think.
We’re all humans after all. A person that wrote that code might have the reason to write it that way. It might be a tight deadline. Or family problems. Whatever. It’s not an excuse for a technical debt. But yet. Once you get tolerant to others’ code, you find your life much easier.
The ability to understand others’ code is essential for any developer.
Putting your hands in the dirt
I’m afraid that I can break something
Yes, many people are afraid of breaking something. But come on! When you write new code you can break something too.
We’re living in a time when there definitely is a CVS system. Make your refactoring on a branch and test it well.
Unit tests are also pretty common today. Write a bunch of tests prior to refactoring. It’ll help you be more confident making changes.
I’m afraid to delete code
Often the thought that you might use some code later stops the urge to delete unused parts. Truth is that you barely will use a tiny part of it. And even if you will, you can restore any part of the code using CVS.
Code base grows over time. Even if unused code is not slowing down runtime, it’s slowing down compile time. It’s slowing down your IDE. It’s slowing down you, making you think what’s really used in application and what’s just lays there waiting to be “reused”.
Deleting the code is my favorite type of refactoring.
Technical debt accumulates over time, so stop searching for excuses and start doing something about it. Technical debt directly affects project health. If you don’t keep an eye on it, project will eventually die.
Start with small refactoring. But be consistent. Consistency may dramatically change the situation.
Be the healer. Don’t be afraid of dirty work. That’s not so scary after all.