
Refactoring vs. Rewrite - fogus
http://www.targetprocess.com/blog/2009/11/refactoring-vs-rewrite.html
======
richardw
Joel wrote an article back in 2000 on why you should never rewrite, mentioning
Netscape. While I'm far less sure than he is about it (see below), there are
some awesome points in there.
<http://www.joelonsoftware.com/articles/fog0000000069.html>

While rewriting I've often been surprised how much I've had to re-discover and
re-think, and how many mistakes I'll make second time around. On the other
hand, on one occasion a rewrite saved the day because it pulled together 5
different apps in different languages in a new up-do-date platform. A few
months of work and the sum was infinitely better than the whole and saved the
business much more than it cost.

~~~
btilly
On the flip side during an extended major refactor your code looks like a
construction site. You have some stuff that has been rewritten, some that
hasn't, and no consistency. Then during the refactor people will rethink how
they want it written, and you get more code styles.

Frequently the dust and mess gets so discouraging that people start being
driven away. And then the rewriting effort peters out and people just get used
to living in a half-demolished house.

The moral? Keep refactors small. If you want to do a major redesign, I would
suggest rewriting a small prototype of a piece of it. If the prototype goes
well then expand it until it can replace the previous system. (I've seen this
prototype approach succeed several times. I haven't seen such good results
with major refactors, or the "Let's rewrite from scratch!" approach.)

~~~
firefalcon
I also don't think that full rewrite from scratch is a viable strategy. Much
better is to rewrite by pieces and integrate them with existing system via
interfaces/adapters/etc. For example, you may start new Data Layer and move
code from old app to it slowly, but constantly. Sometime you will have
completely new DL.

~~~
btilly
Believe it or not I have seen multiple people succeed with a full rewrite from
scratch. The ones I have been close to did it with a prototype they evolved.

------
by
I like the boy scout principle of "Leave the campground cleaner than you found
it."

<http://www.moserware.com/2008/10/boy-scout-check-ins.html>

With all the maintainers doing this at the code, database and design level you
shouldn't need to do a rewrite.

The problem is with 'immovable things' that necessarily accrete layer upon
layer of work-arounds. If maintenance work allows 'immovable things' to
persist in the application, at whatever level, the whole structure gradually
degrades and a costly rewrite is eventually forced.

~~~
barrkel
It's not nearly so simple in practice. If your codebase is old and large, and
no one person knows it enough to change significant amounts of it, there are
simply some fixes that you never have the time to risk.

~~~
by
Yes I agree if your 'immovable thing', for example the problem that would need
a risky fix that nobody fully understands, can remain without much impact for
the rest of the application's life.

Sometimes I find I can move towards fixing something difficult in multiple
steps as I apply successive features etc. I find that even just documenting
the problem in the affected parts of the code can be a good first step. If
something changes once it often changes again and I'll move it forward a bit
more next time. My theory is that the movement is the important thing, not the
arrival at some particular point.

------
igrekel
That is very short, the subject has been explored much more deeply in the
past.

I'd suggest Brian Foote's Big ball of mud where he talks about software going
through phases of expansion and consolidation, he also discusses the total
rewrite in much greater lengths. Although it too is lacks hard data and I find
parts of the format and discourse annoying (can't exactly put my finger on
why), I think it is still more interesting.
<http://www.laputan.org/mud/mud.html>

------
einarvollset
"I think we may expect something like.."

This would have been a very interesting article if it was backed by actual
data. It's not. Shame.

------
zyb09
Now I'm the middle of rewriting a good-sized software system. The reason for
this is, we had to a add a completely new security level on top of our data
(user accounts, groups, individual column access).

There's just no way we could've refactored our already tucked-together legacy
code. This thing was passed along 4 different developers, each constantly
adding new features and I'm surprised it hasn't exploded yet.We're getting
calls every day cause something broke again.

So yea sometimes rewrite definitively makes sense and I'm sure our customers
will love it.

------
Quarrelsome
Wild speculation. Love it.

