Still Running: A Field Guide to the Developers Keeping Dead Software Alive

Every few months, the tech press runs another story about the developer who just shipped a framework that will revolutionize the way we build applications. There are photos. There is a demo. There is a Hacker News thread where everyone argues about whether it's actually revolutionary or just a React wrapper with better marketing.

Nobody runs a story about Marcus.

Marcus — not his real name, because his employer would prefer that the general public not think too hard about the vintage of the systems processing their transactions — has spent the last fourteen years maintaining a portfolio management system built in the early 1990s. The system runs on hardware that hasn't been manufactured since the Clinton administration. The documentation is partly in a language Marcus does not speak. The original developers are, in his words, "retired, dead, or both."

The system processes somewhere north of $2 billion in transactions per week.

"People ask me what I do," Marcus told me over a call that he took from what sounded like a server room. "I tell them I keep the lights on. They think I mean that metaphorically."

He does not mean it metaphorically.

The Invisible Infrastructure

The romance of software development, as sold by every bootcamp and startup blog in America, is about building new things. You have an idea, you write the code, you ship the product, you iterate, you scale, you exit. The mythology is entirely forward-facing.

But the actual topology of the software that runs the United States — that processes payroll, routes air traffic, manages hospital records, clears financial transactions — looks a lot less like a startup pitch deck and a lot more like a geological cross-section. Layer upon layer of systems, each one built on top of whatever existed before it, none of it ever fully replaced because replacement is terrifying and expensive and the people who understood the original system have been gone for decades.

The Federal Reserve still runs COBOL. So do most major banks. So does a significant portion of the Social Security Administration's infrastructure. COBOL, for the uninitiated, was developed in 1959. It is older than the integrated circuit. It is, by most measures, very much not supposed to still be running critical American financial infrastructure in the 2020s.

It is very much still running critical American infrastructure in the 2020s.

And somewhere, there are developers whose entire professional existence is organized around keeping it running.

The Dignity of Maintenance

There's a philosophical dimension to this work that doesn't get discussed much in an industry obsessed with disruption. To maintain something is to make a sustained argument that it still has value — that the cost of keeping it alive is worth paying, that the people depending on it deserve continuity.

Developers who do this work describe a peculiar professional identity. They are, in a very real sense, the last people alive who understand how some of these systems work. That knowledge is both a source of job security and a kind of existential weight.

"You become the documentation," one legacy systems developer told me. She's spent a decade maintaining a claims processing system for a regional insurance company. "There are things I know about how this system behaves that don't exist anywhere else. If I got hit by a bus, some of this would just be gone."

She paused. "That's a weird feeling."

It is a weird feeling. It's also, she noted, a feeling that the tech industry's relentless focus on novelty has no real vocabulary for. There are no conference talks about the craft of keeping old things running. There are no VC pitches for maintenance. The word "legacy" in tech is almost always pejorative — a way of saying "this should have been replaced by now."

But legacy systems are also, often, systems that have survived precisely because they work. They've been battle-tested in ways that new systems haven't. They've had their edges knocked off by decades of real-world use. They are, in an industry that moves fast and breaks things, a monument to not breaking things.

The Zombie Feature Problem

Beyond the infrastructure layer, there's a subtler category of maintenance work: the zombie feature. This is the button in the app that 0.3% of users still click. The export format that one enterprise client requires for a workflow that predates the current IT team. The API endpoint that was supposed to be deprecated in 2019 but is still receiving 40,000 calls a day from integrations no one can fully map.

Every sufficiently old codebase has them. And every sufficiently old codebase has, somewhere in its git history, a developer who quietly kept them alive because the cost of removing them — the testing, the migration support, the support tickets from confused users — was always slightly higher than the cost of just leaving them alone.

This is maintenance as a form of passive courage. It's the decision, made over and over again, to absorb the complexity rather than pass it downstream.

What the Industry Owes These People

The honest answer is: more than it's paying.

Legacy systems work is chronically undervalued because it's invisible when it's going well. The only time anyone pays attention to the COBOL developer is when something breaks — which, given the quality of the maintenance work being done, happens less often than it should, given the age of these systems.

There's also a knowledge transfer crisis building in slow motion. The developers who built these systems are retiring. The developers who have spent their careers maintaining them are aging out too. And the new generation of developers — trained on React and Python and cloud infrastructure — often have no exposure to the systems underneath the systems.

"I try to document everything," Marcus told me before we ended our call. The server room sounds had gotten louder. "But some of it is just intuition at this point. You learn how the system breathes."

He laughed, a little tiredly.

"That sounds insane, right? The system breathes. But you spend long enough with something, you just know when something's off."

It doesn't sound insane. It sounds like the most human relationship in tech — a developer and a system, keeping each other running, long past the point where anyone expected either of them to still be here.