> It's easy to "replace" it with something that is buzzword-compliant and that uses the new shiny, but that doesn't cover all the cases and doesn't have all the needed bug fixes. That's not a step forward.

This is a false equivalency imo. If you build a replacement system that is buggy and sucks, you did a bad job, it has nothing to do with the tools that you are using. This seems like more of a criticism of management to me

> If you build a replacement system that is buggy and sucks, you did a bad job

Or you just didn't know about all the edge cases, niche ways of using it, and the regulation on page 475 of some arcane law code that requires that something be so.

> Or you just didn't know about all the edge cases, niche ways of using it

Sure but this goes both ways. Developers cannot know all future requirements when writing the software. SaaS models largely alleviated this problem because people are continuously working behind the scenes adding new features and fixing bugs

What you say is true. But it's really hard. It's almost impossible to get all the corner cases and only-documented-in-the-code requirements. It's, yes, a criticism of management, but it's not just that they managed the process badly. It's that they chose to go down that path at all.

It is also true that old code gets harder and harder to modify, and requirements do change, so you have to modify the old code. But you're not going to make good choices on whether or when to rewrite if you mis-estimate how hard the rewrite is to get right.

> What you say is true. But it's really hard. It's almost impossible to get all the corner cases and only-documented-in-the-code requirements.

See my other comment about continuous improvement, iteration and SaaS. We can’t expect people to get things right the first time, or ever for that matter.