Why Stable Requirements Don't Make Code Legacy

I strongly disagree with the claim that code written years ago, using poor technical decisions or outdated frameworks, automatically becomes legacy code.

Code exists to solve a specific problem. As long as that problem hasn't changed, the code can remain stable and functional regardless of its age.

It may be imperfect or use technologies that are no longer popular, and a redesign today might yield a better solution, but stable requirements let the code continue working reliably. Time itself does not create technical debt.

Old ≠ Legacy.

Consider two modules I saw years ago: one written in an IBM internal language, the other in COBOL. Both processed millions of transactions daily, and the transaction protocol had hardly changed for decades. They are not legacy code because the requirements and functionality stayed stable.

The real cause of legacy code is usually changing product requirements. When new requirements appear, developers must revisit and modify the old code. This exposes problems: unfamiliarity with the code, fear of altering design, risk of affecting other parts, and unclear original logic.

Each subsequent change becomes harder, and the code gradually fails to accommodate new needs because it was originally designed for a different problem set.

Thus, legacy code is not defined by age or language but by the mismatch between unchanged code and evolving requirements. A ten‑year‑old codebase can still be good if its requirements remain constant, whereas a two‑year‑old codebase that has undergone ten requirement changes may already be legacy.

When judging whether code is legacy, don't first look at its language, framework, or age. First assess whether the problem it solves has changed. Legacy code often emerges incrementally as business needs evolve, not because the original developers made mistakes or could have predicted future requirements.