Refactoring - Room of Files analogy summary

In my previous posts I have compared software refactoring to sorting out a Room of Files.

You may think in this example I have been just doing trickery with the numbers. It is true that in practise, with refactoring, the time overall will take longer. Nonetheless, even when the total time for things done with refactoring is longer, there will still be many benefits, both tangible and intangible:

• The actual time spent on any given file-finding task is objectively reduced. This corresponds to an actual reduction in the time programmers spend on any given programming task (when not counting any new refactoring).
  
• It is easier for people to do the required work. It’s a lot easier for a programmer to work on a program which is in a good condition than one which is in a poor condition.
  
• When files have to be found with a degree of urgency and speed then the room will be ready. This corresponds both to the need to have programmers fix critical bugs quickly, but also to develop new features to a tight deadline.
  
• The chance for duplication and errors are reduced when everything is well-ordered. One of the causes of errors in software is when things are in several places instead of just one; refactoring removes this duplication and such errors naturally get reduced or eliminated.
  
• People’s morale will be much higher, as a result of contributing to a tidy and well organised room. Programmers will be much happier working on a program which they are really trying to make a quality product internally, rather than something which is just a hack.
  
• People’s morale will be higher, as work will feel fast and efficient, because it is.
  

So, what are the important messages from this room of files example?

• Refactoring is not something you typically do in one big blitz, but rather something you integrate as a part of normal work.
  
• When considering the cost and benefits of a refactoring, the costs always appear at the time of the refactoring, and the benefits always appear after the refactoring.
  
• Even though on the detail level, refactoring takes more time, when looked at from the wider perspective, it can actually save time. Even when there is no overall saving of time, there are other benefits which still make refactoring worthwhile.
  
• There are many benefits including: efficiency of working, reduced bugs, faster when needed, improved morale.
  

See my book The Refactoring Workout for more on refactoring.