Sometimes you will come across a codebase/application that looks in such a mess or so old that the only option is to do a full rewrite. The code is horrible and out of date, it’s using an old version of a language/framework and everyone has forgotten how it works. Everyone agrees it will be much faster to just throw it away and start again.
This seems to be how so many software projects start. Over my career, I know that I’ve been heard to say those very things myself. It’s seductive, we all love a nice greenfield project and the big rewrite is the easiest way to turn a boring, difficult brownfield project into something everyone wants to work on.
The hard truth is that I can only think of one (smallish) rewrite that I’ve worked on that could be classed as success and that company is no longer around (but I don’t think the two things were related). More often than not, after we’ve finished the project (late, normally very late) our first thoughts are ‘Now if we could just have just another 2 months we could rewrite it from scratch (again) it would be so much better”. Unsurprisingly most businesses don’t respond overly positively to those sorts of requests!
Now when we’re considering a re-write I’m trying very hard to work to the following process:
- Estimate how long the legacy application will take to refactor to the desired quality/level of maintainability. At this point, double that estimate and if the business can afford that amount of time, then you’re good to go with the full rewrite (over the refactoring). Of course, you might ship the first version faster than that, but we all know that it’s about version 3.0 that we get the desired functionality, stability and performance – rewrites generally aren’t any different.
- When there just doesn’t seem to be any way to refactor an application, you’ve not looked hard enough. Go back to the drawing board and try again. Maybe the UI needs to be rewritten as you’re moving from a technology that is no longer supported, but the business/domain logic can probably be reused. If that needs to be rewritten, do that in a later project in smaller chunks. Sure, it may take a while but do your estimates for the refactor approach and refer back to the first point.
If you’re still not convinced (you might have to live the disappointment of seeing what a v1.0 of a rewrite looks like), then the additional benefits of the refactor approach are:
- The only functionality missing from the final application will be depreciated functionality that the business agrees is no longer needed.
- It should be possible to ship the application incrementally through-out the refactoring. If it’s not, are you sure you’re not just doing a re-write?
- Development of new features doesn’t need to stop, it can continue alongside the refactoring or even get included in the refactoring process itself. Maybe changing the functionality first will make the later refactoring easier, or the refactoring can be targeted in a way to make the later change of functionality easier.
So, taking all that into account, who would ever consider a rewrite again? Now back to application I need to maintain, I’m sure it doesn’t do much and I could easily replace it before I’ve even finished understanding what all that horrible, cluttered code in the original application actually does. I hear all the cool kids are playing with ‘Rust’ these days and it would be good to see what the Google Cloud platform is like for hosting…….
The first step to solving technical debt has to be for the business and technical teams to have a common, agreed direction for the product(s). To determine the right direction, the team will need a ‘map’ – this is generally the company vision, which should come from the senior management team/board. Only with a clear direction to measure their progress against, can they be sure that they’re all aligned and how far along the path . . .