Stop! Rewriting is almost never the answer. More often than not, refactoring is a better bet.

Of course, there are times when a rewrite is worthwhile:

• Switching to a new platform where migration tools don't exist (or can't be written cheaply enough).
• When the application to be rewritten is trivial.
• When the source code for the original application is lost, and recovery is more expensive than rewriting.

Stop! Rewriting is almost never the answer. More often than not, refactoring is a better bet.

Of course, there are times when a rewrite is justified:

• You're switching to a new platform where migration tools don't exist (or can't be written cheaply enough).
• The application to be rewritten is trivial.
• Source code for the original application is lost, and recovery is more expensive than rewriting.
• The vast majority of the business rules encapsulated by the existing application no longer apply.
• There are few active users of the existing code.
• You have the resource (time, talent and tools) to undertake the rewrite.
• The existing application cannot be run in a production environment, for legal or practical reasons.

To understand why I recommend refactoring over rewriting, consider what is involved in a rewrite. You must:

1. Understand the nuances of what the existing application does. This is not usually trivial when you take in to account all the subtle business rules that it encapsulates, the environment (both human and technical) in which it operates and the advantages and disadvantages of the current solution. More often than not, the only place that this information exists (if anywhere) is in the source code of the existing application. It is unfortunate that one of the main reasons for performing a rewrite is that existing code is difficult to understand and maintain.

2. Reproduce this functionality (or an updated version of it) in a new application that is tested and reliable. Existing code may not be understood by developers, but is typically well understood by its users. It may not meet their current business needs, but they can at least tell you what the application does under various circumstances.

Big advantages of refactoring are that:

• You can take things one small piece at a time.
• Any changes can be tested in the context of the existing, working application.
• Hypotheses about the way the existing code works can be tested by making small changes and observing what happens.
• Changes can often be delivered to users in phases rather than all at once.
• Learning from early stages of refactoring can inform later stages of the refactoring.
• If you abandon the process part way through, there will still be benefits in terms of a cleaner code base (as opposed to a rewrite that must be completed to offer any benefits to the user or developers).

Remember, too, that if you do a rewrite you are guaranteed to introduce lots of new bugs and mess into the new code base.

Stop! Re-writing is almost never the answer. More often than not, refactoring is a better bet.

Stop! Rewriting is almost never the answer. More often than not, refactoring is a better bet.

Of course, there are times when a rewrite is worthwhile:

• Switching to a new platform where migration tools don't exist (or can't be written cheaply enough).
• When the application to be rewritten is trivial.
• When the source code for the original application is lost, and recovery is more expensive than rewriting.