It’s a bit like Barney Ross…
For the 0.5% of you who aren’t aware of who he is, he’s an Expendable. He’s old as shit with a dodgy hip (this is an assumption) and a quick trigger finger who keeps getting hired to go on dangerous high-priority missions. Half his face doesn’t move, he can barely speak properly and probably needs to pee pee five or six times a night.
But he’s still crucial. Here’s a picture:
So how’s this relate to Software Engineering? Well, despite having a face ravaged by botox and bad life choices, Barney Ross gets the job done even though he probably needs to spend his evenings reading the newspaper in his slippers rather than having fist fights with the bad guys.
Similarly, legacy code may not be ideal, but it does a job.
Tenuous links to fictional action heroes aside, let’s be honest—legacy code is probably the reason you’re getting paid.
Legacy is everywhere
The moment code hits production, it becomes legacy. Once a piece of software is live, it's already a step away from being the cutting-edge solution it once was.
Just like Barney Ross, who might not be the youngest or the most glamorous, legacy code starts to show its age the moment it’s deployed. The new features you’re excited to add today will eventually become outdated, and the quick fixes you’re implementing to meet short-term goals will eventually reveal their cracks. Whether it's outdated libraries, missed optimisations, or outdated documentation, what’s fresh today is tomorrow’s technical debt.
Legacy is not just something that happens after years of neglect—it starts the moment something is released, and maintaining it becomes a continuous challenge.
An underrated skill
Are you a software developer looking to stand out? Want to show your value in a way that doesn’t rely on the latest cool frameworks or trendy buzzwords? It might be time to list "working with legacy code" as a key skill.
Legacy is an integral part of most businesses, and knowing how to handle it could be the thing that truly sets you apart from the pack.
When it comes to legacy code, you’re not just maintaining or migrating old systems—you’re part of strategic decisions that shape the future of a product.
Updating strategies, refactoring, and adhering to coding standards can make the difference between a smooth transition and an inevitable disaster. Each time you’re faced with the decision of whether to refactor a piece of legacy code or just patch it up with a quick fix, you’re making a conscious compromise.
That decision isn’t just about the code; it’s about weighing the immediate needs against long-term sustainability.
A well-documented codebase is a gift, but many of us are forced to work with systems that have zero documentation or the documentation they have, reads like Ikea flat pack instructions. Writing your own documentation as you go or updating the existing one can make a massive difference for the next developer who needs to step in and take over.
Imagine if you utilise the above to your advantage? Imagine if you could give examples where you’ve:
Refactored a code base.
Brought a code base up to standard.
Documented code for other developers who may work on it in future.
And, on top of that, imagine you’re able to explain the decisions behind your technical choices and tests with confidence. This isn’t just about surviving legacy code—it’s about mastering it, and that’s a skill worth showcasing.
So, the next time you’re reflecting on your skills, think about how you can use your legacy code experience as a major differentiator. It could be the thing that makes you stand out from the crowd.
Bring it up during interviews and use it as a key selling point. It’s a great way to expand on typical interview questions like, “Can you tell me about a challenge you’ve faced and how you overcame it?” and the like.
What if your current company sucks?
Let’s face it: Not all companies are proactive when it comes to legacy code. Some are stuck in a “fix it as it breaks” mentality, where legacy systems get patched with quick fixes rather than being properly refactored or maintained. If your company doesn’t prioritise legacy code, or lacks the in-house expertise to manage it properly, it can be incredibly challenging.
But here's the thing—this can also be one of your greatest opportunities as a developer.
While you may feel frustrated with a lack of foresight or investment in legacy code management, your ability to navigate these challenges can set you apart. You’re not just working on legacy code; you’re becoming the expert in dealing with it. You’re the one who sees the cracks in the foundation and understands the long-term consequences of neglecting proper maintenance.
What can you do about it?
Start Small, Advocate for Change: You don’t have to overhaul everything overnight, but you can start by making small improvements that make the codebase more maintainable. Advocate for technical debt management as part of the company’s overall strategy, even if it’s on a smaller scale.
Be the Change Agent: Sometimes, it’s about leading by example. Start refactoring when possible, write clear documentation, and create internal discussions around best practices for managing legacy systems. Over time, you may help shift the company culture toward better practices.
Make It a Learning Opportunity: If your company isn’t prioritising legacy code management, use it as a chance to learn. Every time you encounter a poorly designed or outdated system, try to extract a lesson. This can help you develop strategies and approaches for tackling legacy code more effectively, and you’ll be better equipped for future roles or projects.
Know When to Speak Up: It’s also important to know when to voice concerns to management. If your company is pushing short-term fixes at the expense of long-term viability, this could eventually lead to costly failures. Presenting the case for proactive legacy code management can not only help the company but also position you as a leader within the organisation.
What if you’re still stuck?
Sometimes, no matter how much you push for change, a company simply isn't willing or able to make the investment in legacy systems. In these cases, it’s crucial to know when to move on—either by looking for a company that understands the value of maintaining legacy systems or by moving into a role where you can make a more significant impact.
At the end of the day, working with legacy code in a company that doesn’t prioritise it might feel like swimming upstream, but it’s also a chance to sharpen your skills, advocate for better practices, and position yourself as the person who can manage the chaos.
Don’t disregard your experiences
So, what’s the point of this article?
Don’t disregard your experience with legacy code. Use it to your advantage. The next time someone asks about your skills, don’t shy away from mentioning how you’ve maintained, refactored, and migrated legacy systems. It might not be as shiny as the latest framework or a new language you’ve mastered, but it’s an invaluable skill.
Legacy code might not be sexy, but working with it is something that will give you an edge over other candidates. The challenges you face with legacy systems aren’t just technical—they’re problem-solving, strategic thinking, and decision-making skills that are critical for long-term success in software development.
So, embrace your legacy code experience and turn it into your advantage.
You got this!
Yep. I know. That’s Rambo. Not Barney Ross.
The Grumpy Dev is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.