CODE TUNER INSIGHTS
Should You Refactor Before Building a New Feature?
Refactoring before a feature can reduce future development cost, but it isn’t always justified. Use these questions to decide.
A commercially important feature reaches engineering. The estimate is higher than expected, followed by a familiar explanation: “We can build it, but we need to refactor this part of the system first.”
Sometimes that is the right call. The decision depends on which code the feature touches and whether improving it now will reduce enough delivery cost or risk to justify the delay.
Start with the route the feature takes
A feature in a healthy part of the product may need little preliminary technical work. A similar-looking feature that crosses a complex, heavily connected component can have a very different cost profile.
The estimate includes more than new functionality. It includes understanding existing behaviour, working around structural constraints and checking the effect on dependent components.
Ask engineering to identify that extra effort. A discussion about specific components and dependencies is easier to evaluate than a general claim that the codebase needs cleaning up.
Three options worth comparing
1. Refactor first
This has a stronger case when the problem is concentrated, the feature definitely depends on it and the improvement can be bounded. Future roadmap items passing through the same area may strengthen the return.
The argument should explain how the upfront work reduces effort or risk across the feature and subsequent development. Include the cost of delaying the customer outcome, not just the engineering saving.
Define the stopping point before work begins. A targeted improvement can otherwise expand into a much broader redesign.
2. Build the feature another way
Product and engineering may be able to achieve the customer outcome without touching the highest-friction component. A change in scope, sequencing or implementation route can sometimes cost less than either a major refactor or the original delivery premium.
Check that the alternative does not merely move the problem elsewhere. New duplication or dependencies may create their own future costs.
3. Accept the premium knowingly
An urgent feature, a long remediation lead time or a component approaching retirement may make immediate refactoring unattractive. Proceeding can still be a sound commercial decision.
Make the additional effort and risk explicit. Record any follow-up work and the assumptions behind postponing it. A known trade-off is easier to manage than a surprise halfway through delivery.
Questions before approving the refactor
- Which part of the feature estimate comes from the existing structure?
- Which components create that additional effort?
- What is the bounded cost and scope of the proposed refactor?
- What would the feature estimate look like afterwards?
- Which other planned features would benefit?
- What is the cost of waiting, and what happens if we proceed without the work?
Use ranges where estimates are uncertain. The purpose is to compare credible options, not to manufacture a precise return from incomplete information.
Check the prediction afterwards
Agree how the team will evaluate the result before the refactor starts. Did the feature require less effort than expected? Did rework fall? Did later changes through the same area become easier?
Interpret the result alongside changes in scope, staffing and delivery conditions. A better complexity score alone does not prove the commercial prediction was right.
This feedback makes the next decision more informed. It also gives engineering a stronger way to demonstrate where technical investment creates value.
Make timing part of the business case
Refactoring is particularly tangible when there is a concrete change to support. That still does not make it a prerequisite for every feature.
Compare three routes: improve the affected code first, achieve the outcome another way, or accept the additional cost and ship. Choose the one that best balances total effort, delivery risk and the value of timing.
Make the next engineering decision with better evidence.
Code Tuner analyses technical debt, complexity and codebase health to support engineering judgement and investment decisions. Explore how Code Tuner can help your team.