Conversations such as "Oh, this is such a cluttered design", "This software has high technical debt", and "What a complex piece of code!" may lead to exchanges such as "Can't we do something about this?", "Why can't we scrap this?", and "Can refactoring make it better?" Essentially, the discussion boils down to the famous dilemma "Refactor or re-write". Let's take a closer look at the dilemma and a few factors that impact the dilemma.

1. Refactor vs. Rewrite
Ganesh Samarthyam, Tushar Sharma, Girish Suryanarayana
REFACTOR VS REWRITE WWW.DESIGNSMELLS.COM

2. Refactor vs. Rewrite
Conversations such as "Oh, this is such a cluttered design", "This software has high
technical debt", and "What a complex piece of code!" may lead to exchanges such as "Can't
we do something about this?", "Why can't we scrap this?", and "Can refactoring make it
better?" Essentially, the discussion boils down to the famous dilemma "Refactor or re-
write". Let's take a closer look at the dilemma and a few factors that impact the dilemma.
When it takes more time and effort than genuinely required to fix a bug or introduce
a new feature in the software due to high technical debt (including high complexity,
tightly coupled design, and so on), the software becomes difficult to maintain. In extreme
conditions, making each change in the software becomes a painful nightmare. In such
situations, the dilemma "refactor or re-write" may capture the attention of project
stakeholders.
History has taught us that "re-write" from scratch could be strategically dangerous
for the product and the company. Joel [1] has pointed out many such mistakes; some of
them are:
Netscape released version 6 during year 2000 after three years they released version
4 and yes, there were no version 5. Why? Because, the company decided to develop the
software from scratch! It took three years for them to do it by that time they lost the
market.
Borland bought Arago to make dBase for Windows but started the development
from the scratch; before they can make to the market, MS Access captured the market. All
REFACTOR VS REWRITE WWW.DESIGNSMELLS.COM

3. of the above cases highlight strategic mistakes of these companies that wiped their market
share. Thus the "Risk of losing the market" is indeed a significant factor to consider when
the question (i.e. "Refactor or re-write") is posed. In this context, Refactoring could be
favored since the product is always market-ready and refactoring can consistently
improve the quality to sustain the product for a longer period.
If you think that the old software is a complete waste that doesn't deliver any value
then think again. The old huge legacy software was maintained by your company for so
long and in this duration the project team has fixed numerous bugs aroused in different
client conditions. In summary, the same piece of crap has accumulated huge knowledge
and experience which is difficult (if not impossible) to introduce at once in a software
developed from scratch. Again, from this dimension, refactoring option is fruitful
alternative to retain and exploit the knowledge captured by the old software.
Does it mean we should always opt for refactoring over re-write? Well..No. There is
at least one case when it is desirable to go for re-write. When it becomes difficult to
maintain old software technologically (difficult to get compatible hardware, software, or
people who can run the show) since the used technology is obsolete while management of
the product foresee a relatively long life for the product then re-write could be an option.
However, while opting re-write, the risk associated with first two factors must be
addressed; for instance, the management could decide to develop the new product from
scratch with new technology without removing the old product from the market.
Microsoft did the same once when they started developing Word from scratch under the
project code name Pyramid. Although, the project Pyramid was a disaster but the parallel
development saved Microsoft from losing the market.
References:
[1]
Joel
Spolsky,
"Things
you
should
never
do,
Part
I"
About
the
Authors:
Ganesh
Samarthyam
(sgganesh@gmail.com)
is
an
Independent
Consultant
and
Corporate
Trainer
based
in
Bangalore.
Tushar
Sharma
(000.tushar@gmail.com)
is
a
Technical
Expert
at
Research
and
Technology
Centre,
Siemens
Technologies
and
Services
Pvt.
Ltd.,
Bangalore.
Girish
Suryanarayana
(girish.suryanarayana@gmail.com)
is
a
Senior
Research
Scientist
at
Research
and
Technology
Centre,
Siemens
Technologies
and
Services
Pvt.
Ltd.,
Bangalore.
REFACTOR VS REWRITE WWW.DESIGNSMELLS.COM