I can always seem to tell the developers who are accustomed to working on new projects and those that generally work on legacy codebases.

When I run into a bit of legacy code that is giving me trouble or just need to vent, the ones who often work on new code or maybe are the only developer at their company always seem to give the same sorts of feedback — very little of which is helpful. Sometimes I might be asked, incredulously, why such-and-such design choice was used in the first place. (Who knows? I didn’t write it. I’m just tasked with adding functionality to it, integrating with it, etc.) They after a bit of back-and-forth, the recommendation is inevitably a full rewrite, starting from scratch in technology ‘x’, using methodology ‘y’, or framework ‘z’. Honestly, it’s so adorable they think that a complete rewrite is always the answer… Especially when it’s a long-lived application used day-to-day by the business to make money.

The developers that work a lot on legacy code, though, they get it… They know it takes finesse to slightly tweak the code here and there in just the right way to make things just a little bit better as things go, without potentially breaking stuff for the end-users.

Legacy code is generally this thing no one wants to touch, know one really understands, and everyone is afraid to break. It won’t be using the latest sexy new technologies. The code will all be written with more anti-patterns than best-practices. But so what?

Businesses are there to make money. They aren’t there just because they don’t want developers living on the streets… A lot of the time, the most cost-effective business decision is to keep the legacy system running for the least amount of money. Doing a full rewrite just so it’s in some other language or framework isn’t attractive to the business. They just want it to solve a specific business problem. That’s what I’m there for. I make things work.

That all being said, it drives me nuts when the most junior of development staff get tasked with code maintenance. I get that most people don’t want to work on that stuff, but skill and experience will generally serve you better in that situation, whereas new code (that likely isn’t even getting used yet) is probably a much more forgiving place to let the new developer cut their teeth on some business problems…

Maybe I’m just an outlier, though. I mean, I do really enjoy making systems from scratch. But I think there’s something to be said for the thankless job of being able to look at someone else’s code (and, as all developers know, everyone else’s code = ugly code), rolling up your sleeve, and saying, “I’ve got this…”