views:

156

answers:

7

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?

+1  A: 

When improvements or additions are necessary for a program (or OS, etc), you have two options:

  1. Add to the current solution
  2. 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.

Cam
+1  A: 

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.

marklai
+4  A: 

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.

John Knoeller
I have to agree its rarely a good idea to rewrite code from scratch. Iterative updates to the code are much more efficient and productive, if somewhat more costly in the beginning.
GrayWizardx
@GrayWizardx - I'm curious - why do you say iterative updates are more costly in the beginning? Because you have to spend time learning the code? Or something else I'm missing?
JasCav
@Jason iterative updates are almost always done as a add-on to already existing work. if it were part of the primary work path (i.e. the feature or fix) you would have added the cost into the overall cost of the rewrite/update into the cost of the work. Usually though you are addressing something tangental to the actual work (libraries outside of it, code refactoring, etc) and this must be paid for in addition to the cost of whatever required work is scoped.
GrayWizardx
+1  A: 

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.

Woot4Moo
+1  A: 

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.

wheaties
+2  A: 

consider the time taking with the current code to :

  1. maintain it
  2. add functionality
  3. rewrite the same code base using new technique/language/etc.
  4. maintain the new code
  5. 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
mathroc
+2  A: 

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.

GrayWizardx