A Companion to The Cost of Better
The Graveyard of Sure Things
Every technology that promised to be the destination turned out, soon enough, to be the detour. The trouble? You cannot tell which is which, while you are standing on it.
There is a particular sentence I have heard in elevated rooms and engineering reviews across four decades, on four continents, in firms that no longer exist and firms that now run the world. It is always delivered with great confidence, and it goes something like this….
This is the one. This is where the industry is going. We need to be on it.
This has been said about a great many things. It was said about the relational database, and then about the technology that was going to replace the relational database, and then about the technology that replaced that.
It was said about a dozen programming languages and twice as many frameworks. It is being said, right now, in more or less every technology meeting on Earth, about artificial intelligence.
And the remarkable thing — the thing that ought to make us all a little more humble than we are — is how often the sentence has been wrong, and how completely we forget that it was wrong the moment the next candidate arrives.
I have written, in a separate series, about the hidden costs of technological progress — the bill that does not disappear but merely moves, into the future, into the physical world, into the questions we stop asking. This essay is a companion to that argument, and it concerns a particular and very expensive species of that cost: the cost of mistaking a detour for a destination, paid by the people who bet their roadmaps, their careers, and their balance sheets on a technology that turned out to be a phase.
The Shape of the Mistake
Let me show you the pattern before I argue it, because once you have seen the shape you cannot unsee it. What follows is “sure things” laid on a single timeline — the technologies I watched arrive, each announced as the place the industry was finally heading. I have marked the two oldest differently, because they belong to a different category. The mainframe was the ground everything stood on, and BASIC, for many of us, was simply where we began. The rest were destinations. That’s what we were told.

