
What to Consider Before Embarking on a Rewrite - rfreytag
https://www.mcls.io/blog/before-embarking-on-a-rewrite
======
mark-r
This was a lot lighter in content than I expected it to be.

Having survived one rewrite, I'll say that you're sure to drastically
underestimate two things: how long it will take, and how many bugs there will
be when you're done.

------
WheelsAtLarge
A complete rewrite isn't usually worth the trouble unless you are reaching a
bottleneck that you just can't fix. The never-ending bug fixes to your new
code will leave you with the same situation that you were trying to fix in the
first place. And to top it off you've lost ground since you had to rewrite the
base and use your best resources to do it while losing ground to competitors.

Your best bet is to pick sections of pain in your code and refactor them.

I remember that in the '90s Netscape decided that their browser engine code
could no longer be used so they had to rewrite it. It took over 2 years and
they had to pretty much stop adding new features to their old codebase. They
finally delivered the new code, later than they expected. The engine was
slower, was full of bugs, and did not add anything to the user experience.

It wasn't the primary reason why they lost the browser war to Microsoft but
they used a lot of resources to deliver an inferior product at a time when
they had very little room for mistakes.

It was not a complete waste since the code eventually became the first code
used by the Mozilla foundation.

------
rurban
"Hype is the plague on the house of software" as Robert Glass put it in "Facts
and Fallacies of Software Engineering". A very good citation, the rest is not
worth reading.

Hype driven development is for long a big thorn in my eyes. Esp. with rust and
raku/perl6.

