Hacker News new | ask | show | jobs
by carlmr 3168 days ago
>> 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.

1 comments

> 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.

> 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.)