I once explained what refactoring was to a non-programmer. It went like this:

“We software developers (programmers for short) do not only need to write a program that accomplishes a task. That’s the easy part. The difficult part is to change an existing program to adapt to new requirements / problems.

A lot of thought has been put into this problem. Methodologies, advice, tips, books, best-practices arose and continue to arise to address this issue.

One such “practice” to address the “changeability” of a program is “refactoring”. Refactoring means that you change the way your program is structured inside, without changing what it does. It takes work, talent, insight and time, but ultimately it pays off. You are left with a better structure for your program and from there you can make changes more easily.

Imagine you just came from the super-market and bought a lot of stuff. Your goal is to prepare dinner for some guests. In front of you are the bags full of the ingredients you bought. Some other ingredients are somewhere in your kitchen. You still have some pans and bowls to wash from yesterday.

You could start cooking right away, and looking for each item as you need it, cleaning and making room in your kitchen as you need it, or brining an extra table from another room to occupy place in your kitchen because you are so focused on cooking that you don’t want to waste time making some order. Because you don’t have place to work, you take the new ingredients from the bags as you need them, and lay them on the floor.

You could work like that, because your mantra is “no need for tidying up, have to cook” but ultimately you will be less productive and the results will not be as good.

Instead, if you take time to bring your kitchen to a better “shape”, to wash, tidy up, prepare everything before you even start cooking, what looked as a waste of time pays off (because you know you will cook afterwards; if you won’t you can as well leave everything as it is).”