As entertaining as that article was when it came out, I think its apparent wisdom should have been reevaluated for at least the past two decades. Even back when it was written, its pertinence was questionable, since it hinged on the perception that written code has particular value, to justify much of the failures at Netscape and Borland, neglecting many of the other -- probably more relevant -- business and human factors that were at play within the two organizations and their surrounding ecosystems. But lessons learned from watching startups fail in trove in the following two decades have mooted many of Joel's arguments. With the vantage of hindsight, if you read JWZ's account of what went on at Netscape, some of the dysfunctions become glaring.
Making software projects successful has always been about a lot more than just writing code. People have been "rewriting code from scratch" successfully even before LLMs. We just don't tend to call it that. We call it "cloning", "competition", "copy", "alternative-to", "reverse-engineering", "x-written-in-language-y", etc.
It's funny, but I think the article is showing it's age. It's no longer true.
In hindsight having automated auto complete rewriting your code base wasn't something on 2000's radar.
Now switching from language to language is much easier. Just for Rust, there was Ladybird and Bun complete rewrite, that ran into zero things that Joel rallied about.
> It's funny, but I think the article is showing it's age. It's no longer true.
Joel argues 2 effects:
# Developer & time-cost of a rewrite is a big unknown. That's still true, but LLMs may cut that down by a factor of 10x or more. You cut time & developer-hours by throwing tokens ($) at it. An optimist might say this cost has vanished.
# Shipping a rewritten product is -by itself- an unknown risk. That still holds. You can do all the testing you want, but your test suite != your clients environment(s? multiply by number of users or target platforms).
A single bug that pops up in the rewritten codebase (which wasn't in the old one) can hurt a vendor's reputation badly if the stars align just right.
All in all Joel's article held up pretty well (esp. given how long ago it was written).
> Developer & time-cost of a rewrite is a big unknown... An optimist might say this cost has vanished.
I wouldn't say it vanished. I'd say it moved from unknown to known. It's highly likely that for code the size of Bun the price is around 200k dollars of tokens + a month of programmers time to monitor it.
> Shipping a rewritten product is -by itself- an unknown risk. That still holds. You can do all the testing you want, but your test suite != your clients environment(s? multiply by number of users or target platforms).
Fair point.
That said, it seems the number of relevant platforms is shrinking. Both on the hardware side - x86_64 AMD, x86_64 Intel, and aarch64. On the OS side, you have Linux, Mac and the dying Windows.
Still, it seems with enough tests and original source code, you can limit this risk to a few edge cases.
> All in all Joel's article held up pretty well
Aside from the fact that it mostly applies to commercial endeavors[1], it still missed the mark on old code decaying over time.
Turns out being exposed to the Internet has a chance to turn even old code sour.
[1] If you don't care about your users, or you care more about pleasing/attracting new developers, then points made in his article don't make rewriting it that bad.
I think it was always hyperbolic to call rewrites the single greatest mistake (I can think of worse) but I think most of the wisdom still holds. And AI generated rewrites are arguably riskier because now NOBODY is familiar with the massive codebase.
Making software projects successful has always been about a lot more than just writing code. People have been "rewriting code from scratch" successfully even before LLMs. We just don't tend to call it that. We call it "cloning", "competition", "copy", "alternative-to", "reverse-engineering", "x-written-in-language-y", etc.