davidbgk
/
larlet-fr-david-cache

title: The Big Rewrite
url: http://chadfowler.com/2006/12/27/the-big-rewrite.html
hash_url: e1911ccf82335e72f78e6e6328c01cf3

<p>You’ve got an existing, successful software product. You’ve hit<br/>
the ceiling on extensibility and maintainability. Your project platform
is<br/>
inflexible, and your application is a software house of cards that<br/>
can’t support another new feature.</p>

<p>
You’ve seen the videos, the weblog posts and the hype, and
you’ve decided you’re going to re-implement your product in
Rails (or Java, or .NET, or Erlang, etc.).

</p>
<p>
Beware. This is a longer, harder, more failure-prone path than you
expect.

</p>
<p>
Throughout my career in software development, I’ve been involved in
Big Rewrite after Big Rewrite. I suspect it’s because I have an
interest in learning eclectic computer languages, operating systems,
and
development environments. Not being just-a-Java-guy or
just-a-Windows-guy
has led to me becoming a serial rewriter. I’ve been on projects to
replace C, COBOL, PHP, Visual Basic, Perl, PLSQL, VBX (don’t ask!)
and all manner of architectural atrocities with the latest and
greatest
technology of the day.

</p>
<p>
In many cases, these Big Rewrite projects have resulted in unhappy
customers, political battles, missed deadlines, and sometimes complete
failure to deliver. In <em>all</em> cases, the projects were
considerably
harder than the projects’ initiators ever thought they would be.

</p>
<p>
This is not a technology problem. It’s not at all Rails-specific, but
being in the limelight these days, Rails implementations are both very
likely to happen and very risky right now.

</p>
<h2>
Why So Hard?

</h2>
<p>
So, why, in software rewrites, when you’re traversing exclusively
<em>familiar</em> territory are the results so often unpredictable and
negative?

</p>
<p>
For the next week, I’ll post specific reasons I’ve seen things
go wrong. The following is a list which will eventually be made into
links:

</p>

<p>
Stay tuned.

</p>