We Keep Declaring Technologies Dead, But They Keep Running

The Pattern of Premature Eulogies

There is a recurring joke in developer communities: COBOL was supposed to die in the 1990s. Then in the 2000s. Then in the 2010s. It is now 2026, and COBOL still processes roughly 95% of ATM transactions and 80% of in-person financial transactions. The language has been declared dead more times than most software projects have had version releases.

This pattern extends far beyond COBOL. The web was going to kill the desktop. Mobile was going to kill the web. Cloud was going to kill on-premises. Each prediction carries the same implicit assumption: that technology transitions are clean, total, and final. That when something new arrives, the old thing ceases to matter.

History suggests this assumption is almost always wrong.

The Roman Precedent

In 476 CE, a general named Odoacer deposed the last Western Roman emperor and shipped the imperial regalia to Constantinople. Most history books mark this as the "fall" of Rome. But consider what actually happened: Odoacer kept the Roman civil service intact. He governed through existing Roman institutions. The Senate continued to meet. The bureaucratic machinery continued to function.

Twenty years later, a Gothic king named Theoderic took over the same apparatus. He was technically a "barbarian" and an Arian Christian, or what amounted to a heretic by the standards of the time. Yet he ruled the Roman state for thirty-three years, longer than the previous nine Western emperors combined. Roads were repaired. Trade continued. The Consulship continued to be appointed. The Senate continued to convene.

The "fall" of Rome was primarily symbolic. The real destruction came decades later, not from barbarian invaders but from the Eastern Roman Empire's attempts to reconquer Italy. Venice was founded because Italy had become so dangerous that living on the water seemed preferable.

The Software Parallel

The tech industry exhibits remarkably similar patterns to this historical arc, though compressed into years rather than decades.

Consider the mainframe. Mainframes were declared dead in the 1990s when client-server computing became the dominant paradigm. By 2000, mainframes were supposedly irrelevant. Yet as of 2024, 71% of Fortune 500 companies still run core business processes on mainframes. IBM's z-series mainframes generate billions in annual revenue. The technology did not die. It simply stopped being discussed in startup blogs and tech press.

Or consider jQuery. jQuery was declared obsolete years ago by front-end developers who moved to React, Vue, and Angular. A 2024 analysis found that jQuery is still used on 77% of the top 10 million websites. It runs on more sites than React, Angular, and Vue combined. The "death" of jQuery was a narrative within a specific community, not a description of reality.

The same pattern applies to PHP. PHP has been the target of developer mockery for over a decade. PHP 8 introduced modern features like JIT compilation, attributes, and union types. WordPress, which runs 43% of the web, is built on PHP. The language did not die. It evolved in relative silence while developers debated frameworks that serve a fraction of the same audience.

Why the Narrative Diverges from Reality

Several forces drive this disconnect between declared obsolescence and actual persistence.

The replacement is always more visible. New technologies attract blog posts, conference talks, and social media discussion. Old technologies that continue to work generate no content because they are not interesting. Nobody writes "COBOL Processes Your ATM Transaction" because it is not novel. The absence of discussion creates the illusion of absence.

Career incentives favor novelty. Developers build reputations and command higher salaries by working with new technologies. There is no career advantage to being the person who maintains legacy systems, even though that work is often more critical and complex. This creates a selection bias where the people who talk about technology are systematically uninterested in what actually runs the world.

Vendor marketing shapes perception. Cloud providers, framework creators, and tool companies have financial incentives to declare older approaches obsolete. If you are selling a migration tool, you need the thing being migrated from to be perceived as problematic. The narrative of obsolescence serves commercial interests.

Confirmation bias filters evidence. When a company successfully migrates from an old technology, it generates a case study and blog posts. When a company attempts migration and fails, or when the migration takes five years longer than planned, there is no equivalent documentation. We see the successes and miss the silent failures.

The Counter-Argument

None of this is to say that technologies never actually die, or that migration is never warranted. There are genuine cases where old systems become security liabilities, where the knowledge to maintain them disappears, or where the cost of running them exceeds the cost of replacement.

The key distinction is between technologies that are truly obsolete and technologies that are merely unfashionable. COBOL is not unfashionable. It is actively maintained, has modern standards, and continues to be taught in some universities. jQuery is not unfashionable. It has a defined place in the ecosystem and continues to serve a specific use case well.

The problem is not that people identify real technical debt or genuine need for modernization. The problem is that the industry lacks a framework for distinguishing between "this is genuinely problematic" and "this is not what people on Twitter are talking about.

The Zombie Technology Spectrum

Technologies do not exist in a binary of alive or dead. They exist on a spectrum of visibility and utility.

At one end are technologies that are both invisible and dead. The Y2K bug was addressed, and the systems it affected were either fixed or replaced. At the other end are technologies that are both visible and alive. React, Kubernetes, and Rust are actively discussed and actively developed.

The interesting middle ground contains technologies that are invisible but alive. Mainframes, COBOL, jQuery, PHP, jQuery, WordPress, and countless internal enterprise tools that run critical business processes. These technologies do not appear in Hacker News discussions, do not get conference keynotes, and do not generate viral blog posts. They simply continue to function.

There is also a category of technologies that are visible but dead. These are technologies that generate discussion primarily as objects of comparison or nostalgia. Nobody builds new projects in Perl, but Perl remains a topic of conversation. The technology has been replaced in practice but persists in discourse.

What This Means for Practitioners

For individual developers, the practical implication is to be skeptical of any narrative that declares a technology universally dead. Before assuming a technology is obsolete, check whether it is actually unused or merely uncool. The distinction matters for career decisions, architectural choices, and technical assessments.

For organizations, the lesson is that migration decisions should be based on concrete costs and risks rather than on industry narratives. If a legacy system is running reliably, serving its purpose, and is maintainable, the fact that it is not discussed in modern conferences is not a reason to replace it. The cost of migration is real; the benefit of being perceived as modern is largely imaginary.

For the industry as a whole, there is value in recognizing that our collective narratives about technology often describe aspiration rather than reality. We talk about what we want the world to look like, not what it actually looks like. The gap between those two things is where most technical decisions go wrong.

The Roman Senate continued to meet for decades after the traditional date of Rome's fall. The bureaucratic machinery persisted through multiple changes of leadership. The infrastructure continued to function. The fall was real, but it was not a single moment. It was a gradual process of decay that took longer to unfold than the romantic narrative of sudden collapse suggests.

Software systems follow similar trajectories. They do not die cleanly. They fade, persist, and transform. The honest assessment of any technology requires looking past the narrative of what should be true to the evidence of what is actually happening.