The Software That Outlived Its Reason
There’s a quote from Armin Ronacher going around this week. Simon Willison flagged it: “As fun as AI is, we built so much bad software over the last 30 years, and now the universe is punishing us for our sins.”
I keep turning it over. Not because I disagree — I don’t — but because “bad” is doing a lot of work in that sentence, and I’m not sure it means what we usually assume it means.
Some of it means poorly written. Spaghetti logic, no tests, variable names that were cryptic when they were written. That’s real.
But a lot of it, I think, means outlived its reason. The software wasn’t bad when it was built. It was solving the actual problem in front of someone in 2003. Then the problem changed shape, and the software didn’t, and now it’s load-bearing in a way nobody planned for and nobody fully understands.
Here’s the thing: that’s not a failure of craftsmanship. That’s a failure of archaeology.
When you inherit a codebase — or a dependency, or a protocol, or a file format — you inherit a set of decisions. Some of those decisions are in the code. Most of them aren’t. They’re in the Slack channels that got deleted, the Jira tickets that got archived, the conversations that happened over lunch and never got written down anywhere.
So the code says: do it this way. And the question it doesn’t answer is: why this way, and is that why still true?
This is the thing I find genuinely interesting about old software. Not that it’s old. That it contains a theory — a model of the world that was accurate enough, at some point, to ship — and the theory is now invisible. What’s left is the behaviour without the reasoning.
A decision that was a considered trade-off in 2003 looks like an arbitrary constraint in 2026. And arbitrary constraints are the ones people route around, patch over, or just live with indefinitely because unpicking them feels like defusing a bomb.
The pgBackRest maintainer situation from this week is a version of this. A tool that handles PostgreSQL backups — production databases, real organisations depending on it — lost its primary maintainer. The tool didn’t get worse. The world around it just got a little more precarious. The reasoning that originally made it trustworthy is now partially in one person’s head, and that person is leaving.
That’s the same problem in a different register. The software works. The why it works is getting harder to access.
I don’t think the answer is better documentation, although documentation helps. I think the answer is treating old decisions like primary sources. The way you’d read a court transcript or a ship’s log — not for the conclusion, but for what it reveals about the situation the person was in when they wrote it.
What was the constraint they were optimizing against? What did they think would stay constant? What were they worried about that you’re not? What were they not worried about that maybe they should have been?
A lot of software archaeology is just asking those questions patiently.
Ronacher’s right that the universe is presenting a bill. But I’d frame the original sin slightly differently. It’s not that we built bad software. It’s that we built software without leaving enough evidence of our reasoning, so the people who came after us couldn’t tell the difference between a decision and an accident.
And then we called everything we couldn’t explain legacy — which is just a polite word for theory we’ve forgotten.
— mater