Each technology in the lower part of the chart arrived announced as the destination — the place the whole industry was finally heading, the thing you had to adopt or be left behind. And each, in its turn, was revealed to be something more modest. A useful tool that found its proper, narrower place once the enthusiasm burned off. Notice, too, what happens to the bars as the eye travels down. They get shorter. The interval between “this is the future” and “that was a phase” has been compressing for decades — from the long reigns of the early platforms to the JavaScript frameworks that now rise and fall faster than a team can master them.
We are not getting better at picking destinations. We are getting faster at being wrong about them.— Sumir Nagar
Four Headstones, Read Closely
Let me start with two from my own stretch of the timeline, because I was in the rooms where they were chosen, and the confidence in those rooms is the part I remember most, some of it my own.
Through the first half of the 1990s, if you were building serious business applications — and if you were building DSS – Decision Support Systems, like I was before the words became common parlance, in and around financial services — the answer was PowerBuilder. Released in 1991, it was a genuine revolution in productivity. It made building data-driven, client-server applications faster than anything before it, and by the late nineties it had something close to a million developers worldwide and ran critical systems inside a great many of the world’s banks. To be a PowerBuilder developer between roughly 1997 and 2002 was to hold one of the safest, most marketable skills in enterprise software. It was, unmistakably, where the industry was going.
And then the web arrived, two-tier client-server architecture began to look like yesterday’s idea, and we saw the advent of three-tier and n-tier. The economics turned, the PowerBuilder license cost serious money while Java was free, and one by one financial institutions began the long, expensive migrations off it. The tool had not become bad. It had simply been asked to be a destination, when it was in truth an excellent vehicle for a particular leg of the journey. The developers who had bet their entire identity on it spent the next decade either migrating away or maintaining systems the market had quietly decided were legacy.
Beneath PowerBuilder, very often ran Sybase — and its arc is sharper still, because it contains a self-inflicted wound that ought to be taught as case studies in business schools. By the end of 1993 Sybase was the world’s second-largest supplier of enterprise client-server database software, the database of choice on Wall Street, growing at better than sixty per cent a year and closing on Oracle. It was a sure thing. And then, having licensed a version of its database to a partner named Microsoft, it watched that partner turn the very same code into Microsoft SQL Server and compete it into the ground. By 2002 Sybase’s share of the relational-database market had fallen below four per cent.
The company that armed Wall Street armed its own executioner — and called the deal a partnership.— Sumir Nagar
If you think this is merely the foolishness of an older generation, consider the database wars that followed, which are even more instructive because the pendulum swung all the way out and all the way back inside a single decade. Around 2009, riding the arrival of Big Data, the NoSQL movement announced the death of the relational database. The old, slow, rigid SQL world was over. The future was distributed, schema-less, horizontally scalable. The enthusiasm ran well past what even the engineers at Google and Amazon, who built the original systems, had intended. Companies declared they would use nothing but NoSQL stores. To insist on a relational database was to be a dinosaur.
And then SQL came back. So decisively that Amazon’s own SQL-compatible database, Aurora, became — in its own chief technologist’s words — the fastest-growing service in the history of Amazon Web Services. A whole new category, “NewSQL,” was invented essentially to reintroduce the relational model the movement had just finished burying, now wearing the scalability features that had been NoSQL’s pitch.
The industry spent a decade traveling in a circle, arrived back where it started, slightly out of breath, and called the return a breakthrough.— Sumir Nagar
Blockchain deserves its own headstone, and a slightly different epitaph, because it is the instructive exception in this graveyard. The others were good tools mistaken for destinations. Blockchain was something rarer and more telling. A genuinely clever answer that went looking for a question, and largely failed to find the ones it had been promised. For a few years around 2017 and 2018 it was declared the future of nearly everything — supply chains, voting, healthcare records, property registries, an entire re-plumbing of the internet under the banner of “Web3.” Enterprises ran thousands of pilots. And then the pilots mostly stayed pilots. Gartner found that only a small fraction of firms rated blockchain important to their business, attributed the spreading “blockchain fatigue” to a simple absence of strong use cases, and by 2024 had so lost interest that it signaled it might stop publishing a hype cycle for the technology at all. The durable use turned out to be narrow — cryptocurrency, and a handful of niches — while the sweeping enterprise promise evaporated. Its lesson is the sharpest of the lot, and it is this. That the confidence with which a thing is declared the future is wholly independent of whether anyone has yet found a problem it genuinely solves.
Blockchain was the rarer case: not a good tool mistaken for a destination, but a clever answer that went looking for a question — and mostly failed to find the ones it was promised.— Sumir Nagar
And running underneath all of it now is the JavaScript front-end, which deserves a final mention because it stopped being a wave and became a permanent weather system — the churn you can see on the chart fragmenting into ever-shorter bars. For more than a decade the framework of the moment has changed faster than a team can reasonably master it, each arriving with the identical promise that this, finally, is the stable foundation, and each superseded before the documentation is dry. The developer who invested deeply in the framework of 2014 found much of that knowledge devalued by 2018, and again by 2022. Rails, lived the same story one rung higher. The framework Twitter was built on, was hailed around 2008 as the future of all web applications, before Twitter itself tore it out at scale and the industry moved on — though, tellingly, Rails did not die, and still quietly runs Shopify and GitHub today. None of these technologies failed. They were simply mistaken, by their most fervent adopters, for the end of the road.
Why We Keep Doing It
Why do intelligent, experienced people — people who have lived through three or four of these cycles — keep making the same bet? The answer is not stupidity. It is structure, and incentive, and a very human discomfort with a particular kind of uncertainty.
Part of it is the cost of being late. The fear is real and not irrational. The firm that ignored the web in 1996, or mobile in 2009, did genuinely suffer. So “we must be on the new thing” is learned from real disasters. The difficulty is that the lesson over-generalises — it teaches you to fear missing the destination so much, that you lose the ability to ask whether this particular thing is the destination at all. Every wave gets adopted as though it were the web, because no one wants to be the person who dismissed the web.
Part of it is that “adopt the new thing” is a defensible decision and “wait and see” is not. If you back the new framework and it fails, you were being bold. Everyone was doing it. If you decline to back it and it succeeds, you are a fool who missed the future. The incentives are asymmetric, and they push relentlessly toward motion. I have sat in those rooms. The safe career move and the wise technical move, are frequently not the same move, and the safe one usually wins.
The deepest part, is that you genuinely cannot tell a destination from a detour while you are standing on it. In the moment, the enthusiasm of a NoSQL or a Rails or a front-end framework is indistinguishable from the enthusiasm that surrounded the genuine, permanent advances — the web itself, the relational database, the move to the cloud. They feel the same from the inside. The only reliable way to know which was which is to wait, and waiting is the one thing the incentives will not permit.
The Discipline of the Provisional
So what does one actually do, if the pattern is real and the incentives are immovable?
Not abstention. I am not arguing that you should ignore every new technology and wait for certainty, because certainty never arrives in time to be useful, and genuine revolutions do happen and do punish the absent. The answer is subtler and harder. To adopt while holding the adoption as provisional. To bet on the new thing without believing the prophecy that attends it. To build so that you can leave — to treat every technology as a tool that has found a job, rather than a destination you have finally reached. So that when it turns out to be a detour, as it usually does, you are not so deeply married to it that the divorce destroys you.
The engineers and institutions I have watched survive these cycles best, were never the earliest or the most enthusiastic adopters. They were the ones who held their tools loosely. They asked of each new arrival not “is this the future?” — an unanswerable question — but “what specific problem does this solve well, and what will it cost me to leave when something better comes?” That is a far less exciting question. It does not make anyone look like a visionary. It is also the only question that has reliably protected anyone from the graveyard.
The ones who survived never asked “is this the future?” They asked “what will it cost me to leave?”— Sumir Nagar
I now find myself to be inexorably drawn, to the newest and largest occupant of the boardroom — the one technology on that chart whose arc is not yet drawn, because we are living inside its rising line.
Artificial intelligence is being announced, in every meeting on Earth, with precisely the sentence I opened this essay with. This is the one. This is where the industry is going. We need to be on it.
It may well be the web — a genuine, permanent, civilizational shift. It may be the relational database — real, foundational, but narrower in the end than the prophecy. It may, in some of its more breathless current forms, prove to be another Rails. A marvelous tool, oversold as a destination, destined to find a humbler and more honest place once the enthusiasm cools. I do not know which. Nobody does, and anyone who tells you they are certain is selling something — most likely the thing itself. What I do know, from forty years of watching this same scene replay, is that the confidence in the room tells you nothing about which it will be. The confidence was identical every previous time, including all the times it was wrong.
The graveyard is full of sure things. Each headstone reads the same: this was the future. The wise response is not cynicism — the genuine revolutions are buried in that same field, and they mattered. The wise response is humility about which is which, held while everyone around you is certain. Adopt, by all means. But hold the tool loosely, keep the receipt, and never, ever believe the part of the pitch that tells you the journey is finally over. It never is. There is always another sure thing, already being readied, already wearing the costume of arrival.
Related — The Series This Accompanies
Part 1. From Punch Cards to Claude Code
Part 2. There Is No Cloud
Part 3. The Question Nobody Funds
Sources
- PowerBuilder released 1991; ~1 million developers worldwide by c.1997; dominant in client-server business and banking applications c.1997–2002, then displaced by web architectures and the cost gap with free Java — Grokipedia; HandWiki; DisplacedGuy. grokipedia.com
- Sybase the world’s second-largest enterprise client-server database vendor by 1993 (~61% growth), popular on Wall Street; licensed its database to Microsoft, which became Microsoft SQL Server; Sybase’s market share fell below ~4% by 2002 — FundingUniverse; Datamation; InformationWeek; Database of Databases. fundinguniverse.com; datamation.com
- Ruby on Rails released as open source (2004); early adoption by Twitter, Shopify, GitHub, Airbnb; “Rails developer” among the most sought-after Silicon Valley roles c.2013 — Monterail; RailsFactory; AgileWay. monterail.com
- Twitter’s scaling problems on Rails and its move of key systems to the JVM / Scala — TechCrunch (2008); SitePoint; BairesDev tech-stack history. techcrunch.com
- Rails’ relative decline in popularity while remaining in production at GitHub, Shopify, Dropbox; supplanted at the frontier by Node.js and JavaScript frameworks and by microservices architecture — Monterail (2024–2026). monterail.com
- NoSQL movement (term popularised 2009) driven by Big Data and the systems behind Google’s MapReduce/Bigtable and Amazon’s Dynamo; subsequent resurgence of SQL, with Amazon Aurora described by AWS’s CTO as the fastest-growing service in AWS history; emergence of “NewSQL” — Tiger Data; use-the-index-luke; Packt. tigerdata.com
- NoSQL as catch-all for non-relational stores and the “end of relational” framing, later moderated — Metal Toad; ResearchGate (NoSQL movement overview). metaltoad.com
- Timeline arcs in the chart are illustrative and interpretive, anchored to the documented turning points above; they do not represent measured adoption data, which is not available in comparable form across this period.

Leave a Reply