Modular rewrites of existing codebases are often recipes for disaster.
Posted on Monday, March 30, 2009 at 11:55 AM.Today I read an article that discusses the risks of rewriting poor codebases rather than trying to refactor them. It also gives some advice regarding how to go about performing a rewrite of a software system, at one point suggesting that:
If we do take the path of rebuilding, what are some things we can do in order to help ease the pain. First bit of advice is DO NOT LEVEL the program. Try to break off parts are going to be rebuilt and do it one at a time. Isolating these components gives you the chance to utilize unit testing, which is one of the most important tools you have when refactoring.
I've seen this approach used with a variety of systems over the years, and I'm not convinced it's a good idea. Nor do I think that it can necessarily be considered a "rewrite" per se, but instead more an example of large-scale refactoring.
The main problem is that the portion of code to be rewritten (ie. the "module") tends to be small compared to the entire codebase. Given that the software's quality is currently poor, it's unlikely that the code is naturally very modular to begin with. So even if we isolate our rewrite to a limited portion of the code, it's likely that it'll still perform data access like the rest of the code, obtain configuration setting values like the rest of the code, and so forth.
So what we find is that we want to do things "better" in our rewritten code, but we still need to remain somewhat interoperable with the existing code, databases, RPC services, Web services, and so forth. So if we choose to use the existing components, we're often forced into following their "mindset" and way of behavior, which ends up limiting the improvements we can make with the rewrite. On the other hand, if we start from scratch, the amount of work will likely increase significantly. We might also end up with code duplication between the old code and the new code, which can just make the codebase as a whole much more difficult to work with. If several teams perform such partial rewrites, we can potentially end up with five or more ways of performing the same basic tasks.
If it's decided that a rewrite is to be performed, it's often better just to go ahead and do it in full, rather than trying to piecemeal it using the existing code. The piecemeal approach often handicaps the new code, which can lead to a more confusing codebase rife with duplication, contradiction, outdated approaches and interoperability hacks.








