Home > Software development > When should you rewrite and when should you just modify that old code?

When should you rewrite and when should you just modify that old code?

Photo by quasimondo

Today I was in need of arguments to support my personal opinon, so it was kind of an ordinary day. As always I turned to Google. After some fruitless clicking around I finally found something useful over at stackoverflow.

Jack Marchetti neatly formulated his question as “When to rewrite a code base from scratch?” and some of the answers were pretty good.

If it ain’t broken don’t fix it

The most popular answer was submitted by Matt and the gist of that answer is that you should not rewrite working code. Although you may dislike the code, that feeling in and of itself is not a good enough reason to rewrite it.

This answer is very much in line with the thinking presented in an article that was referenced in the original question. If you rewrite code from scratch you risk:

  • Spending time and money on work that was already done
  • Making the same mistakes as last time
  • Making new mistakes this time
  • Having to wait a long time before the new functionality make it into production
  • Putting unused and (at least partially) untested code into production

Modification can be both inefficient and ineffective

A bit further down a less popular but nontheless great answer was submitted by swamplord. This time the answer is based on a quote from the book Facts and Fallacies of Software Engineering:

Modification of reused code is particularly error-prone. If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to rewrite it from scratch.

Statistical analysis of a number of projects show that if you need to revise too much of the code (what “too much” is may vary) it simply isn’t worth the time and effort.

This certainly rings true to me. If you have to change too much of the code it will not save time. Also, if you need to change so much the code might not have worked so well to begin with. If there is a lot of defects (a.k.a. bugs) in the code you might want to be particularly careful. Jeff Atwood warns that not all bugs should be fixed and advices to use a triage approach. The main reason is that in fixing bugs you at the same time risk introducing new bugs.

How to think about it

The factors above are important before deciding to go for a rewrite or instead modifying the code, but some other factors apply too. Here is a condensed piece of advice that sums up how I think about it:

Modify the code if the code works, less than 15% of the code must be revised, the code has good test coverage, you have persons with good knowledge on the codebase on your team.

Rewrite the code if the code has significant defects, more than 20% of the code must be revised, the code is poorly tested, noboby you work with have deep knowledge on the codebase.

Beware if many other systems already have formed dependencies on the code or the system/component you are working on. You also need to beware of huge code bases. In these cases both rewriting and modifying the code might seem like a bad idea and you need to thread very carefully.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: