refactoring – When is it good (if ever) to scrap production code and start over?

refactoring – When is it good (if ever) to scrap production code and start over?

Without any offense intended, the decision to rewrite a codebase from scratch is a common, and serious management mistake newbie software developers make.

There are many disadvantages to be wary of.

  • Rewrites stop new features from being developed cold for months/years. Few, if any companies can afford to stand-still for this long.
  • Most development schedules are difficult to nail. This rewrite will be no exception. Amplify the previous point by, now, a delay in development.
  • Bugs that were fixed in the existing codebase through painful experience will be re-introduced. Joel Spolsky has more examples in this article.
  • Danger of falling victim to the Second-system effect — in summary, “People who have designed something only once before try to do all the things they didnt get to do last time, loading the project up with all the things they put off while making version one, even if most of them should be put off in version two as well.
  • Once this expensive, burdensome rewrite is completed, the very next team to inherit the new codebase is likely to use the same excuses for doing another rewrite. Programmers hate learning someone elses code. No one writes perfect code because perfection is so subjective. Find me any real-world application and I can give you a damning indictment and rationale for doing a from-scratch rewrite.

Whether you ultimately rewrite from scratch or not, beginning a refactoring phase now is a good way to both really sit down and understand the problem so that the rewrite will go more smoothly if truly called for, as well as giving the existing codebase an honest look to really see if a rewrites needed.

To actually scrap and start over?

When the current code doesnt do what you would like it to do, and would be cost prohibitive to change.

Im sure someone will now link Joels article about Netscape throwing their code away and how its oh-so-terrible and a huge mistake. I dont want to talk about it in detail, but if you do link that article, before you do so, consider this: the IE engine, the engine that allowed MS to release IE 4, 5, 5.5, and 6 in quick succession, the IE engine that totally destroyed Netscape… it was new. Trident was a new engine after they threw away the IE 3 engine because it didnt provide a suitable basis for their future development work. MS did that which Joel says you must never do, and it is because MS did so that they had a browser that allowed them to completely eclipse Netscape. So please… just meditate on that thought for a moment before you link Joel and say oh you should never do it, its a terrible idea.

refactoring – When is it good (if ever) to scrap production code and start over?

A rule of thumb Ive found useful is that if given a code base, if I have to re-write more than 25% of the code to make it work or modify it based upon new requirements, you may as well re-write it from scratch.

The reasoning is that you can only patch a body of code so far; beyond a certain point, its quicker to do over.

Theres an underlying assumption that you have a mechanism (such as thorough unit and/or system tests) that will tell you whether your re-written version is functionally equivalent (where it needs to be) as the original.

Leave a Reply

Your email address will not be published. Required fields are marked *