Refactoring seems to be one of those concepts that has been bastardised as is become more mainstream. Turning to Martin Fowler’s Refactoring site, refactoring is defined as:
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
I just finished listening to Refactoring Part 2 from Software Engineering Radio. In this episode they talk about large refactorings, which in my mind seems to imply that you are changing the external behaviour. For a refactoring to become large (ie days or weeks) you really must be changing the behaviour in some way.
Refactoring is a technology process where we identify a smell in the code that either is or will shortly cause the code to become complex and we restructure it to prevent the complexity. In technology we sell this as a low impact process, we now have refactoring tools built into or IDE and we have unit tests to ensure we don’t introduce bugs. If your project gets to the point where anyone other than developers are suggesting refatorings to the code base then I question if what is being asked for is a design change.
External people see this and like to extrapolate that if technology can change the application and there is no impact to the schedule, they can too. I have been in the situation where management has suggested that we refactor in a change, meaning that the change will be quick and won’t impact the schedule. This is a design change it is not a refactoring. If there is a functional change to the application then you are not refactoring your code you are redesigning it. I think is is important that technology protect the concept of refactoring, it is a valuable discipline that allow developers to build quality into what they write.
If we allow the disipline of refactoring to be bastardised we will get to the point where refactoring is seen as the reason projects are ever budget and late not the fact that there was changing requirements and therefore a changing design.