skip to content

How do you budget refactoring against feature delivery and justify it to non-technical stakeholders?

level: principalimportance: should knowfreq 40%

answer

  1. Two channels: inside estimates + small explicit slice
  2. Interest, principal, payback, roadmap linkage
  3. Agree the policy once, not every sprint
  4. Evidence: lead time, change failure rate, rework
  5. Say no sometimes: short-lived, low-churn code

basics

~10 s

Fold most cleanup into feature estimates instead of asking permission for it, keep a small explicit allocation for larger items, and argue in terms of delivery speed and risk rather than code beauty.

solid answer

~50 s

Use two funding channels together. Most repayment should be internal: preparatory and opportunistic refactoring inside the estimate of the feature that benefits, so quality is a professional standard rather than a negotiable line item. On top, keep a small explicit allocation - a share of each iteration or a standing slot - for high-interest debt no feature will naturally touch, agreed once as policy rather than re-argued every sprint. Justify it economically: state interest in delivery terms ("changes here take three days instead of one, about eight times a quarter"), the principal, and the payback period; tie items to committed roadmap so repayment is an enabler, not a detour. Track outcomes - lead time, change failure rate, share of capacity spent on incidents and rework - so the next request has evidence. Be honest about the reverse too: some debt should never be repaid, which makes the requests you do make credible.

go deeper

for a junior

Say cleanup should be included in the work rather than requested separately, and framed as making future changes faster.

for a middle

Describe both channels - inside estimates and a small explicit allocation - plus the habit of preparatory refactoring.

for a senior

Quantify interest, principal and payback, link items to roadmap commitments, and use delivery metrics as evidence.

for a principal

Add governance: agreeing the policy once, guardrails that limit new debt, portfolio decisions about which debt never to repay, and building trust by declining low-value items.

## Two funding channels **Internal (default).** Preparatory refactoring and everyday cleanup belong in the estimate, not in a separate approval. This avoids the failure mode where quality becomes a permission slip a product owner can decline, and it is honest: the estimate reflects the real cost of changing this code. **Explicit (exception).** Debt too large to hide, or living in code no upcoming feature touches, needs visible capacity. Common shapes: a fixed share of each iteration (10-20% is the usual quoted band), a maintenance rotation, a hardening period after a major release, or debt items competing directly in the backlog with a stated payback. Agree the policy once; renegotiating it every sprint guarantees it loses to the nearest deadline. ## Making the economic case Stakeholders do not buy "clean code"; they buy predictability, speed and risk reduction. A usable argument has four parts: 1. **Interest, quantified in their units.** "Every change in checkout costs about two extra days and caused three of the last five rollbacks." 2. **Principal.** "About six engineer-days." 3. **Payback.** "We change that area roughly eight times a quarter, so it repays within a quarter." 4. **Roadmap linkage.** "Three of the next quarter's committed items go through it." Debt blocking a commitment is scope, not cleanup. Evidence that travels well: delivery lead time and its variance, change failure rate, share of capacity spent on incidents and rework, and estimate inflation for comparable work over time. Avoid presenting raw static-analysis scores as the argument - they measure symptoms and invite haggling over the metric instead of the outcome. ## Guardrails that reduce future borrowing Budgeting is cheaper when less debt arrives: a definition of done that includes tests, automated checks in the build (lint, architecture rules, coverage on changed code), review standards, and a rule that deliberate shortcuts require a written decision with a repayment trigger. Design choices that keep options open - clear module boundaries, reversible decisions - lower the interest rate of future debt. ## When *not* to repay Credibility comes from saying no as well as yes: - Code with a short remaining life (being replaced, or in a product being retired). - Rarely changed modules with no roadmap overlap. - Debt whose principal exceeds the remaining value of the component. - Prototypes explicitly built to be discarded - provided they really are discarded rather than quietly promoted to production. ## Failure modes - **Refactoring as a negotiation item** - declined whenever there is pressure, which is always. - **The debt sprint that never comes** - a promised window perpetually deferred. - **All-or-nothing rewrite proposals** - too large to approve and too risky to start. - **Aesthetic arguments** - "this code is ugly" has no comparable unit against revenue features. - **Allocation without habits** - a 20% budget cannot offset a team that adds debt daily.

  • A product owner rejects every refactoring request. What do you change?
    Stop making them separate requests. Fold preparatory refactoring into feature estimates so it is part of the cost of the change, agree a standing allocation once at policy level, and reframe the remaining asks around delivery risk and roadmap commitments with quantified interest and payback.
  • Which metrics support a debt argument, and which mislead?
    Useful: delivery lead time and its variance, change failure rate, share of capacity on incidents and rework, estimate inflation for similar work, and churn in hotspots. Misleading alone: lines of code, raw coverage percentage, and static-analysis debt scores, which measure symptoms and invite arguing about the metric.
  • When should you deliberately leave debt unpaid?
    When the code has a short remaining life, when it is rarely changed and no planned work touches it, when the principal exceeds the component's remaining value, or when it is throwaway experimental code that will genuinely be thrown away.

Vehicle maintenance for a delivery fleet. You do not ask the sales director's permission to change the oil - it is part of running the truck. You do make a business case for replacing the gearbox, using downtime and missed deliveries, not engine aesthetics.

saying these in an interview costs you the question

  • Treating every refactoring as something to request permission for, sprint by sprint
  • Justifying refactoring with aesthetics or 'best practice' rather than delivery outcomes
  • Proposing an all-or-nothing rewrite as the only remedy
  • Promising a future cleanup sprint with no trigger and no owner
  • Assuming a fixed debt allocation removes the need for everyday quality habits
  • Never declining a debt item, which destroys the credibility of the ones that matter

context

resolving links…