Why you shouldn't say refactor

As a codebase grows, new features are added and things are learned. This is very common in Agile development, where priorities and new features can be reprioritized and customers discover how a product is used. Organic growth leads to inefficiencies, technical debt, and potential security problems. Because of all of these reasons and more refactoring is a natural and healthy process of development. 

I can hear the thoughts, "If refactoring is healthy, why do we not say refactor?"

Let’s start with the definition: Refactoring is a process to restructure code, while not changing its original functionality. Since there is no change in functionality, there is no change in value to the customer. 

Instead of saying, “We need to refactor the feature x?” try one of the suggestions below. 

• “Lets upgrade the code on feature X to meet current security requirements.”
• “Changing the code in Y will allow feature X to easily add new features. ”
• “A number of recent bugs in feature Z. If we change this function, we can make it easier to understand and reduce future bugs.”

Can you spot the difference? The above is shifting focus away from technology problems and towards the customer perspective. It will show the customer you are invested in the success of the project and care about the outcome. 

To be clear I’m not saying Engineers aren’t interested in the success of their project. They pour weeks, months, or years to a project. They want to see it succeed as much as the customer. This makes the focus on value even more important. It actively demonstrates that desire. Which enables customer trust in decisions that technical teams are making. 

Focusing on customer value won’t always get a yes. If you can change your vocabulary to reflect customer value, the customer will be happier, more features will get done, more technical debt will get fixed, and more value is delivered.