
When is a BIG Rewrite the answer? - tsudot
http://programmers.stackexchange.com/questions/6268/when-is-a-big-rewrite-the-answer
======
lugg
Over the years my opinion on this sways between never, and whenever you feel
like it.

Never: its far too risky, usually ends up not fixing half of the issues in the
first place. Better off taking scorched earth refactor approach at the class /
file level than system level.

Whenever: the more often you do something, the better at it you should get,
the faster you will get, and the better your designs will get.

I think there really is likely some middle ground in there.

The one thing I caution against is not to refactor while doing bug fixes
unless it is part of fixing the bug. Overcomplicates the situation
dramatically, make a note to refactor next time you're replacing a feature /
have some downtime (lol downtime)

------
dragonwriter
When you can't do a component-wise rewrite and the cost of not fixing the
currently-inadequate components justifies the cost and risk of a big rewrite.

But make sure when you do it you build with a loosely coupled architecture so
that this is _never_ an issue again -- any system that will force you into
deciding when a big rewrite is necessary is badly designed.

