Joel is right, but he's also wrong. I've been on the other side of a timid engineering culture that commerical rides roughshod over and its this depressing immeasurable decline. The company stagnates and slowly tailspins around an unmaintainable product until a competitor steals their lunch in a way that that further obscures cause and effect.

Estimates are considerably longer, QA is much harder, integration is full of buckets and rakes, some "senior" devs are afraid to touch stale core code, innovation is stifled, devs are frustrated, hiring is harder, attrition bites. The most frustrating thing is that its very hard to communicate the issues as everyone experiences a fragment of the pain and none of it lines up in a spreadsheet for anyone to appreciate the whole cost. Everything just sucks.

LLMs changing the economy of this sounds great, especially if removes the essential issue with the ground up rewrite, which is the "ground up" part.

The LLM might change the economy of this, but I doubt it.

I tend to believe that the engineering culture you describe will end up producing similar or, as Joel postulates, an even worse result, just dressed up in a modern stack.

If the technical leadership remains the very same one that enabled such a culture, I don't see them being able to suddenly produce a genuinely better software product only because an LLM is in a picture - especially considering how easy it is to convince an LLM that your idea is the best one.

Well, Joel is not saying not to refactor anything. In fact he is advocating improving the code quality in small steps. What is missing there is that in practice improving code quality in small steps requires automated tests . But I guess he can be forgiven given when he wrote the article.

I think the important lesson is to use clear eyes to evaluate what the rewrite buys you. I was on a team that rewrote a native code app in C#. We also had access to early cloud tech in the Azure stack, what is called queue now and then was called service bus.

These two technologies combined greatly simplified this specific product making it far easier to maintain. Performance on these services was not important so native code was carrying a lot of penalties without the benefits.

Having a well documented messenger like service bus with great SLAs removed several tools we had needed in the old implementation.

We were able to leverage the tests form the original product to define success and tmthus were able to solve a lot of the edge cases in the new code w before we even shipped.

However, the old code was perfectly fine code. If new technologies had not provided significant simplification of the service architecture, a rewrite would've been foolish. And without the very good previously existing tests, we would've run into a lot of issues as we released.