Refactor or Rewrite

Problems happens all the time, during planing, development or maintenance phases. As deadlines get tighter during final development and maintenance phases and it's quite common to take the easy path. In the beginning, small hacks can be done without much hassle, a small comment is then added to explain the hack and the developer decides to do it properly later.

But with a tight schedule, chances are that the developer won't look at it too soon and all small hacks done (sometimes commented, some times too obvious to comment) will linger even during maintenance phase. The developer then, will start other projects, move on to another team or even leave the institute and the context of each hack will be lost forever.

With time, new developers will have to maintain the code and without the knowledge of the whole they won't be able to define the context and how to refactor the hack and will be forced to increase the hack or add another layer of hacks on top of it. The uglier the hack, the longer its life for the more difficult it'll be to put the hack in context and refactor it later.

After a while in this path, a whole legion of scripts, will appear around the program. Scripts to prepare the input data that the program cannot parse correctly and no one knows how to fix it, scripts to restart the program when it breaks for no apparent reason, scripts that will parse the logs and re-catalog the failed entries to re-run the program with them in a different way and so on.

This new layer will become part of the program itself as standard procedure and lots of documentation will be written about it, how to run it and understand the error messages of the scripts when reading the error messages of the program. With time, developers will stop worrying about the program because it'll be too far away from day-to-day reality and the problems will be in the scripts for the newcomers.

New developers will then start writing wrappers for the scripts and a new cycle will start. The more you wait to properly fix the program or even re-write it from scratch, more layers of scripts will be added, more clutter will have to be maintained and the bigger the workaround layer will be.

Brand new projects are easy to refactor. All the architecture is in the developers' minds, no one is using the software, you can do virtually whatever you want to make the program better. There are some deadlines and milestones, of course but still, time micro-management is up to the developer.

There is a common misconception that the time and amount of changes implied by the refactoring will increase the development time, and that's the root of the first workarounds. If you see development time as the time required to launch the first demo, yes that's probably true, but actually, development time should be consider as the time until it reaches production, also know as time to market, and that can be considerably reduced by refactoring.

No matter which development style you do (RUP, XP etc), you always have a few milestones leading to a beta leading to production in a way or another. When good practices are mandatory since the birth of the project, the time to a beta version can be longer than expected but the time between beta and production is reduced to a minimum. The last phase becomes much more of sharpening the edges than fixing the numerous bugs and workarounds created which is much more demanding than the former.

In maintenance the matter is different. It's much more difficult to refactor when fixing bugs than when designing the system, you normally don't know the system well as the original coder, you don't know the whole context the program runs and how many people or teams are using it that way it is: broken. If you fix a bug you might be inserting new bugs on other teams' procedures, and because the other teams' coders changed too, not you nor them will ever know.

Nevertheless, refactoring is not an option, make it mandatory for yourself. Whenever you feel tempted to workaround, stop, think and refactor. Always remember, the less you work now, the more you'll work tomorrow and vice-versa.

A special note for maintenance: the beginning will seem impossible, carry on, do smaller refactorings and let the hard bit untouched. As you feel confident, go and try something more complicated and with time you'll see that the big monsters of the past are actually small hacks that could even be deleted as it's completely redundant now in your high-quality infra-structure.

Rewrite is a very easy decision but a hard job. Another common misconception that rewriting will set you free of all the bugs the old code had, you can do whatever you want while the old program is still running, do it your way, much better than before.

The problems arise when you forget the fact that the old program already fixed several bugs that you'll have to fix it yourself, solved many problems that you don't even know that exist (especially with bad documentation) and because of the enthusiasm, you'll end up with your own set of workarounds and hacks and start all over again. Worse, because of design decisions, your program will be bad for things the older was good (and vice-versa) because you'll focus on the old program's problems instead of the problems the old program was trying to solve.

Not to mention you'll have to maintain the old code until your own go to production and if the code is as bad as you thought it was (thus your need to rewrite) you'll have two tough jobs when you originally planned a nice and clean program. The time constraints you'll create yourself to finish the new program (you'll be so full of fixing the old program that your priorities will change) will force you even more to add workarounds and big hacks to push it to production as fast as you can, and the result will be very likely much worse than the original. Don't panic if the users actually ask you to go back using the old library or if you hear comments about how crap is the new library.

Rewriting is a solution, however, when you have complete knowledge of the realm you're in, have refactored the program to the extents of possibility and reached a major design flaw impossible to be refactored. Real impossibility is never an issue, everything is possible, but sometimes the refactor will be worse than the current situation in terms of maintenance, performance or stability. For instance, in order to achieve the desired performance you have to pay a huge price in maintainability making the refactor a seamless move.

The other problem with rewriting is that you must assure that the old program will be fully functional during your new development and that means no bugs or incorrect results, so the fundamental about rewriting is never rewrite to solve bugs but to achieve the desired performance, stability and maintainability incapacitated by the former design. Thus, rewriting is not a matter of fixing programs but of achieving the required quality for your software.