Refactoring with purpose: code, product, and trade-offs

Recently, I’ve been in the middle of a major refactoring effort, which made me reflect on what refactoring means in the context of building software. My view is that the product always comes first. And refactoring has value when it helps us deliver that product more effectively.

For the purpose of this blog, let’s stick to this definition of refactoring:

Refactoring entails changing the internal structure of code to make it cleaner, more maintainable, and easier to understand — without changing its external behavior.

Without the product, there’s no purpose for the code. Everything we do should ultimately help us build and deliver that product. Refactoring matters when it helps prevent technical debt from slowing us down or makes it easier to keep improving the product. If a piece of code isn’t affecting the product, or if refactoring it won’t help us move faster or build better, it may not be worth the effort. Let the rot decay!

When do I choose to refactor? For me, the signal that it’s time to refactor is when making changes starts to feel slow or repetitive. When I find myself copying and pasting code, duplicating logic, or struggling to generate small variations in behavior, I know it’s time. I’m not a fan of refactoring purely for style or abstraction. Early on, it’s often better to focus on getting something working because you don’t always know what will need to change later. Refactoring too early can be a waste of effort.

Refactoring is never the top technical priority. The first priority is correctness. The code has to do what it’s supposed to do. Performance is important, especially for code that runs often or at scale. Maintainability and ease of change (the result of our refactoring) comes next, but only once you’ve identified the code that changes often.

With that being said, it’s important to communicate the value of refactoring when you’ve decided that it’s necessary. In the end, you’re all one team working toward the same goal, and open communication builds trust.

Refactoring isn’t about chasing perfection. It’s about keeping the code healthy enough to support the product and the team. I’m still learning how to balance refactoring with delivery, but keeping the product at the center of these decisions helps me make better choices.