“Refactoring” is one of those words that are loved by developers and dreaded by project managers. As a developer I love the idea of it, I love initiating, planning and executing a well meaning refactoring. I love making code simpler and easier to understand. So why do we get groans and resistance from PMs and product owners when we bring it up? Don’t they love efficient and clean code practices that lead to a better software product too?

Fundamentally the problem comes from two things: misunderstanding the process and communication of intent.

In order to unpack these concepts we need to briefly remind ourselves what is refactoring.

“A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.” (M.Fowler, “Refactoring”)

Okay, so the key concepts to highlight is that refactoring does not change observable behavior and that it makes it easier to understand and change the codebase. This sounds straightforward and “good”. Who does not want code that is easy to change and add new features? However selling such idea to the stakeholders, by itself, is a losing battle. The value proposition of “code will be better internally, but with no changes to functionality will be made “ sounds like developers complaining about current codebase and doing work to improve it with no tangible benefits to the clients/stakeholders. It is the classic trope of developers complaining about existing system and wanting to do a total rewrite.

This is where communication breakdown happens most often. Developers trying to sell the idea of large scale refactoring and product owners hearing “a bunch of work for nothing to show for”.

So how do we sell idea of refactoring code in the most effective manner?

We don’t sell it at all, we just do it!

Before the accusations of mutiny let me explain. Refactoring is part of the work we do everyday, it is an integral part of delivering high quality software. Think about it as tending a garden, first we make sure the plot of land where we were asked to plant flowers is ready for it and then we plant flowers. We don’t need to sell the idea of preparing the plot for planting because it is part of the job. In software, we implement tasks by first making sure we understand the context and then adding the functionality. If we find it hard to add a feature or fix a bug, we start the process by making appropriate changes to it is easier to accomplish said task (refactoring).

Obviously caveats apply here as they do everywhere, we cant just rewrite the whole system if we find it tricky to add one small feature, we also cant spend all the budget in order to “understand the system”. We need to use our heads and figure out the most effective solution with the time we have. As a general rule, if we think we need a very large scale refactoring (1-2 weeks or more) this is generally full blown software rewrite and not refactoring, as latter consists of small, incremental changes that are done in order to make implementation of feature or a bug fix easier to do.

So next time you are presented with a task to accomplish think and evaluate if context around that task is easy to understand and if you find it hard to accomplish, you may need to be doing a little bit of garden tending in order to make the change easier for you and others who will be finding themselves in that particular plot of land in the future.