Just the other day I was listening to, i.e. eavesdropping, a conversation between peers where they were trying to decide on what version of Visual Studio.NET their team should migrate to. This team was still using Visual Studio 6 (!!) and wanted to know if they should go to 2005 or 2008. During the conversation the motivation for the upgrade was discussed:

“We want to refactor some of the old [C++] code in C#.”

[OK, now imagine the sound of metal scraping on your fillings. It is that bad.]

Refactoring has been in print since 1999 and has a really clear definition. I also tend to think it is one of the fundamental skills every software developer should be proficient in. Frankly, I feel if you are not refactoring your code, you are not doing your job. So, why do people in this day and age of our profession still consider a rewrite of old code in a new language refactoring? Just another example of sloppy language and, unfortunately, sloppy thinking. So, to be precise, here are the definitions of refactoring.

refactoring (n.): a change to made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

refactoring (v.): to restructure software by applying a series of refactorings without changing its observable behavior.

For those of you who have stumbled upon my rant, here is a short list of things I do NOT consider refactoring:

• adding new functionality to the code.
• changing the design in the absence of automated tests – either unit, functional or acceptance.
• a separate “stage” in the project you do either after, or before, the “real” work.
• a replacement, or substitution, for a genuine software design.
• “fixing things up while you are in there.”