In any agile environment (and just damn good software engineering in general), refactoring forms (or should form) part of your normal everyday coding. Correcting issues like ‘this-could-be-called-a-better-thing’, or ‘this-is-not-quite-in-the-right-spot’ is usually performed at the quick flick of a button (at least with a nice IDE, and more importantly with a lot of thought). See Fowler’s Bliki for more about Refactoring.

Andy’s blog entry (nice post btw!) and this week at my client site has given me pause to think more about it. Here are my thoughts on this topic:

• Spread the Risk – Although thankful for the chance to get to address a number of things that we have had on our list, I think that doing all of these during the same iteration is a poor business risk management strategy. The great thing about agile is the small iterations and frequent releases allow quicker feedback about changes in the codebase. Normal refactorings and restructurings that occur as part of a normal iteration can usually be identified and isolated from the functional groups of work that go out with each release, making it cheaper and less risky to rollback certain parts if need be. Though a comprehensive test suite (later discussed) helps address some concerns, I see that the compound of so many refactorings (and in particular so many restructurings) is much riskier as each change will be more difficult to identify and isolate.
• Avoid Sending the Wrong Message – Performing refactoring in a week separate from all other concerns sends the business the (wrong) message that this sort of work can be done on its own at any time of convenience. A horrible consequence of this business misperception is that they may then attempt to manage this as one of their normal priorities where it will most likely remain at the bottom of their list.
• Team Communication is as Important as Ever – One of our agile practices on this current project makes a distinction between refactoring and restructuring to avoid the consequences of the infamous late night refactor (ever come in and find all your code was changed overnight?). This practice involves maintaining a list of these issues and ensuring that all developers are involved before work on them is performed. The intention behind this practice is to emphasise the need to communicate changes or to ensure everyone on the project agrees with those changes. Rogue refactoring without any form of communication can only be taken as a form of Teamicide.
• Unit Tests are Your Safety Line – Refactoring is based around making improvements to the code without changing its behaviour. Without a comprehensive unit test suite, I don’t see how anyone can have a high level of confidence or communicate that confidence to others without a comprehensive unit test suite. A better test suite leaves you safer to refactor mercilessly.