Lazycoder

The Big Rewrite – Reverse Engineer it

Treat the rewrite as a reverse engineering.

Fowler mentions using the source as the spec as one of the reasons for failing. Trying to reverse engineer an application from the source code is hard. It’s much easier to write code than it is to read it. Instead, write test scripts for the application if none are available. If you are lucky enough to be re-writing the application in the same programming language as the original application, write unit tests for the methods and functions. Document the existing functionality as much as possible. Specify what functionality is vital for the re-write to be considered a success.

The Big Rewrite – Know your tool

If you’re going to rewrite, use a language and framework you are intimately familiar with.

Whenever a new version of a framework or a new language comes along, a programmers first reaction is to use it and see what it can do. This is fine, unless you are using the new framework to re-write. If you are going to undertake something as complex as a re-write, you don’t need your lack of knowledge of the framework or language getting in the way. At least one member of your team should be very familiar with the tool you plan on using during the rewrite. A rewrite is not the correct time to experiment.

The Big Rewrite – Know when to quit

Have a drop dead date. Know when to quit.

This may sound like a bad idea at first, but in my experience you have to know when a project isn’t going well and when to put it out of your misery. You should be able to honestly evaluate your progress during the rewrite and compare it to your goals. Many rewrites turn into death marches. You should document the existing applications functionality. Make a list of what functionality has to be present in the new application for it to be considered a success. If you need to take a phased approach and prioritize the functionality into releases, so be it. In the case of a rewrite, the evaluation needs to start early and happen often. If you get too far out into the weeds, you may feel obligated to keep trudging along on the death march. Ironically, this is what often drives people to keep beating a dead horse rather than attempting a rewrite.

Fear the big rewrite?

Derek Silvers wrote a piece for O’Reilly talking about why he switched CDBaby from Rails back to PHP. Since the article invoked the magic words of “Ruby”, “Rails” and “switch”, thousands of words have been written about his article. Most of them are pointing to Chad Fowlers article “The Big Rewrite” from last year.

Having been through a couple of big rewrites and gearing up to start another one within the year, I thought I’d share a few thoughts on what might cause you to start a big rewrite project and some things that can help you succeed.

Why on earth would you want to do one given that everyone says they never work?

See, the main problem I have with Fowlers original series, and the idea that the big rewrite will always fail, is that it kind of paints us into a corner. A situation where we have to maintain and extend a codebase no matter how hard it is to maintain, how little it satisfies current business requirements, and how outdated the underlying technology.

Sometimes not doing to rewrite is more painful than doing the rewrite. Consider a codebase written in a programming language that isn’t supported by the vendor anymore. Or a codebase written that is such a Jenga puzzle that fixing one reported bug causes 2-3 more reported bugs to appear. Sometimes you may find yourself saying, “fixing this and regression testing the entire system will take more time than re-writing from scratch. Since software estimation is an imprecise science to put it mildly, this is a delicate balancing act that really requires trust in the team members that will be affected by the rewrite and buy in from everyone involved.

Here’s what Giles Bowkett says about the big rewrite:

The Big Rewrite doesn’t work. Incremental rewrites do work … You can fail with Rails and succeed with PHP for reasons that have nothing to do with either language.

Reg Braithwaite says this:

This is because, in my experience, the technical problems in projects are not root causes, they are symptoms of people and management problems.

Both of these quotes point toward non-technical reasons the big rewrite can fail. There are a few technical things to keep in mind when attempting the big re-write. But by an large, the inability to honestly asses your progress during the rewrite is the reason most rewrites, and most software projects in general, fail.