Refactor or Rewrite?

by Vikas Hazrati on Nov 24, 2009 |

The goal of refactoring and rewriting is, to improve the sanity of the system by improving the code readability, structure and clarity. A clean code would be easier to maintain and enhance. However, on many occasions Agile teams have a tough time deciding between the two.

Michael Dubakov suggested the following reasons for the code base getting worse over time,

More and more features. It leads to increased complexity.

Shortcuts and hacks to support “We need this fancy search till August. Period!” features

Developers rotation. New developers don’t know all the fundamental decisions and ideas behind the architecture. Knowledge gets lost with transition inevitably.

Development team growth. More people - less communication. Less communication - bad decisions.

Michael suggested that, though refactoring and rewrite might lead to cleaner code however, both the techniques bring chaos to the existing system. Refactoring is an incremental activity hence it touches some portion of the system at a time. This creates chaos at local levels and might be easy to contain. Rewrite on the other hand is a more invasive change and results in a bigger chaos in the system. Due to the wider impact, the stabilization period of a rewrite is much longer than that of refactoring.

We have the old system during rewrite, so chaos is constant. After the public release chaos increases significantly. Quite many new (and old) bugs and quirks are expected, so stabilization period is longer.

Peter Schuh suggested that often teams use the words interchangeably there by resulting in more confusion and chaos. Teams should understand that rewriting is riskier proposition as compared to refactoring and hence should use the terminology accordingly. According to him,

It’s just semantics. Well … it’s only semantics until someone gets hurt. Rewriting code is a risky and sometimes painful endeavor. It doesn’t always end well. If we execute a rewrite but call it a refactor and the whole thing goes pear-shaped, no business person is going to stop and think about semantics. They’re just going to cringe the next time they hear the word refactor.

Guido A.J. Stevens made an interesting observation. He suggested that the question is not between refactoring and rewriting but it is between either: refactor, or else: rewrite AND refactor. He suggested that even when a team decides to rewrite the system they would eventually have two systems running in parallel. The old system which would require refactoring and the new system which is being rewritten. The combination becomes an overly complex task. According to him,

Maintaining an aging code base, AND writing a new system, is going to be a huge drain on your resources. Your team is split and will run into delays. You'll have to plan and carefully execute a transition. Meanwhile, your competitors don't have your time-to-market problem and will try to steal your customers. If you can stare this reality in the eye and still want to bet the firm on a rewrite, you may have a chance of succeeding.

Naresh Jain had the following suggestions specifically for legacy code. Refactor when the code is difficult to understand and the team is not sure of what it does. Rewrite when it is clear what the code does but it is difficult to understand.

Thus, refactoring is the preferred way to incrementally improve the system. It is slow paced, improves quality with small and constant improvement. Rewrite has its advantages however, in most situations it is a riskier option and the teams can never be sure about the outcome. As Joel on Software suggested,

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

Related Editorial

Agile workshops and training

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

Infographic: Just How Big is the Nerd Economy

Application Performance Management Buyer's Guide

Agile Maturity Model Applied to Building and Releasing Software

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Business To know technology by Senthil Kumar Vaithilingam Posted

Re: Business To know technology by Mark Lawler Posted

One rewriting can be done by multiple refactoring by Zhang Joey Posted

Re: One rewriting can be done by multiple refactoring by Salah LAARIDH Posted

Re: One rewriting can be done by multiple refactoring by Roy Donasco Posted

Business pressure can lead to bad code by Salah LAARIDH Posted

Good arguments against the great rewrite. by Alen Milkovic Posted

Software development and entropy... by SSSSS RRRRR Posted

RE::Refactor and rewrite: by Shubhashish Bhowmik Posted

Re: RE::Refactor and rewrite: by Roy Donasco Posted

Business To know technology by Senthil Kumar Vaithilingam

In growing trend of Technology being the back bone in most of the buiness companies, in the same way technical people need to know the business, I see a demand for business people knowing the technology becomes imperative. So some of the design practices we use like refactoring, eventhough it goes not have any meaning to business, but I think that keep system little more stable and reliable than before. So we need to cross train business people to understand some of the technical/design methodologies we use. Those days of clear separation is fading way...Collaboration with overall system knowledge is becoming mandatory for successful launch.....

Re: Business To know technology by Mark Lawler

