Business transformation, change management or transition to better innovative company, improvement and adaptation to new normal concept, smart businessman jump from old to new shiny lightbulb idea
A Rewrite is NOT Refactoring!
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:
[OK, now imagine the sound of metal scraping on your fillings. It is that bad.]“We want to refactor some of the old [C++] code in C#.”
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.”
