[zimpenfish]

> once all features and edge-cases are accounted for.

But one of the benefits of a rewrite is that you can dump all the features and edge-cases that are no longer required. Or fold old edge-cases into new generalities because the business has changed since then.

> the real world is messy, very messy.

Cannot disagree -but- it's nowhere near as messy as the people (often those who are to blame) defending the byzantine software stacks using that argument.

> reality is going to temper their enthusiasm after a decade or so.

I've been doing this professionally for two decades and my enthusiasm for "chuck it away and do it right" hasn't waned one bit.

[btschaegg]

>> the real world is messy, very messy.

> Cannot disagree -but- it's nowhere near as messy as the people (often those who are to blame) defending the byzantine software stacks using that argument.

This. As a still relatively young developer, I can almost guarantee you that the initial reaction of "nuke it from orbit!!!" doesn't come from a couple of minor abstraction problems. You get this reaction when every second bug you try to fix ends in a trip to Klendathu.

[carlmr]

>> reality is going to temper their enthusiasm after a decade or so.

>I've been doing this professionally for two decades and my enthusiasm for "chuck it away and do it right" hasn't waned one bit.

I think it's probably somewhere in between the two extremes. I think you should have good unit tests and then refactor parts of your code where you see better generalities, or where basic code cleanliness was disregarded before.

But throwing all of it away is rarely possible without endangering the profitability of the company for a while.

[zimpenfish]

> throwing all of it away is rarely possible without endangering the profitability of the company

Well, obviously I don't mean "turn it off and wait for the new system to be finished". You build the new one whilst the old one is in maintenance mode and swap in new bits as and when you can.

For example, at current $WORK, the backoffice system is a horror show of overcomplex PHP that is riddled with bugs and no-one really understands how it all works. Replacing that would be a huge boon both humanly and monetarily to the company because CS use it heavily every day.

[dragonwriter]

> You build the new one whilst the old one is in maintenance mode and swap in new bits as and when you can.

Continuous incremental improvement of a production system may, over time, have the same net effect as a an idealized big-bang replacement, but it's a very different process (it's usually what people who are saying you should never do a ground-up replacement prefer instead, because actual big-bang replacements, unlike idealized ones, are usually a shitstorm: and the reason is that they are usually done to the kind of systems you describe, overcomplicated key systems with inadequate documentation or institutional memory, and they are done instead of trying to get a firm grasp on each component of the existing system before replacing that component. And so they end up, at best, being exceedingly well designed, but overlooking key elements of business function discovered and implemented, but not durably documented, in the original system.)