Comparisons help us understand new ideas faster because human brain prefers linking new ideas to things it already know.

So when I need to explain the technical concept of “Code Refactoring” to non-technical people I use a comparison with our home.

Your home is like your code, from time to time it needs to be cleaned and stuff needs to be sorted out. The clothes you left on the chair since last month should not be there and you know it. In software it works the same way, sometimes you need to tidy up, move portion of code from one file to another and rewrite functions to make them clearer and lighter. If you never sort things out, your code eventually break in a way or another.

Imagine to never tidy up your place, eventually you probably can’t even open the door anymore. Or image to never clean up your desk, eventually you can’t use it anymore because there is no space left. Also you can’t move your desk anymore because stuff will fall down and you will break something else. Moreover in the mess you usually can’t find what you are looking for.

Same concept applies on software, if you code piles up (like your clothes or your stuff on your desk), you eventually cannot touch a single line of code because something else will break. The concept of moving stuff to the right place is unbelievably applicable to both worlds.

Code refactoring, like being tidy and organized in life, is an essencial pratice that any codebase needs. The best way to do it is on a recurring way, but is not so easy to decide what to refactor in the first place. So what I usually recommend, due to the eternal lack of time in companies, is to track down plausible refactors while working on another feature or bug. This moment is the best because you are already watching the code and you can note down how you would change it.

It is preferred to not perform code refactoring on the same branch of the feature or bug you are working on. These tasks must be separated, but if you think to resolve a bug faster or to create a feature in a cleaner way it would be extremely beneficial to perform a code refactor, then go ahead, you will thank yourself later.

A more difficult aspect to explain are the benefits of code refactoring, because they are not easly countable, so the activity rarely find the dedicated time slot it deserves. The benefits are usually on the long run but everybody know that the business people always prefer that a feature is shipped today. If you want to measure the benefits you can try to track these 2 metrics from today: the average time a feature takes to complete; the average number of bugs reported. If you carefully track these metrics over time, you might even demostrate the benefits of code refactoring on the long run. Both metrics should decrease over time.

As of my experience I can guarantee you that after working “the right way” the features ships extremely fast and the bugs are very rare. Eventually everybody is happy, because business people see the features shipping quickly and developers feel better because they enjoy to work on cleaner code.

Side note: I didn’t mention test coverage on this article because it needs a dedicated article, but I’d say that testing can be included inside “code refactoring” concept due to its benefits on the long run.