Every developer has felt the urge to rewrite code that offends their sensibilities. That urge is natural, but acting on it without good reason can cause more problems than it solves. Here’s how we think about when refactoring makes sense—and when it doesn’t.
Good Reasons to Refactor
You’re about to make a change in that area anyway. The Boy Scout Rule (“leave the code better than you found it”) works well when applied locally. If you’re touching code to add a feature or fix a bug, improve it while you’re there.
The current code is actively slowing you down. If you and your teammates keep struggling with the same tangled logic, that’s a signal. The cost of refactoring may be less than the ongoing cost of working around problems.
You need to add tests. Sometimes code is structured in a way that makes it nearly impossible to test. Refactoring to make code testable often improves the design as a side effect.
Bad Reasons to Refactor
It doesn’t match current best practices. Best practices evolve. Code written two years ago may not follow today’s conventions, and that’s fine. If it works and you’re not planning to modify it, leave it alone.
You think it could be more elegant. Elegance is subjective and often at odds with clarity. Code that’s slightly inelegant but easy to understand usually beats clever code that requires documentation to decode.
You want to learn a new technique. Learning is great, but production code isn’t the place to experiment. Practice new approaches in side projects or non-critical paths first.
The Strangler Fig Approach
When you do need to rework a significant portion of a codebase, consider the Strangler Fig pattern. Instead of a big-bang rewrite, gradually replace pieces while keeping the system working. This reduces risk and lets you validate changes incrementally.
Communicate About Technical Debt
Refactoring decisions don’t exist in a vacuum. If significant refactoring is needed, make sure stakeholders understand why. Frame it in terms of business impact: faster future development, fewer bugs, reduced risk.
The best engineering teams we’ve seen treat technical debt like financial debt—something to be managed consciously, not ignored or eliminated entirely.
Struggling with technical debt in your codebase? Reach out—we help teams develop practical strategies for managing and reducing it.