Lazycoder

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.