This is the first in a series of articles, discussing why
  many software rewrite projects end badly and what
  to do to avoid some of the ways I've seen them go astray.

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

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.).

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

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.

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

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.

Why So Hard?

So, why, in software rewrites, when you’re traversing exclusively
familiar territory are the results so often unpredictable and

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:

Stay tuned.