Refactor Culture: When and how should we prioritize refactoring on our teams

As software engineers, we are constantly under pressure to deliver new features, fix bugs, and improve the overall performance of our products. In this fast-paced environment, it is easy to prioritize new features over code refactoring, which may seem like a time-consuming and less important task. However, in the long run, refactoring is just like car maintenance — you can put off that oil change and keep driving, but pushing that job down the road creates a larger long-term problem that is harder to fix, eventually rendering you too afraid to drive that car anywhere.

The question is, when and how do we prioritize the process of refactoring? We have a few options: during feature creation, as their own prioritized tasks, or not at all. There are pros and cons to each approach, depending on the size, complexity, and importance of the refactor needed.

Not refactoring

Let’s start with the obvious: not refactoring at all is a serious risk. If your team doesn’t prioritize refactoring, it can create a horror story for your codebase. Your software will become unwieldy, buggy and fragile, and you will sacrifice speed later in feature creation and stability. Eventually, no one will want to touch your code. This changes the culture of the team and the way folks approach the codebase, resulting in less efficient work hours, low morale, and frustration. It becomes harder and harder to hire good developers, and leads to a slippery slope of technical debt.

Some may argue that if the codebase is ‘temporary’ (a proof of concept, for example) we may want to avoid refactoring. This is a reasonable argument, however a good portion of ‘throw away code’ tends to live on much longer than intended. In fact, if a codebase lives long enough that you feel the need to refactor, one could argue that you’ve passed the threshold to consider a project as temporary.

Prioritized stories

Another approach teams use is creating stories which product will prioritize within the feature backlog. Frankly, when a refactor should happen is typically not a product decision. There are occasions when developers determine that the scope of a refactor is too vast, or requires some larger team decisions. In this case, prioritizing it in a backlog may be appropriate. However, this prioritization strategy should never become a gate-keeping mechanism for refactors in a healthy team. In fact, it may be a sign that smaller refactors haven’t been happening earlier in feature work.

This gate-keeping strategy, where a refactor must be associated with a story, can lead to some unhealthy practices. Good developers can’t help themselves but refactor — tidying up logic as we go along makes our work more efficient and enjoyable. This means that, if we are required to associate a refactor with a story, developers will likely sneak in refactors into their feature work.

During feature work

Refactoring code as part of a feature can be a completely reasonable practice. There are some times, however, when enforcing a one-to-one relationship between code, a pull request, and a “ticket”, we end up ballooning PRs out of understandable scope and holding up future work that depends on that feature.

The best process to determine when to refactor is to remove as much process as possible. If, during feature work, it feels right to refactor as part of that release (or PR), they should take the liberty to include it. If the refactor is done during feature work, but might hold up the feature or balloon the scope, it should be done separately from the feature release (or PR) but not necessarily prioritized separately. And if the refactor feels large enough or requires a larger team discussion, it can be turned into its own task and prioritized.

In the end, the solution to determining when to refactor comes down to trust. Trust in the development team to do the right thing, and trust in the communication between the developers and the product team. Though releasing control on this process can feel scary to stakeholders, it is truly the most effective way to build a fast-moving, reliable, and delightful product in the long run.