Technology is supposed to age quickly. Phones become obsolete, startups disappear, frameworks fall out of fashion and yesterday's revolutionary software becomes tomorrow's migration problem. Yet beneath this churn lies a strangely durable layer of old technology.
FORTRAN dates to the 1950s. COBOL appeared in 1959. The C programming language emerged in the early 1970s. Unix was born around the same period. SQL, TCP/IP and decades-old file formats remain embedded throughout modern computing. Much of the newest technology in the world still rests on ideas and software interfaces created before many of today's programmers were born.
One way to think about this persistence is the Lindy Effect: for certain non-perishable things, surviving for a long time can be evidence that they are likely to survive longer still.
It sounds almost like the opposite of aging. A 90-year-old person generally has fewer expected years remaining than a 20-year-old. But a programming language that has survived 50 years of competitors, hardware revolutions and changing fashions may be a safer bet for continued existence than a framework launched six months ago.
The distinction is seductive. It is also easy to misuse. Lindy is not a magical law saying that old technology is always better. It is a way of reasoning about survival.
The idea began with comedians, not computers
The name has nothing to do with engineering. It traces back to Lindy's, a famous New York delicatessen associated with Broadway and show-business culture.
In 1964, writer Albert Goldman described “Lindy's Law” in The New Republic, referring to folklore among comedians and media observers about how long performers or television careers might last. The idea was subsequently transformed by mathematician Benoît Mandelbrot, who discussed a version of Lindy in his 1982 book The Fractal Geometry of Nature.
Nassim Nicholas Taleb later popularized a broader version, especially in Antifragile. His formulation focuses on non-perishable things — ideas, books and technologies rather than organisms — and argues that additional survival can imply additional expected longevity. Taleb summarized the technological intuition in a 2012 essay for Wired: for non-perishable technology, every additional period of survival may imply a longer future life expectancy. citeturn0search1
The principle feels paradoxical only because we instinctively import biological aging into things that do not have biological lifespans.
What Lindy actually predicts
The popular version is often stated like this: if something non-perishable has already lasted for 20 years, expect roughly another 20; if it has lasted for 100, expect another 100.
That is a useful intuition, not a universal countdown clock.
Mathematically, Lindy-like behavior can emerge from heavy-tailed lifetime distributions such as the Pareto distribution. In one simple model, conditional expected remaining lifetime becomes proportional to the age already observed. citeturn0search3
More recent work has also shown that the phenomenon is subtler than the slogan suggests. Philosopher Toby Ord's analysis of the mathematics behind the Lindy Effect argues that Lindy behavior can arise under multiple mechanisms and does not require every individual object to become intrinsically safer with age. A population containing things with different underlying failure rates can produce the same pattern because fragile members disappear early, leaving unusually durable survivors. citeturn0academia26
This distinction matters enormously for technology.
A 50-year-old programming language does not physically grow stronger every birthday. Instead, reaching 50 tells us something about the language, the ecosystem around it and the environments that have repeatedly failed to eliminate it.
Time acts like a brutal technology filter
Imagine two software tools. One was released last month and has attracted enormous attention. The other has been used continuously for 30 years.
We know relatively little about the first tool's long-term survivability. It may have serious design flaws. Its company may fail. Its maintainers may lose interest. A competitor may replace it. The underlying platform may change. Its community may never become large enough to sustain it.
The 30-year-old technology has already passed through many of those filters.
It has survived operating-system changes, hardware transitions, security discoveries, corporate reorganizations, competing products and generations of engineers who tried newer alternatives. Its survival is information.
This does not prove that it is technically superior. Survival can result from excellence, but it can also result from compatibility, inertia, regulation, network effects or the terrifying cost of replacement.
In software, those forces are exceptionally powerful.
Why old software can become harder to kill
Software is unusual because successful technologies accumulate dependencies.
A programming language attracts libraries. Libraries attract applications. Applications create jobs. Jobs create training materials. Universities teach the language. Companies hire specialists. Tools emerge for testing, profiling, debugging and deployment. Standards are written. Data formats become established. Other systems learn to communicate with it.
Each layer makes replacement more expensive.
A new language does not merely need to be better than the old language. To replace a deeply entrenched technology, it may need to compensate for decades of libraries, documentation, institutional expertise and tested behavior.
This helps explain why legacy software can survive even when almost everyone agrees that a greenfield system would be designed differently. A long-running banking application may contain decades of encoded business rules and obscure exceptions. Rewriting the syntax is easy compared with rediscovering every assumption hidden inside the old system.
Age creates an installed base, and the installed base creates inertia.
COBOL is the obvious Lindy mascot
Few technologies illustrate the effect better than COBOL.
Designed around 1959 for business data processing, COBOL has been declared obsolete for decades. Yet old COBOL systems continue to operate in governments, banks, insurance companies and large enterprises.
Its persistence is sometimes treated as absurd, as though organizations simply forgot to upgrade. The more interesting explanation is that the software performs important work inside systems where failure is extremely expensive.
Once a program has correctly processed transactions for decades, replacing it creates a peculiar risk asymmetry. The old code may be awkward, but its behavior is known. A replacement may be elegant, modern and extensively tested, yet still misunderstand one business rule written into the original system in 1987.
Longevity therefore becomes self-reinforcing. The longer critical software operates, the more evidence organizations accumulate that it works — and the more surrounding systems grow dependent on its exact behavior.
C survived because the world grew around it
The C programming language offers a different kind of persistence.
Created at Bell Labs in the early 1970s and closely connected with the development of Unix, C became foundational to systems programming. Operating systems, compilers, embedded devices, databases and countless libraries were written in it.
Modern languages can offer stronger memory safety, richer abstractions and more convenient tooling. Yet replacing C everywhere would mean replacing not just a language but an enormous body of infrastructure and interfaces.
In fact, new technologies often extend the life of old ones. A modern language may call a mature C library through a foreign-function interface. A Python package may use high-performance native code underneath. A new operating system may continue implementing decades-old networking standards because every other machine expects them.
The future does not always destroy the past. Often it adds another layer on top.
Protocols may be even more Lindy than programs
The Lindy intuition becomes especially strong with network protocols and standards because compatibility creates network effects.
A private application can be rewritten by one organization. A protocol used by millions of independent systems is much harder to replace.
TCP/IP became the foundation of Internet communication because enormous numbers of machines learned to speak it. HTTP became fundamental to the Web. Once a protocol reaches that scale, a technically superior replacement faces a coordination problem: its advantage matters only if enough other systems adopt it too.
This is why successful standards often evolve through extensions, revisions and compatibility layers rather than disappearing overnight. Old protocols can acquire new security mechanisms, performance improvements or transport options while preserving enough continuity for existing systems to keep functioning.
The Internet is therefore simultaneously one of the fastest-changing technological environments ever created and a museum of extraordinarily durable abstractions.
But Lindy does not mean “old equals good”
This is the most important limitation.
Some old technologies survive because replacing them is painful, not because they are ideal. Legacy systems can accumulate severe maintenance costs. Old protocols can contain security assumptions that no longer make sense. A format can persist because everyone is trapped by compatibility.
Lindy is a survival heuristic, not a quality score.
Nor does age make a technology immune to sudden displacement. Film photography survived for generations before digital imaging transformed the mass market. Fax machines remained important for decades before electronic workflows eroded many of their uses. A technology can look durable until a change in cost, regulation, hardware or user behavior removes the environment that sustained it.
Survivorship bias also matters. We notice C, Unix and COBOL precisely because they survived. Computing history is littered with forgotten languages, operating systems and standards that were once considered important.
The correct inference is therefore modest: conditional on a technology having survived for a surprisingly long time, we should update our estimate of its durability upward. We should not assume immortality.
The practical lesson: boring technology can be valuable
Software teams constantly face a choice between established tools and fashionable new ones. Lindy offers a useful question: how much evidence of survival does each option have?
A database technology used in production for decades has encountered workloads, failures and edge cases that a brand-new database cannot yet have experienced. A mature programming language has accumulated documentation, libraries and debugging knowledge. A long-established protocol has demonstrated interoperability across generations of hardware.
That evidence has value, particularly for systems expected to survive many years.
But the conclusion should not be to reject innovation. New technology is necessary precisely because old systems have limitations. The better lesson is to distinguish between novelty that solves a genuine problem and novelty whose main advantage is being new.
A useful architecture can even combine both: stable, boring foundations underneath rapidly changing layers above them.
The oldest layer may still be there when the newest is forgotten
The technology industry encourages a peculiar perception of time. A three-year-old framework can feel dated. A five-year-old phone can seem ancient. Yet underneath the latest applications sit ideas and interfaces whose lifetimes are measured in decades.
The Lindy Effect helps explain why.
Survival selects. Compatibility accumulates. Communities preserve knowledge. Dependencies deepen. Every year an established technology remains useful creates another year of evidence that replacing it is harder — or less necessary — than enthusiasts once expected.
That is why predicting technology by looking only at what is newest can be misleading. Sometimes the strongest clue about what people will still be using twenty years from now is what they were already using twenty years ago.
The future of computing will undoubtedly contain technologies that do not yet exist. But it will also contain ghosts of the past: old languages calling older libraries, modern applications speaking venerable protocols, and new machines preserving compatibility with decisions made generations earlier.
In software, age is not always decay. Sometimes it is evidence.