Lindy Effect
For technologies and ideas, every year they survive increases their expected remaining life.
To an executive
Technologies that have survived for decades are likely to last much longer. Proven choices tend to carry less long-term risk than fashionable new ones.
To an engineer
When choosing between tools, treat track record as evidence. Favour long-lived technologies for foundations and keep newer ones for places where you can afford to replace them.
The idea
The name comes from Lindy's, a New York delicatessen. In 1964 the writer Albert Goldman, in The New Republic, described a folk theory among the comedians who gathered there about how long a television comedian's career would last. Benoit Mandelbrot later gave the idea a mathematical form, and Nassim Nicholas Taleb, in Antifragile (2012), named it the Lindy effect and applied it to non-perishable things such as ideas, books and technologies.
The claim is statistical: for things without a natural lifespan, the longer something has survived, the longer it can be expected to last. A technology that has been around for thirty years is likely to be around for many more. One that appeared last year may be gone next year.
Why it works
Survival is evidence. A technology that has lasted decades has come through changes in hardware, fashion, vendors and competing ideas. Each one it survived was a test.
Age builds an ecosystem. Old technologies have tooling, documentation, skilled people and known failure modes. That ecosystem is itself a reason they keep going.
It is a useful prior when evidence is thin. You cannot know which new tool will last, but age gives a reasonable starting estimate that you can then adjust.
Where it applies
- Foundations for long-lived systems: storage formats, protocols, languages and databases for records that must last a decade or more.
- Vendor selection, where a supplier's age and the age of its technology are part of the risk.
- Archives and regulated records, which may need to outlive many generations of tools.
- Standards choices, where long-established open formats are easier to migrate away from later.
How to apply
- Match technology age to system lifespan. The longer the system must live, the more weight to give proven foundations such as SQL, HTTP and plain file formats.
- Spend novelty where it pays: on the parts that differentiate you, not the parts that must simply last.
- Isolate younger choices behind interfaces and open formats, so they can be replaced if they fade.
- Use Lindy as a prior, not a verdict, and update it with evidence about the specific technology.
Example scenario
A team chose a new, fashionable database for a ten-year regulatory archive because it was fast to develop against. Three years later the product was discontinued, and the team faced an unplanned migration of years of records under audit.
For the replacement, the architect separated the two concerns. Records went into long-established technologies: a relational database and object storage, with documents in open formats. The newer search tool the team liked was kept, but only as an index that could be rebuilt from the records if it ever had to be swapped out.
Questions to ask
- How long has this technology existed, and how widely is it used?
- How long does our system need to live?
- Can we isolate the younger choices behind stable interfaces?
When not to use it
- Short-lived or experimental systems, where the newest tool may simply be the most productive.
- Genuine step changes, where a new technology offers something the old ones cannot, and waiting for it to age would cost more than the risk.
How it misleads you
Lindy can become an excuse to dismiss all new technology. It is a prior, not a verdict; some new technologies are genuine step changes, and every old one was new once. It also says nothing about whether an old technology still fits your needs: survival is not the same as suitability.
Further reading
- The Lindy EffectToby Ord · Paper · 2023(opens in a new tab)
- Antifragile: Things That Gain from DisorderNassim Nicholas Taleb · Book · 2012(opens in a new tab)
Last reviewed · Suggest an improvement