The Legacy System Only One Person Understands

TL;DR: Every org has one: the system nobody wants to touch, kept alive by the one person who isn't afraid of it. Nobody planned that - ticket routing built it, one rational decision at a time, and it costs you daily long before anyone resigns. The fix isn't a rewrite and it isn't a wiki sprint: rotate real tickets through a second person with the expert reviewing, write runbooks for the operational folklore, and read your git history so you find the next single-interpreter system while the knowledge is still cheap to move.

There's a service in your stack right now that everyone routes around. It predates half the team. Its tests are a rumor. And there is exactly one person - call her Dana - who can touch it without holding her breath. When a ticket lands on it, the ticket goes to Dana. When it pages at 2am, the page finds Dana. When Dana takes two weeks off, the system enters a gentle, unspoken freeze.

That's not a Dana problem. That's a system one resignation away from having zero living interpreters: a bus factor of 1 wrapped around code that's old, critical, and allergic to guesswork. This article is about how that happens, what it costs while nothing is technically wrong, and how to spread the knowledge before the deadline someone else picks for you.

How one person becomes the interpreter

Nobody assigns a legacy system to a single human on purpose. Routing does it.

The first time something breaks, the ticket goes to whoever is least afraid, often whoever touched it last or whoever inherited it when the original author left. That fix makes them slightly more expert. The next ticket routes to them because they're now the fastest safe choice, and every teammate who didn't take the ticket learns a little less. Repeat for three years and the gap is a canyon: one person holds the whole mental model, everyone else holds a healthy fear, and both groups are behaving perfectly rationally.

This is the same compounding mechanism that concentrates tribal knowledge anywhere. Legacy systems just run it at maximum speed, because fear makes the routing stickier. Roast the system, not Dana: she didn't hoard anything. The org fed her every ticket and called it efficiency.

What it costs before anyone resigns

The obvious risk is the departure, and it's real. Avelino et al. (2016) measured truck factors across 133 popular GitHub systems and found 34% sitting at exactly 1, and about 65% at 2 or lower. Those are healthy, actively developed projects. A decade-old internal system with one interpreter is the textbook case, not the outlier.

But the meter runs daily, even if nobody ever quits:

• The interruption tax. Every question about the system is a context switch for one person. In the 2024 Stack Overflow Developer Survey, 61% of developers reported spending more than 30 minutes a day just searching for answers. When the only search index for a system is a human, that cost lands on her focus time.
• The single-lane bridge. Every change waits for one reviewer. Estimates on that system aren't estimates of the work; they're estimates of Dana's queue.
• The risky outsider fix. When someone else is forced to touch it, the odds are worse than usual: Bird et al. (2011) found, studying Windows Vista and Windows 7, that components with more low-expertise contributors had more pre-release faults and post-release failures. A legacy system with one expert converts every substitute into exactly that low-expertise contributor.
• The invisible freeze. Vacations, parental leave, a bad flu week - each one quietly pauses a slice of your roadmap. You've just never written the pause down.

This is key-person risk in its purest form: the person is fine, the system is the problem, and the bill arrives whether or not the bus ever shows up.

How to see it coming

You don't need a survey; the evidence is already in version control. Areas where one name dominates both authorship and review over the last year are areas where the knowledge has had no reason to exist in a second head. It's the same signal used in calculating bus factor, and a story your repo tells in detail if you read the git history properly. Cross-reference with the human layer: which systems generate questions that always route to the same person? Where both signals agree and the system sits in a critical path (money, deploys, the thing customers actually hit), you've found your interpreter dependency.

Do this before the resignation and it's a planning exercise. Do it after and it's the two-week scramble.

Spreading the knowledge without a rewrite

The reflex answer is "rewrite it," which, run by the same single expert, produces a newer system with the same single expert, and run without her rediscovers every buried decision at production speed. Spread first; decide about rewrites afterward, with more than one informed opinion in the room.

1. Rotate real tickets, expert reviews. Route the next tickets on the system to a designated second, with Dana as reviewer, not author. Real work surfaces the real landmines - the config nobody mentions, the vendor API that lies. It's slower for a month. That slowness is the price of the insurance, paid while it's cheap.
2. Runbooks for the operational folklore. The deploy quirks, the recovery steps, which alerts are noise: short, versioned next to the code, and verified by having the second person run one while the expert watches. Prose that hasn't been executed is documentation debt in advance.
3. Write down the whys as they surface. Every "oh, that's because…" in review is a decision record trying to happen. Ten minutes at the moment of explanation beats an archaeology project in three years.
4. Name a successor, formally. An explicit second owner for every critical legacy system, with warm-up time budgeted rather than wished for, is the heart of succession planning for engineers. If the departure does land anyway, the difference between a plan and a panic is the offboarding checklist you wrote in peacetime.

The door

The legacy system with one interpreter is the most predictable crisis in software: you can see it in the git history months or years before it happens, and every month you wait, the knowledge gets more expensive to move. A continuously computed ownership map - which areas have one living interpreter, how critical they are, trending which way - is exactly what Busfactor's knowledge view renders from the history you already have. Dana deserves a vacation without a pager. Give the system a second head before it demands one.