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:

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.

If you must rewrite…

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.

5 Responses to “If You Must Rewrite”

  1. 1 Eric March 17, 2010 at 1:25 pm

    In other words, treat the rewrite as you would any other real software development project. 🙂

    I agree with you. I’ve had to work through more than a few rewrites in the past couple of years, and their success depended on doing much of what you’ve written above.

  2. 2 Peter Zsoldos March 18, 2010 at 9:19 pm

    Well summarized!

    I’ve found it handy to have a dictionary mapping concepts/actions/data from the legacy system to the new one, in all phases of the projects, but especially after/around go-live. Not all users are involved in the development process, so for them the change happens overnight. Old habits (jargon) are hard to get rid of, not mentioning outdated written instructions, etc.

  3. 3 Fred November 29, 2012 at 1:17 am

    we have a 16-bit Bible program that we would like to have rewritten to work on 64 bit computers there is no rush and we have plenty of time can you help us? If not, do you know someone who might?

  1. 1 The Morning Brew - Chris Alcock » The Morning Brew #561 Trackback on March 17, 2010 at 8:30 am
  2. 2 The software rewrite vs refactor debate: 8 things you need to know - Small Business Programming Trackback on March 26, 2018 at 2:04 pm

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: