Something Alan said a few weeks ago has just bubbled to the surface: there appear to be two main ways that people think about refactoring. I’m going to call them ‘Refactoring’ (big ‘R’) and ‘refactoring’ (small ‘r’).

The apparently more common usage is the big-R form, Refactoring as a task in its own right. Typical comments would be “We have to spend the next two weeks Refactoring this system”. The small-r form is done as part of everyday programming activities, at the same level as writing statements and method calls. Nobody says, “Today my tasks will include writing for-loops, methods and if-else statements.” (Although that is a great way of describing your activities without actually saying anything about what you will be doing.)

The XP / Test-first crowd tend to think of refactoring in the small-r sense. Its just one piece of the Test-Code-(r)efactor cycle that they go through many times a day. In this way (in a perfect world), the code is kept clean and lean enough that Refactoring (big-R) is never required. Having to plan a Refactoring session for some code probably means that its in what the XP books call ‘Refactoring debt’ (its like oxygen debt for software). The system wasn’t refactored mercilessly enough (if at all) while it was being grown, and, just like a human in oxygen debt, progress slows down and pain increases, until it becomes necessary to stop and do something about it, in a big Refactoring session.

I am of the opinion that just as aerobic exercise (eg. jogging) is less painful and can be done for longer than anaerobic exercise (eg. sprinting), its better to keep to the discipline of refactoring as you go (ideally as part of the test-code-refactor cycle), and try to minimise the incidences of Refactoring required (during which customer-visible progress tends to slow or stop).