The Word You Use When You Won't Be There

In English, “legacy” is what someone leaves you when they die.

The watch your grandfather wound every morning for forty years. The house your mother kept. The manuscript a friend finished the week before the diagnosis. The word means inheritance. It carries the weight of someone’s life and lays it in your hands. We do not use the word lightly. We use it at funerals. We use it in wills. We use it when something matters enough that the leaving of it is the point.

In engineering, “legacy” means what we throw away.

The same word. Two opposite meanings. One language. Has anyone noticed?

When did the flip happen? When did the discipline that prides itself on building things invent a word that means what we kill because we no longer have permission to ask the author?

Hold that question. We’ll come back to it.

Is the word ever right?

Somewhere right now, an engineer is staring at a library written in PHP thirteen years ago. It has not been maintained since the iPad was a new product category. The author left the project eight company acquisitions ago. The maintainer’s email bounces. The repository has been archived. The dependency tree is a graveyard of versions the package manager refuses to install. The code does what it does, and what it does is exactly what the business needs, and there is no path forward that begins with the words “let’s preserve this.”

Is that legacy?

Probably. Yes. Sometimes the word fits. Sometimes the author is gone, the maintenance has stopped, and the rewrite is the honest option. The word exists because the situation exists. Engineering hands down dependencies the way families hand down houses, and sometimes the house is uninhabitable.

So the question is not “is the word ever right?” The question is the one that lands the moment you stop reading and start counting.

What percentage of the time you used the word, this year, were you describing that situation?

What were you describing the rest of the time?

You walked into a project you did not build. You opened the codebase. Within six weeks, you found yourself using the word. The architect who built it left two years ago. Maybe he’s still in the company, on another team, three Slack channels away. Maybe he’d answer your DM in an afternoon. Did you ask?

Or did you read the code, feel the friction, recognize that the abstractions are not the ones you would have chosen, and reach for the easiest word in the language for what to do about that?

There are two statements hiding behind the same word:

This is unmaintained and the original author is gone.

I would not have built it this way.

They grant the same permission: to rewrite, to dismiss, to begin again. They feel the same on your tongue. They produce the same nodding around the table. Which one is a finding? Which one is a preference wearing the costume of a finding?

Which one were you using?

The verdict that never has to be defended

Notice what happens once the word lands.

You begin the rewrite. The rewrite ships. The new system is better, faster, easier to reason about. You were right. The code was legacy.

Or: you begin the rewrite. The rewrite collapses. The new system never reaches feature parity. The team ages out. The replacement is, eventually, replaced. You were also right. The legacy was even worse than we thought. It had infected our estimates. Of course it took longer.

Or: you begin the rewrite. The company runs out of money. The rewrite is half-finished. The “legacy” system is the one that’s still running when the office lights go out. The engineers who called it legacy don’t outlast the legacy.

In every scenario, the word survives. The verdict cannot lose, because the verdict cannot be reviewed. Whoever pronounced it has already moved on. There is no defendant in court. There is no court. The word was the trial, the verdict, and the execution.

What other word in your professional vocabulary works like this?

Who, exactly, says it?

Try this exercise. Think of every conversation in the last six months where the word “legacy” appeared. Who used it?

The consultant who’d been there six weeks. The new tech lead. The recently-acquired team describing the system they were now expected to maintain. The vendor pitching a replacement. The architect just promoted into the role. The senior who’d been there a year and was now interviewing elsewhere.

Now try to remember a conversation in which the word was used by someone who had been at the project for five years and intended to stay.

Hard, isn’t it?

The word is the vocabulary of arrival. It is what you say when you have just walked in. The maintainer does not call his own work legacy. The maintainer has things he would change, things he regrets, things he’s been meaning to fix. He has a relationship with the code. He does not have a verdict on it. He is still there.

The dismisser, on the other hand, has not yet stayed long enough to know what he would regret. He has only stayed long enough to know that he would not have built it this way. So he reaches for the word that converts that preference into a finding.

By the time anyone could check whether he was right, he is on the next project, doing it again.

The thing nobody says

Look at your curriculum vitae. How many years did you spend at your longest engagement?

How many years has it been since you stayed somewhere long enough to maintain something you yourself built, past the point where it started to feel old to you? Not abandon. Maintain. Past the point where you started having opinions about the code you wrote three years ago, the architectures you committed to under deadline, the decisions that aged in ways you did not predict.

Have you ever, in your career, been in the room when someone called your own work legacy, where you could answer back?

The word requires the dismisser and the dismissed to never share a room. Why is the word unfalsifiable? Not because the verdict is hard to test. Because the conditions of testing have been arranged so the original author is never available. Sometimes by death. Sometimes by retirement. Mostly by departure. By the ordinary churn of an industry that rewards leaving over staying.

We made a word for the kind of work that gets done by people who are no longer present to defend it. And then we use that word on people who are still alive, still employed, still reachable. We use it on code that was committed last month, by someone in the next building, whose Slack handle we have not opened.

What does the original word mean again?

A watch. A house. A manuscript. The thing your grandfather wound, your mother kept, your friend finished.

The English word has not lost its meaning. We are the ones who took it and used it on people we did not bother to call.

We did not invent a new word for “code I do not want to maintain.” We appropriated the word for what someone left when they died, and applied it to what someone left when they took another job, or moved teams, or simply went home for the weekend and did not pick up their laptop on Saturday because we had not asked them anything.

If a stranger walked into your home, looked at the watch on the shelf, and said “this is legacy,” you would be insulted on your grandfather’s behalf. You would correct them. You would say no, that is an inheritance, that is a gift, that is something somebody loved enough to leave me. The watch is here. You can hold it. You can read the inscription on the back.

Where does this leave you?

How long have you been at your current project?

If you left tomorrow, what would the engineer who replaces you on day one call your code? Has anyone called your code legacy yet, in your career? Were you in the room when they said it? Could you answer back?

How many times this year did you use the word? How many of those times were you describing thirteen years of unmaintained PHP, with the original author gone, the email bouncing, the maintainer absent? And how many of those times were you describing something you simply would not have built that way, written by someone whose phone number was in the directory, who you did not bother to call?

Were you right? Probably, sometimes. 100% of the time?

How would you know the difference?