Rules of refactoring

As developers, we constantly notice imperfections in our codebases: rough edges, awkward decisions, bits of bad or outdated code. Naturally, we want to refactor—to make things cleaner, more consistent, maybe even introduce a shiny new library that promises to fix all the legacy pain, or just rewrite everything “the right way.” These are all good intentions. Very developer-like ones.

But… refactoring isn’t always necessary.

Sometimes “bad” code is actually effective. It was written quickly, it does its job well enough, and it doesn’t need to change often. In those cases, touching it may bring more cost than value.

Over time, I’ve come up with my own set of rules for refactoring: when it’s worth doing, and when it’s simply a waste of time.

First, before starting any refactoring, I think about its goals. They need to be clear, measurable, and achievable. Without that, refactoring easily turns into an endless process with no real finish line.

Next, I estimate the effort in terms of time and resources. Sometimes the outcome of a refactoring just isn’t valuable enough for the project to justify the investment.

When evaluating the results, I always look at both the short-term and long-term perspectives. Refactoring might promise big benefits—but only in a future that may never actually arrive. I also consider who benefits from the change. Is it about improving developer satisfaction? Enabling faster feature delivery? Or creating a better user experience for customers?

I also think about the risks refactoring can introduce, and how those risks can be mitigated.

And finally, I consider how the refactoring will be delivered. Ideally, it should be seamless and shouldn’t cause major disruptions to the development cycle.

Sometimes, even when refactoring makes perfect sense for the team, it still needs to be “sold” to stakeholders. In those cases, having clear arguments and tangible benefits becomes essential.

Overall, I find it extremely effective to discuss refactoring decisions with people in different roles—especially those who will be affected by the change. Those conversations often bring the clarity that code alone cannot.