Archive for August 14th, 2008

• A Rewrite is NOT Refactoring!

  Date: 2008.08.14 | Category: Communication, Legacy Code, Refactoring | Response: 0

  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.”