Refactor-itis

I have an urgent need to talk about a disease which is a threat to the health of the software we create: "refactor-itis".

Martin Fowler's book on refactoring is a valuable piece, because it describes both phenomenea and cure. It also explains that refactoring is sometimes required to get to a stable code base. However, ever since his book has appeared a lot of people have been misusing the word on a frequent basis.

Martin Fowler's definition is the following:

"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior"

In its purest form, it's altering the internal structure without changing the external behaviour. Most often I hear the word 'refactoring' when people want to redesign a piece of software, when they want to write a whole new implementation, ... . As refactoring has the following connotation : 'it is a maintenance effort we cannot really escape from', it often gets accepted because it is well hidden under the cloak of 'refactoring'.

If it were not hidden under this cloak, people would have to answer more questions such as "why is this necessary", "what are the risks",...

I have heard the phrase "I've refactored the interface" being used a couple of times. This is actually in total contradiction with the real meaning of the word.

The problem is ofcourse : How we can cure this decease?

To do that, we should detect the symptoms : we should be triggered when somebody uses the word 'refactoring'. Instead of just accepting it, we should ask through in order to get an idea of the real nature of his/her request. To be able to do this, you should come to a situation where 'refactoring' ideas get announced prior to getting executed (for example in a short meeting or in a short stand-up meeting. Definitely not by e-mail but rather in face-to-face meetings).

The actual cure is that you need some form of sensibilisation of the associated risks of so-called 'refactoring' efforts together with a gatekeeper (or gatekeeper team) which will protect the system from unnecessary rework. I believe that creating business-awareness is a good way to tackle the decease : people should realise what the impact can be on the business. When they do, they'll already have a difficult time in convincing theirselves of the neccessity.

Also, you can more easily decrease the chance that people catch 'refactoritis' if there's enough work on their plate : When you have a tight schedule, people will automatically avoid unnecessary work (this is the human nature).