Everyone Should Maintain Legacy Code
The Project Nobody Volunteers For
Every team has one. The old system. The one with the module everyone refers to by nickname, the one where the deploy has a runbook with a step that says “wait five minutes, don’t ask”.
When it comes up in planning, the room develops a sudden interest in the ceiling.
I understand it, because for a long time I was the same. Greenfield was the good stuff: clean slate, latest tools, no history to apologise for. Legacy work felt like a punishment posting. Given a choice I took the new project every time.
That was a mistake, and it took me embarrassingly long to notice.
The Code Isn’t Stupid, You Just Don’t Know Why Yet
Here’s the reliable pattern. You open the file, find something absurd, and reach for the group chat to share your discovery.
Then you look at the git blame, or the ticket it references, or the very defensive-looking condition just below it, and it turns out that absurd branch is handling a real customer whose data arrives in a format nobody would design on purpose. The “over-engineered” abstraction absorbs a difference between two payment providers you didn’t know you had. The redundant null check is there because something upstream lies.
Not all of it, obviously. Some of it is genuinely just bad. But enough of it has a reason that you learn to ask before you judge, and that habit alone makes you a considerably less annoying engineer.
Archaeology Is a Skill, and This Is Where You Get It
No documentation. No original authors. Ten years of decisions layered on top of each other by people with different ideas about how things should work, half of them under deadline.
So you learn to read the thing like a crime scene. Follow the data instead of the file structure. Use the tests as a specification, even when they’re bad tests. Read commit messages for the moment the shape changed. Add logging and let the system tell you what it actually does rather than what it appears to do.
You cannot practise any of that on a project you started last Tuesday. Greenfield code has no history to excavate, which is precisely why it feels so pleasant, and precisely why it teaches you so little about understanding software you didn’t write. Which, over a career, is most software.
Seeing the Bill Arrive
Legacy code is the invoice for every “we’ll tidy this up later” that was ever said in earnest.
It is one thing to be told that shortcuts compound. It is quite another to spend a Thursday tracing a bug through four layers of workaround, each one added to compensate for the last, and realise that somebody’s perfectly reasonable Friday afternoon decision now costs the company a day a month, indefinitely.
You do not write code the same way afterwards. Not because you become precious about it, but because you’ve met the future and it was unimpressed.
Ugly and Working Beats Elegant and Theoretical
The other thing legacy work knocks out of you is contempt for software that survives.
That grim old system serves real users, takes real money, and has outlived several confident plans to replace it. Whatever its faults, it does the job, and there is a reason it hasn’t been rewritten despite years of people insisting it should be. It knows things. Every strange branch is a lesson somebody learned the hard way, and a rewrite starts by forgetting all of them at once.
So you learn to improve it instead of replacing it. Add tests around the bit you’re about to touch. Refactor the edges where it’s safe. Put a new implementation behind the old interface and strangle it across gradually, boringly, over months. Evolution rather than revolution.
That is the actual skill. Almost nobody teaches it, and almost every job needs it.
Legacy code is the invoice for every “we’ll tidy this up later” that was ever said in earnest.
The Argument Against, and Where I Might Be Wrong
Not all of it is educational, and I don’t want to pretend otherwise. Some legacy code was written by people who didn’t know better and maintained by people who’d stopped caring, and there’s a hard limit to what suffering teaches you. Reading a thousand lines of nonsense doesn’t automatically make you wise, it mostly makes you tired.
The opportunity cost is real too. Time in the old system is time not spent learning things the market currently pays for, and if you’re early in your career and trying to build a CV, that trade isn’t free.
It’s also entirely possible I’m romanticising the whole thing because it’s what I happen to have done. Younger developers may pick up the same lessons somewhere else entirely.
The one thing I’d say firmly is that there’s a difference between a rotation and a sentence. Long stretches in genuinely unmaintainable code, with no support and no mandate to improve anything, wear people down rather than teaching them. If you’re going to send someone in, give them permission to make it better, or you’re not training anyone, you’re just staffing a punishment.
If You’ve Only Ever Done Greenfield
- Volunteer for the migration nobody wants. It’s the fastest education available
- Take the maintenance rotation, and actually read the code rather than pattern-matching a fix
- Before you criticise anything, find out why it’s there. Blame, tickets, the commit message
- Write a test around the bit you’re changing before you change it
- Improve one small thing every time you’re in there, and keep the cleanup in its own commit
- Write down what you worked out. You are the documentation now
- Ask for a way out if it becomes a sentence rather than a rotation
The old system will teach you things no tutorial can, mostly because no tutorial has ever had to keep a real business running for a decade.
Until next time, happy coding!