Every few months a new framework, tool or methodology promises to change how we build software. Some of them do. All of them cost something that never appears on the comparison page, and the cost is the rate of change itself.
Take a normal web application. A frontend framework, a state library, an API layer, a database, a deployment platform. Say each one changes in a breaking way every two years. Five migrations every two years would be the good case. A change in one layer forces changes in the layers next to it, so there’s a migration in progress somewhere at all times. A team that’s always migrating ships less than it thinks.
I’ve paid it on a side project. One JavaScript framework, one major version, and the migration took months.
The frameworks that ask the most of you are the young ones. AngularJS, the first Angular, ended support in January 2022. The Angular that replaced it was a different framework, and the way out was a migration guide, not an upgrade command. React changed how you write a component twice, from classes to hooks in 2019, then to server components. Backbone is still on npm, and almost nobody starts a project on it. None of them is a bad tool. Each has a pace, and you signed up for it.
The other side of the ledger is real. Once you’re on a technology, refusing to move with it costs more than moving. Each skipped update makes the next one bigger, and a week of upgrades put off for two years becomes a rewrite. You’ll pay for change either way. The only choice is how much of it you buy.
The Lindy effect is the way to buy less. For things that don’t wear out, ideas and technologies among them, the longer something has been around, the longer it’s likely to stay. Old technology is a prediction about the future, and it’s usually right.
SQL databases have outlived the alternatives that promised to replace them, and PostgreSQL keeps getting picked over the latest document store because its failure modes are known. Server-rendered HTML has outlived most of the single-page frameworks built to escape it, and the teams that built the big SPAs are the ones rewriting them every few years. Old and boring also tends to mean long-term support, documented failure modes, and upgrades you can put on a calendar.
Before you adopt something new, three questions do most of the work. How fast does it change, and can you keep up with it? Is there a Lindy alternative that solves the same problem more slowly? And how will this choice look in five years, when it’s the oldest thing in your stack?
Your users don’t care how new your stack is. They care that it works on Tuesday, and old technology has a long record of working on Tuesday.