Instead of refactoring as a separate activity, the method I advocate is to apportion some part of each new feature implementation to refactoring the part of the system that is being modified for the new feature. This approach provides many benefits:
- You are far more likely to succeed in convincing management to accept a slight delay in a new feature implementation than to halt new development for refactoring.
- In some cases refactoring can actually speed the implementation of a new feature by eliminating the structural awkwardness and reducing bugs.
- The overhead for the design, coding, and testing of the refactoring effort is reduced, as elements of all these activities must be done for the new feature regardless. Refactoring simply adds an incremental level of effort into these activities.
Combining the two processes also allows us to combat one of the largest morale issues faced by programmers supporting existing systems: The Boredom Effect.
The Boredom Effect
Programmers consider supporting existing systems a very poor cousin to rolling out a new system. The daily routine of supporting systems seems to consist of wading through hundreds or thousands of lines of other people's code and making slight patches to effect fixes or new features. Without the ability to refactor, the support programmer sees his future as living with inelegant and rough code that he has no chance of fixing. No glory is attached to those finding themselves stuck with this unenviable task.
Rolling out a new system, with the attendant design activities and exposure to new technology, is considered the better place to be. Of course this is exactly contrary to what the business really needs. The business needs long lasting systems, not frequent system replacements!
Allowing programmers to fix what they find wrong as they work can be a great motivator, increasing job satisfaction and morale. Over time, as support programmers modify the current system, they will come to identify closely with it and take pride in their accomplishments.
But how much refactoring can you reasonably expect to do as part of a new feature implementation?
Choosing What to Refactor
In choosing to refactor as part of a regular implementation of new features, the largest part of the decision-makingwhat scope the refactoring effort should takehas already been made. The refactoring is limited to the parts of the system that relate to new features being designed. But within this definition, there is room to maneuver.
Generally, when choosing what to refactor you need to weigh the following issues.
- What is the amount of additional time added to the project due to the refactoring?
- How great is the risk that the refactoring will produce a bug in the existing system?
- How much "stress" will be released by the refactoring effort?