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 negative?

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.