Pretty similar article to some old Spolsky blogposts:
https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
Some of them ended up proving wrong (like he once predicted that making graphic cards would be a very thin margin business[0]), but most are still true today. Probably truer than when they were written.
[0]: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v In his defense, by the time 'video chips' were totally different things from today's mighty 5080.
Consumer GPUs really are not where the money is. It’s only a tiny fraction of Nvidia’s revenue, and much lower margin. Datacenter GPUs are where the volume and margins are.
It was very well done and strategic on their part but realistically without that they are not that much better than AMD and the margins would be much smaller if it had 1-to-1 compatibility as an x86 has.
Also, since improvements have been plateauing and entry level is becoming enough for more and more people the margins are going to diminish even more, high-end GPU is going to become even more niche overtime IMO.
So, I'd say he is not wrong in spirit, the timeline is just bigger than expected.
[0]: https://nvidianews.nvidia.com/news/nvidia-announces-financia...
Out of $46B about $41B is from datacenter.
People know they should do coding tests in interviews, but not how they're designed to find smart and get things done.
People know they should code clean, but not how it only needs to be clean enough to spot dangers.
Some companies are paying super high prices for interns, and then don't try to integrate them into their recruiting funnel.
That said, I think your overall point isn't affected by my idea. Even a great mind can be wrong occasionally. He doesn't have to be right every time.
CNNs and LLMs became feasible and viable much later. People in the 1500s would also have bet on the automobile and the Wright brothers. Right after drinking coffee from their microwave.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
There is of course some truth wrapped up in those thick layers of punditry, but even today that article gets trotted out as some kind of Revealed Truth of Software Engineering to be swallowed and digested without qualification.
(Edit: I agree that from-scratch total rewrites are rarely a good idea, and should require blindingly obvious justification at the very least. I still cannot take all the points about Old Code at face value, since rewrites often come about after Lots of Bugs have been found and continue to be found)
In our real timeline, Netscape did rewrite. During the rewrite their market share halved. And they died a few years later. So yeah, the lesson here is if you're okay to let your company just die and rebuild a new one, it's perfectly fine to rewrite the whole codebase.
Rewrites often do work out in the long term. However you end up spending 10 years on the rewrite and those are 10 years where the old thing isn't getting as many features (everyone knows it is dead long term so they only invest in the most important features thus allowing your competition time to catch up). Worse those, in 20 years (10 years after the rewrite replaces the old thing) the rewrite is showing age because of things you wish you had done differently.
Which is why I advocate for fixing the old code in place over time. No matter what your best ideas while turn out to be wrong in some way. Architecture decisions that seemed good turn out of have downsides. Languages that go obsolete. APIs everyone uses that you realize should have been done different (If they are only used in one places that is an easy change). Core data structures that no longer meet your needs, but you can't change without touching a million places that update it. You will need a long term effort to fix those mistakes whatever they are. Sure it will take longer to get the old thing to where it needs to be than the rewrite, but you are not saving anything as the new thing will have different mistakes that you will regret in 10 years.
Also the above is in context of a large program. My program to draw names for the family Christmas drawing is easy enough for anyone to write from scratch in an hour so who cares. When your are on a project that costs over 1 billion dollars to write you have different constraints (some of you are on small projects that it is better to write from scratch each time)
In-context, his point is pretty obviously (I think) more like "given a piece of code, it's never better to rewrite." His point is not that newer software can't come along and be better than old software. Rather, all other things being equal, rewriting is an inferior development choice.
To be fair, the author may not have been aware of these previous posts. I find that “kids these days” don’t really read the classics.
For those not aware, Joel Spolsky, Steve McConnell, Don Norman, and a whole bunch of others, really thought hard about our vocation, and wrote down their thoughts.
Might be worth a gander.