Adam @ Bitscribe

No software project can stay healthy over the long run without ongoing refactoring. My off-the-cuff estimate is that you should spend 5 - 10% of development time on any active project refactoring existing code.

But when and where should you refactor? Much as we all hate to admit it, there’s always at least a few dark corners in any codebase that could benefit from a bit of housekeeping. Trying to keep everything spic-and-span absolutely all the time is counterproductive. So it’s important to be able to tell when a refactoring will really be beneficial, as opposed to just setting your obsessive-compulsive developer mind at ease.

The most obvious refactor-needed signal is when you try to add a new feature and find that the module you need to modify needs to be reworked in order to support it.

A less obvious occasion is what Steve McConnell calls error-prone modules. These are the sections of code that just keep breaking. Every bugfix you deploy seems to produce two more bugs a day later. You find yourself getting exasperated when you see a bug report come in for that module, and keep thinking why.. won’t.. this… stop… sucking?

If a module is producing a disproportionate number of defects, that’s when you know something is rotten on the inside. It may just be a matter of tangled code, but more likely it’s a fundamental design issue. Perhaps one object is doing too much, or too much closely0related functionally is spread out among several objects. Maybe the original developer thought they’d be clever by using some language technique or browser feature in a way they weren’t design to be used. Or maybe the functional spec is just too complicated, and the developers need to get together with the product designers and try to come up with a simpler way to achieve the same user goals.

I use the three-times-the-charm rule. One bug - sure, this is software, just fix it. Two bugs in the same area of code - ok sure, fix it that too. Three bugs - dig deeper, it may be time for a refactor.