If You Must Rewrite

As a general rule, you should never rewrite your software. I have (barely) survived several rewrites in the past and they all shared the same horrible experience:

• The rewrite took much longer than expected, during which time the business stood still while the market moved on.
• Functionality written over several years had to be re-implemented in a fraction of the time.
• The development team was immediately pressured to “get it done”. This created a sense of always being behind schedule.
• The business became frustrated and could not understand why it was taking so long.
• The rewrite provided little or no new functionality to the business.
• There were hidden business rules that had been long forgotten and no one knew what they meant.
• The old system could not be turned off until all the features were migrated to the new system.
• The old system still had to be maintained while the new system was under development.

There has been plenty written about the problems with software rewrites. Here are some great articles on the subject:

• Things You Should Never Do – Joel Spolsky.
• Why You Should (Almost) Never Rewrite Your Software – Dharmesh Shah.
• How To Survive a Software Rewrite – James Shore.
• The Big Rewrite – Chad Fowler.
• The Big Redesign in the Sky – “Uncle” Bob Martin.

The general consensus from each of these articles is to never rewrite software unless you really have to.

So when do you really have to rewrite? I mean reeeeaaally have to. Well, there are times when a rewrite is completely unavoidable. In one such case I came across recently, the company no longer had access to the source code of their core product. That’s a pretty tough position to be in and a rewrite is pretty much the only option for moving forward.

So, here are a few retrospective tips from my experience enduring rewrites. This is not a prescriptive list and is only meant to represent ideas that might have helped in the cases I was involved in.

The rewrite will always take longer than you think. Be prepared for a lot of work. An effective strategy is crucial – time spent rewriting the system is time lost from adding new features to grow the business.

Involve the product owner. They will be eager to complete the rewrite as it is costing them money to re-implement functionality they already have. Have them on-hand to prioritise features and answer questions. Keep them aware of progress.

Identify the core set of features the business can not function without. Focus on these features and plan to release as soon as you have a minimum feature set.

Prioritise the features. Ensure you are always working on the highest-priority feature.

Limit work in progress. Don’t try to re-implement everything at once. Complete a feature before moving onto the next.

Don’t rewrite everything. Be harsh – throw out anything you don’t absolutely need. Remember, every feature you rewrite costs adding a new feature that could grow the business.

Simplify your business processes. Use this as an opportunity to refine and simplify your existing business processes. Don’t just re-implement a feature because “that’s how it works in the old system”.

Use a well-known, established technology. Don’t be tempted to use the latest and greatest just because you get to start over. Speed is the key here, you don’t want to be thrashing with an unfamiliar technology.

Release as soon as possible, but not a moment sooner. Your current customers won’t be happy if the new system doesn’t function correctly or important features are missing.

Migrate existing data early. Don’t leave data migration to the last minute. You need to know your new system can work with the data you currently have. I was once involved in a rewrite where the migration happened at the last minute – the entire system failed to function and we lost more time rewriting parts to improve performance.

Implement whole features at a time. Don’t focus on horizontal layers of the application, e.g. database layer, services, UI, etc.

If you can, replace parts of your system at a time. If you can rewrite parts of the new system that integrate the old system, then you can stagger the rewrite and release sooner.

Use off-the-shelf software. If you have a generic feature, such as a forum or CMS, consider using a commercial or open-source alternative to avoid reinventing the wheel.

Don’t create a mess. Write adequate tests. The only way to go fast is to go well. Buggy software will cost more time and money, even in the short-term.