When can we put the "don't rewrite old code" myth to rest? People cite Joel's essay in many situations where it can be reasonably believed to be applicable, but

When can we put the "don't rewrite old code" myth to rest? People cite Joel's essay in many situations where it can be reasonably believed to be applicable, but they also cite to people who are in a much better position to determine whether it is applicable. I've had to inherit a couple of troubled Go codebases with a lot of bugs, to the point of near-constant outages and functional incorrectness problems attributable to many different causes all throughout the codebase. One of them was amateur work with zero tests or docs, but it was only about 10k lines of well-delineated components I could understand and rewrite one by one. The end result was effectively a total rewrite, but as Joel suggested, I always had a shippable version at any given moment. One project was "professional" work with tons of structure and tests, but it was 70k lines for what should have been at most 15k. Worse, it wasn't delineated at all in practice; every component depended on everything else in fine detail. Even the many "interfaces" that were defined were always circumvented by various means anyway, including in tons of copy-paste unit tests that barely caught any bugs but took hours to update when trying to fix the bugs they didn't catch. This was a total writeoff and replacing it with 15k lines took less time than fixing some individual bugs in the original code. It wasn't "Real-world code evolves to fits its niche, and as it does so, it becomes more complex and harder to understand". Sometimes people do write code more complicated and fragile than it needs to be, and often the people that do that also fail to refactor it later. The more stakes they've loaded onto their rickety mess, the harder it is to justify the risk of maintaining it, even if the steady state is abysmal. Despite both being Go -- a language praised for its maintainability -- one of them is the kind of project that can be evolved in-place, and the other can barely even be bandaided much less meaningfully evolved. I think everyone who's maintained enough projects has seen a mix of both. People parroting that you should never rewrite either haven't worked on the second kind of project, or are just assuming that it will always be someone else's job to work on that kind of project. Either way I'm not especially persuaded.