A recent, short article on O’Reilly.com, Before You Refactor suggests that if you think you need to rewrite code, you must proceed with caution, do cost-benefit analysis and so on. If you’re still convinced then, at the very least, make the changes in small increments, reusing as much of the existing code, and tests, as possible.

The problem with instilling a sense of fear, or at least extreme caution, around refactoring is that while it works in the short term, it causes bigger problems in the long term because it encourages developers to make changes in the least disruptive way possible. Over time, this approach makes it harder to add new features to the code base. This, in turn, makes it slower for the team to move the software forward in response to new technology or changing customer demands. Eventually someone starting from scratch will have an advantage over you in being able to implement a feature that customers want, but which in your existing code base requires too large a change to be possible. In short, if old code is getting in the way of new features, then it’s actively bad for the product. Someone without that code has an advantage over you.

Instead, developers should be encouraged to make refactoring a continuous process of small incremental changes, always leaving the code in a better state than they found it (the Boy Scout rule), and removing obstacles to adding new functionality. The key to good refactoring is to resist the temptation to change existing code until it is necessary in order to both implement a new feature and add momentum. If old code isn’t getting in the way of adding new features, then changing it won’t add momentum to a product. If you don’t plan to add any new features, then it doesn’t matter how ugly the code is so long as it works.

The author, correctly, points out the dangers of ‘rewriting’ code without fully understanding its current strengths and weaknesses, and in many ways the article might have been better titled “Before You Rewrite” i.e. make a large and fundamental change to the way software works. However, there are many valid reasons to rewrite, such as reacting to new business requirements or drastic changes in usage patterns and workload. In general, you would not, as the author suggests, do such changes incrementally. Although the author argues that new technology is not usually a good reason to rewrite, it can be if, for example, you can no longer hire programmers to maintain an aging system. Another good reason is to retain developers’ cutting edge.

As Phil Factor is fond of saying, with a mischievous grin, the problem with source control is that it’s made it much harder to jettison the original source. Source control can engender in the developers a reverence for the source code that it sometimes doesn’t deserve. While refactoring is a good practice, sometimes you really do need to rip things up and start again. Sometimes, the source code doesn’t warrant the elaborate precautions we make for its preservation.