Interesting piece. Thanks. I'm wondering how many have seen this movie before in prior lives? Team demands that they have to rewrite and gets approval to do so. Months in to the project they begin to realize how high they've jumped from and they are without a parachute. Due to market pressures the product needs to be released to drive sales, revenue, or to stay competitive yet they are still rewriting plumbing and many of the core features in the product still haven't been added back in let alone any of the new desired features. With time running out before they hit the ground with a rather large splat they have no choice but to reach for the reserve chute...they resurrect the old code that worked, refactor a few key bits, and make their commitment... Nobody is happy. I've seen this movie at least 4 times (unfortunately once on my watch many, many years ago) and it always seems to end the same. Just sayin'. ;o)

One rewriting can be done by multiple refactoring by Zhang Joey

Now, I'm leading the refactoring of a on-line application, whose code hasn't been cleaned for more than two years. Actually, I cannot help myself to consider to rewrite it at all, but finally I decide to control my step and divide the whole process into several rounds of local refactoring, and now the first one has been finished. It is more practical for me to collect resource and persude the business peoples that the risk is under control.

Business pressure can lead to bad code by Salah LAARIDH

I think that the following reasons will lead also for getting worse code over time:
- Misidentifying requirements / Changing of requirements frequently.
- The pressure made by the business (the owner of the application) to have something that works. In this case the first worries of the team will be delivering as soon as possible which will lead to a completely ignoring of code quality.

Re: One rewriting can be done by multiple refactoring by Salah LAARIDH

I'm totally agreed with you, I’m using the same approach as you. It’s very interesting, I did not find it very hard to convince my business to use this approach to improve our code and our delivering.

Good arguments against the great rewrite. by Alen Milkovic

Still, sometimes you must switch platform for some reason. Then you have to rewrite. If possible it is best to split up the code into pieces to be able to port a part of the time to better deal with the problem of concurrent development (old+new). The thing that people don't always think about is that there are some things one should take with them from the old crappy code. The general flow/organization of the old code. There can be some important solutions and bug fixes that one can reintroduce. Sometimes the general flow of pages/screens/object can be good enough even if one doesn't understand the code and it is this that takes up a lot of time when coding.

Nice article, I am only missing some good arguments for the other side. Do they even exist?

Software development and entropy... by SSSSS RRRRR

I am big fan of refactoring but it's not the panacea.

Refactoring is incremental, therefore it is a linear process. Unfortunately, the development of software systems is far from being linear. It is actually quite non-linear and that means that some (bad) changes in the code are potentially irreversible (or would be ultra costly). The physic guys call it entropy: when the paste is out of the toothpaste tube, you will have a hard time putting it back in that same tube. In a system, the higher the entropy, the most likely you will be able to "simply" refactor.

On Joel's note "It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.", two things:

1) Between developing a system with a defined set of features in 2004 and developing a system with this same set of features in 2009, there is going to be probably at least a 50% productivity advantage for the latter. Why? simply because software is one of the most efficient industries in terms of productivity gains each year (who spend time to write SQL code manually besides DBA nowadays?).

2) There is something else called the "experience curve effect". It says that the more you perform a task, the more efficient you get for that task. Even though this effect has been demonstrated for manufacturing, I also think it is very meaningful in the software development industry.

Rewrite has its place for some situations, and it is not completely stupid! :)

RE::Refactor and rewrite: by Shubhashish Bhowmik

Sometimes, refactor and rewrite has become an ordeal, even more for those who are proposing the Re factor or Rewrite suggestion. Other dev guys often think that there logic is being tormented into pieces(funny isn't it !). Even sometime you will find a file of 1000 LOC where more 500LOC are commented; reason, they can be used in latter part of the project.

Of course, if proper code reviews has been done then probably the situation called "rewrite" wont arrive and if it does then probably for advancement of certain components or new technology.

Re: One rewriting can be done by multiple refactoring by Roy Donasco

I agree with your approach. Incremental steps offers less risk than re-writing the whole application. It is very important especially for software product that is already out in the market.

Re: RE::Refactor and rewrite: by Roy Donasco

Sometimes, refactor and rewrite has become an ordeal, even more for those who are proposing the Re factor or Rewrite suggestion. Other dev guys often think that there logic is being tormented into pieces(funny isn't it !). Even sometime you will find a file of 1000 LOC where more 500LOC are commented; reason, they can be used in latter part of the project.

Of course, if proper code reviews has been done then probably the situation called "rewrite" wont arrive and if it does then probably for advancement of certain components or new technology.

Code reviews are ideal, but let's face it, ideal situations are very rare, especially if you're tasked to improve a Java code written 10 years ago when design patterns and framework does not exist yet, and public and static modifier are abused.