How to Talk About Legacy Code in English

Legacy code conversations are surprisingly easy to get wrong in English, because the natural vocabulary for describing old, hard-to-change systems can sound like a personal criticism of whoever wrote it — including, sometimes, yourself a few years ago. The goal is to describe risk and constraints honestly without implying blame, especially since the original authors may still be on your team, or in the room.

Describing the Current State Neutrally

Lead with observable facts rather than judgments about quality.

• “This module was written before we had an established testing convention, so it currently has no automated test coverage.”
• “This system predates our current architecture standards — it was built under different constraints, with a different scale in mind.”
• “This code has grown organically over several years and several teams, so the original design intent isn’t fully documented anywhere.”

Explaining Why Change Is Risky

Frame risk in terms of the system’s properties, not anyone’s competence.

• “Because there’s no test coverage here, even a small change carries real risk of an unnoticed regression.”
• “The business logic and the database access are tightly coupled in this file, so touching one often means touching the other, whether you intend to or not.”
• “There’s a lot of implicit behavior encoded in this function that isn’t obvious from reading it — several edge cases only make sense once you know the historical incident that caused them.”

Making the Case for Refactoring

Connect the technical argument to business outcomes stakeholders care about.

• “Refactoring this module would reduce the time it takes to ship related features, since right now every change here takes roughly triple the estimated time.”
• “We’ve had three production incidents originating from this area in the last six months — that’s a strong signal the current design has reached its limits.”
• “This isn’t about rewriting for its own sake — it’s about reducing the ongoing cost of every future change that touches this part of the system.”

Responding When Someone Is Defensive About Old Code

Sometimes the original author is present, and the conversation needs extra care.

• “This code solved real problems for a long time — the context has just changed since then, and that’s normal for any long-lived system.”
• “I’m not questioning the original decisions here — they made sense given what was known at the time. I’m flagging that our current constraints are different.”
• “None of this is a criticism of you personally — every system this old accumulates the same kind of complexity, regardless of who wrote it.”

Discussing Incremental Improvement

Native speakers often frame legacy work in terms of gradual, low-risk steps rather than a single large rewrite.

• “Rather than a full rewrite, let’s start by adding characterization tests around the current behavior, so future changes have a safety net.”
• “We can carve out one well-defined module at a time and modernize it in isolation, instead of taking on the risk of touching everything at once.”
• “The goal for this quarter isn’t to finish the refactor — it’s to make the next change in this area meaningfully safer than the last one.”

Vocabulary Reference

Key Takeaways

• Describe legacy code by its observable properties (no test coverage, tight coupling, undocumented intent) rather than by judging its quality.
• Frame risk and refactoring arguments around business outcomes — incident frequency, delivery speed — not just aesthetic preference for cleaner code.
• When the original author is present, explicitly separate “the context has changed” from any implication about their competence.
• Favor incremental improvement language (characterization tests, strangler pattern) over “rewrite everything,” both because it’s usually the better plan and because it’s an easier case to make.
• Keep the conversation focused on the system’s current constraints, not on assigning responsibility for how it got that way.