TL;DR
For a couple of years I watched a few hundred smart people bleed a clever product to death by choosing bleeding-edge technologies that hadn’t yet paid their discovery tax. Spolsky wrote about a version of this in 2000. Dan McKinley wrote about another version in 2015. Both posts age well, for the same reason — the temptation they describe never goes away.
For a couple of years I’ve been watching a slow-motion train wreck. A few-hundred-person company building a genuinely clever product — real market demand, design that cut through administrative and policy limitations the existing players had to live with, the kind of thing you’d want to root for. Smart people. The kind of team you’d want to work with on a different problem.
What killed it wasn’t the market or the design. It was the architecture.
The team got excited — understandably — about the possibility of building something with bleeding-edge technologies. Something technically superb. Bleeding-edge solutions make you bleed when you discover their edges, and sanding those edges takes time and effort a fast-moving company doesn’t have when it’s burning runway to ship. The result was the predictable one: huge stressful flailing around bugs while trying to deliver features, and an inevitable implosion. The rest of the company watched it happen for two years. The investors eventually watched it too.
You know how this story ends. The market window narrows, the funding gets harder to argue for, somebody does the math on what it would cost to start over with boring technology versus what it would cost to fix what’s there, and the answer to both questions is “more than the company has left.”
This isn’t a new story. It’s not even a recent story. Joel Spolsky wrote about a version of it in 2000.
The original
In Things You Should Never Do, Part I, Spolsky argued that throwing out a working codebase is the single worst strategic mistake a software company can make. He was writing about Netscape’s decision to rewrite their browser from scratch — a decision that, in his telling, lost them three years and the market while their competitors shipped. The point wasn’t that Netscape’s old code was elegant. It wasn’t. The point was that the old code encoded thousands of bug fixes nobody could see — defensive checks for browser quirks, edge cases discovered in production, paper-overs for things that had broken on real users’ machines years earlier. None of that history was visible in the diff. All of it was in the binary.
A rewrite, Spolsky argued, throws all of that away. The new code looks cleaner. It is, in the way a freshly built house with no ductwork looks cleaner than a renovated one. The renovated one keeps you warm in February.
The 2026 version of his principle is the same shape, one step earlier in the lifecycle. Spolsky was talking about throwing away worked code in favor of unworked code. The version that’s killing companies right now is choosing unworked code over worked code in the first place — picking a stack whose bug fixes haven’t been written yet, whose edge cases haven’t been mapped, whose production-failure-modes are still in the future. Same invisible inheritance. Same invisible loss.
The smart team I watched didn’t rewrite anything. They picked their stack from a catalog of technologies that didn’t yet have the catalog. There were no battle-scarred best-practice guides, no Stack Overflow answers from six years ago, no senior engineers with twelve incidents’ worth of bruises under their belt available for hire. Every problem they hit was a new problem. Some of those problems had been solved by other teams elsewhere on the bleeding edge, but the solutions hadn’t propagated yet — there was no field guide, because the field hadn’t been mapped.
That’s the discovery tax. Somebody has to pay it for any technology to become boring. The question every architect implicitly answers is: do I want to pay it, or has somebody else already paid it for me? The team I watched answered the first version. They didn’t realize they were answering it.
Innovation tokens
Dan McKinley wrote about the same shape of problem in 2015, in an essay called Choose Boring Technology. His framing was that every team has a finite supply of “innovation tokens” — three, maybe, on a generous estimate. You spend them on the things you have to spend them on, and you get nothing else novel for free. If your product is novel, that’s a token. If your distribution model is novel, that’s another. If your business is novel, that’s the third.
What McKinley was warning against was spending those tokens on things that aren’t your product. Your database isn’t your product. Your message queue isn’t your product. Your build system isn’t your product. Spend a novelty token on a database nobody on your team has run in production and you’ve burned a third of your budget on something the customer will never see. Spend two of them on your infrastructure and your product itself doesn’t get to be novel — there’s no token left for the thing the customer is actually paying you to do.
The team I watched spent every token they had. Possibly more than they had — some on credit, against tokens future-them was going to need. By the time the runway started getting visibly short, they’d already committed to substrates they couldn’t easily walk back from. Ripping out the bleeding-edge database would have meant rewriting half the application. Ripping out the bleeding-edge message bus would have meant retraining the half of the team who’d just gotten productive on it. Every escape route had its own discovery tax attached.
Most discussions of McKinley’s essay focus on the recommendation — use boring technology — and skip past the deeper observation about why the rule is hard to follow. The rule is hard to follow because the people making the choice are not the people paying the cost. The architects pick the stack at the start of the project, when the excitement is highest and the pain is theoretical. The people paying the cost are the on-call engineers eighteen months later, the support team handling outages on a database with no useful documentation in their language, the new hires struggling to onboard onto something Stack Overflow hasn’t heard of, and eventually the investors looking at a burn rate that doesn’t match the velocity. The architects, by then, are often onto a different project.
Douglas Adams had it right about towels. Always know where your towel is. The most useful thing you can carry is the boring thing, because the boring thing has had its uses worn into it by everyone who carried one before you. Bleeding-edge tech is the opposite. You don’t inherit anyone’s lessons; you write them yourself, in production, on a deadline.
I bought a boat
A few years ago I lived on a boat. Four-plus years, full-time, the kind of arrangement most people romanticize without quite understanding what they’re romanticizing.
The boat was a compromise. It was big and comfortable — the interior was the reason I bought it, more living space than most studio apartments, a galley you could actually cook in. It was also big and expensive to operate. The huge comfortable interior meant smaller water and fuel tanks, which meant less autonomy, which meant more nights tied up at marinas paying dock fees and fewer nights anchored out somewhere quiet. The boat was a heavy beast — not the fastest, didn’t point upwind especially well, no one was going to mistake her for a racing yacht. None of that was a surprise. All of it was in the spec sheet.
The compromise fit the life I was after. I wanted long stretches of comfortable living-aboard, occasional shorter cruises, and not much in the way of bluewater passages. The boat I bought was correctly optimized for that life. Somebody who wanted to cross oceans would have made the opposite trade and been right to. Somebody who wanted to race would have bought something else entirely. The boat was boring in the sense that the design choices had been made by the manufacturer years before I owned her, and refined by a previous owner before me. I inherited the bug fixes.
I met plenty of people during those years who’d made the opposite choice. People with great dreams about sailing and free-spirit lifestyles who’d bought project boats — older hulls with potential, custom builds, ambitious refits — and who spent their years working on the boat instead of living on it. Sanding rails. Rewiring. Replacing the engine, which led to discovering the gearbox needed rebuilding too, which led to discovering the shaft alignment was off, which led to a yard bill they hadn’t budgeted for. They were the smartest, most capable people I met on the docks. They were also tired in a way the people who’d bought finished boats off the catalog weren’t tired.
A lot of those projects ended the same way. The boat got sold — usually for less than the owner had into it — and the owner went back to land with a slimmer wallet and a shelf of regrets. Not because they were foolish. They weren’t. They were good engineers and good sailors. They’d just spent every token they had on the boat itself, and had nothing left for the life the boat was supposed to enable.
I bought the boring boat. I got the years of life I was after. The boat was a compromise; the life on it was not.
Every choice is a compromise
This is where the technical version and the boat version meet.
Every architecture is a compromise. So is every boat. So is every product, every team, every life. There is no choice that gives you everything; there are only choices that trade something for something else. The mistake the team I watched made wasn’t picking bleeding-edge technologies. It was picking the trade-off that fit the work the engineers wanted to do instead of the trade-off that fit the company they were trying to build. Those weren’t the same trade-off. They are almost never the same trade-off, because the work that excites senior engineers is, by definition, the work that hasn’t been done yet, and the work that ships products to market windows is, by definition, the work that has.
This isn’t a moral failure on anyone’s part. It’s a structural problem with how excitement gets allocated. Smart people are drawn to interesting problems. Companies need them to solve boring ones. Knowing what you spend your enthusiasm on is not optional; it’s the difference between the project that ships and the one that doesn’t.
The boat version is the same shape. The people who burned themselves out on project boats weren’t foolish either. They were optimizing for the romance of building a boat when what they wanted was the life of sailing one. Different objective. Different optimization. Same regret at the end.
Spolsky’s original principle, restated for 2026: don’t throw away worked code, because the bug fixes are invisible. The version one step earlier: don’t choose unworked code over worked code, because the bug fixes you’d skip are equally invisible — they’re just not in your repo yet. McKinley’s principle alongside it: every team has three innovation tokens. Spend them where the excitement ships. Spend them where the customer pays for the novelty. Spend them on the actual product. And the corollary nobody likes saying out loud: Not Invented Here comes with a tax attached to it, and the tax compounds.
Pick the compromise that gets you the thing you said you wanted.
Use boring technologies to do cool things.