This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Refactoring: You keep using that word…
One of the more powerful, yet more easily misunderstood XP tools is the practice of refactoring. It is actually such an important piece of the Agile development puzzle that most teams, whether they are actually doing Scrum or XP or Lean, or any other Agile process, tend to work toward adopting some form of refactoring. But what does refactoring really mean?
When I’m working with development teams, I often will hear some phrases like “that is going to require a major refactoring.” The implication here is that the software needs enough major redesign and retooling that it will take a considerable amount of time. This is not what refactoring was meant to be, and it is a disservice to yourself to think of it as such. As Martin Fowler first explained: “Refactoring is a process of changing a software system in such a way that is does not alter the external behavior of the code yet improves its internal structure”. This is done through disciplined, small steps.
There is a common theme in application development that we will design a system to the best of our ability, then some day when we have the time we will clean up any loose ends that appeared along the way. With refactoring, we do this clean up all the time. Every time I am in the code base, for some reason or other, I look at the area I am in, and see if there is some small refactoring that needs to be done. I use the entire box of agile tools available to me, most specifically automated unit tests. The refactoring, with the tests around it, shouldn’t take more than a few extra minutes. The results may not be earth shattering but if everyone is doing this all the time, the whole becomes much greater than the sum of its parts.
Which brings me to why I think folks are misusing the word refactoring. When I talk to programmers, they say they need to do major refactoring, by which they really mean redesign or rewrite. Call it what it is. Refactoring makes it sound less scary, and less drastic. Sometimes a rewrite might be necessary, but I’d be willing to bet that if you are following agile development practices, it is far less often than you thought. On the other side of the coin, I hear folks say “We do scrum. While we are doing our story planning, we need to account for a story or some tasks for refactoring.” We don’t need a story for this any more than we need a story for writing a “for loop” or fixing the spelling in a user document. If it’s going to take so much time that you need to account for it in your schedule, it isn’t refactoring, its redesign. And I bet you don’t really need to do it.