I know that under most situation we should avoid rewriting code from scratch. But there must be some cases where rewriting is beneficial (e.g. otherwise MS wouldn't abandon Win98/Me and develop XP from NT). What are those cases?
When improvements or additions are necessary for a program (or OS, etc), you have two options:
- Add to the current solution
- Rewrite the solution, including the addition in the rewrite
Whichever is most cost-effective (monetarily, time-wise, or whatever the case may be) is then chosen.
Example:
- If you want to make an addition but the current code is garbage, it might take you two hours to rewrite with the addition, or five hours to sort through the old code and add to it.
Note:
- Even if the costs don't warrant a rewrite for the current update, it still might be a good idea if there are enough future updates planned that the rewrite costs will soon be justified.
Basically it's just a weighing of the costs/benefits of a rewrite vs. adding to the current solution.
When you can prove that a rewrite is cheaper than maintaining the existing code, or at least convince the stakeholders that this is the case.
I refer you to Joel Spolsky Things you should never do, part 1
And I must say I don't agree that Microsoft abandoned Win98/Me. Windows9x was written after Windows NT, it was always intended to be a migration path between Windows 3.1 and Windows NT. Once it had served its purpose (which took a bit longer than they expected), then they stopped improving it.
Code should be re-written from scratch when you change the language in which the code base is written. Beyond that the things you change because they were "horribly bloated" will eventually break because the line that fixed an issue from 3 years ago was excluded.
When you need to convert from single threaded to multi-threaded and have discovered that in it's present implementation, it can't handle more than a single thread.
consider the time taking with the current code to :
- maintain it
- add functionality
- rewrite the same code base using new technique/language/etc.
- maintain the new code
- add functionality into new code
check if you can do (3) while (1), if so, compare (1)+(2) >?> (4)+(5) if (4)+(5) <<< (1)+(2) and you can wait until (3) is completed, I think you should rewrite from scratch
other things to consider:
- maintaining code is often harder and harder
- adding functionality, the same
- rewriting may mean stopping backward compatibility but also better performance/usability/etc.
- this is the occasion (if not already done) to do unit/regression tests
I think most times the cost of rewriting code, especially from scratch is under estimated. For instance code which is stable (and by stable I mean deployed and showing no bugs, not that it doesnt have bugs, just that it has no logged bugs) might be scary and "unmanageable" but it does not need attention at this moment. The cost of addressing code which was previously in this state but has now been modified because it was part of a rewrite can be costly in terms of dev time, design time, QA and user verification. If you only consider the time it takes to write the code itself you are not taking into account all the variables.
If possible I would recommend never rewriting from scratch. Instead plan to deprecate code and replace it with more stable code which takes advantage of repeated QA and design cycles to improve it. Start by moving high usage code to new functions under more rigorous testing and with a dedicated QA effort around them and slowly deprecate the old code. This gives you the advantage of biting of pieces you can address as well as having a fallback if something fails or has to be rolled back.