Some of the most important software in Houston is older than the people maintaining it. In the control rooms of the energy industry — the refineries, the pipelines, the trading desks that move a meaningful share of the world’s fuel — a great deal of the code quietly doing the work was written decades ago, in languages many programmers today have never touched. It’s easy to read that as a problem. It’s at least as much a lesson.
The instinct in software is to treat age as decay. New is better; old is “legacy,” a word that in much of the industry means little more than embarrassing and overdue for replacement. Sometimes that’s fair — old systems can be brittle, hard to change, understood by fewer and fewer people each year.
But notice what the age also tells you. Software that has run critical operations for thirty or forty years is software that works — that has been tested by reality far longer than most companies have existed, through conditions no designer fully anticipated, and is still trusted with consequences measured in lives and millions of dollars. That is not nothing. Durability is its own kind of proof.
The reason so much of it persists isn’t only inertia. Replacing a system that works is genuinely dangerous. Every rewrite risks reintroducing problems the old code, over decades, quietly learned to handle. The accumulated knowledge of all the rare cases it survived is written into it, often nowhere else. Throw it away and you throw that away too.
There’s a tension here the whole field lives inside. Software does have to change — to stay secure, to meet new needs, to remain understandable to the people who keep it running. But change is not the same as novelty, and not all aging is decay. A tool still doing its job after forty years has achieved something most software never will: it lasted.
The energy capital runs on old code for the same reason a city keeps a bridge that still carries traffic. The question worth asking of any system is not how old it is, but whether it still does the thing it was built to do — and whether the new thing you’d replace it with can promise to last half as long.
It’s a quality we build for deliberately — software meant to keep working, not to be replaced on a schedule. More about how we work →