A brief defense of very old tools

Some of the software I use most every day is a decade older than the phone I am reading it on. This is not nostalgia. It is, quietly, a competitive advantage.

Every year around this time I do a small audit of the tools I actually use for the bulk of my work. And every year I notice the same thing: a suspicious amount of my working day is spent in software that is older than my nephew, and I could not honestly recommend most of the modern replacements over it.

This is not nostalgia. I am not going to write "they don't make them like they used to." Some old software is genuinely worse than the modern alternative and I have quietly retired plenty of it. But there is a specific reason a specific kind of old tool tends to outlast its ostensibly-better replacements, and I want to write it down.

What "old" is doing

A piece of software that has been in daily use for fifteen years has, by that fact alone, been through a decade of decisions about what not to add. Every feature not added is a feature not maintained, not documented, not exposed to a security bug, not confusing to a new user. Every feature it does have is one that survived — a decade of chances to be quietly deleted, and it stayed. This is a very strong signal.

Modern software, by comparison, is usually in the middle of a growth story. It is trying to become the "canonical" version of its category, or trying to justify a valuation, or trying to expand into an adjacent workflow. Its incentives push it toward more features, not fewer. Even when the founders would love to keep it small, the market pushes back.

An old tool is stable because it has already lost the arguments it was going to lose.

Three examples from my desk

A text editor that has not changed its fundamental interface since roughly 2004. It runs on every machine I own. Its plugin ecosystem is mature to the point of boredom. I know exactly what it will do when I press a key, and I have known for so long that the muscle memory feels physiological. If it disappeared tomorrow, I would be actively slower for months.

A terminal emulator from a similarly ancient era. Fast. Small. Configurable in a plain text file. Its author has resisted, over years, roughly a dozen proposals to add features I would have loved for a week and hated for a decade. I have used three "modern" replacements in the same period. All of them are still on my machine somewhere. None of them is on my dock.

A password manager that predates the mobile web. Not the polished new one. The other one. Local database. Text export. No cloud sync unless I bring my own. Ugly interface. Absolutely rock-solid, in a way that its ambition-heavier competitors have not, in my experience, matched. When it fails, it fails obviously. When it works, it disappears.

The one thing you give up

You give up onboarding. Old tools are almost never friendly to the newcomer. They assume you will spend a few weekends learning them. If the tool is important enough for you to use daily, those weekends are the best time investment in your whole toolchain. If it is not, do not use it — pick the friendlier modern option and get on with your life.

This is the one criterion I use to decide whether an old tool is worth the reputation cost of adopting it, socially, in a modern workplace. If I will use it for four hours a day for the next five years, its ugliness is a rounding error. If I will use it once a quarter, its ugliness is the entire experience, and I should be nicer to myself.

What this is not

This is not a claim that old is always better. Version control systems from 2001 are a nightmare and I would not go back for any price. Text editors from 1976 are a specific taste. Cryptography from any era before the current one is dangerous. There is genuine progress in software, and dismissing it wholesale is the mark of someone who confuses their preferences with a virtue.

What this is: a small argument that when you find a tool that has been quietly good for a very long time, you should treat that longevity as a feature, not a defect. And when you evaluate a shiny alternative, you should ask, honestly, whether it has earned the right to replace something that has been getting slowly better for a decade.