An application can calculate every price correctly and still be expensive to change. Technical debt describes design or implementation constraints that create extra work in future development and maintenance. Those constraints can come from a deliberate shortcut or from requirements that outgrow the original design.

The three hypothetical examples below trace that extra work: where it arises, how it affects the business and what evidence supports a fix.

1. Hard-coded rules hold up routine changes

Imagine a retailer whose delivery charges are embedded in application code. Each delivery-charge promotion or regional price adjustment requires a developer to edit the rule, check it and release the software.

A simple implementation may have suited charges that rarely changed. With frequent adjustments, however, routine commercial decisions start waiting for a software release.

Review previous requests: how often were charges revised, how much developer work did each revision involve and which promotions waited? Moving frequently adjusted values into controlled configuration could reduce that dependency, with appropriate permissions and checks for authorised staff.

Agreeing which constraints deserve funding is part of business relationship management: technical teams explain the recurring release effort, while business owners establish how much pricing flexibility they need.

2. Duplicated calculations multiply maintenance

Suppose the same customer discount calculation has been copied into a quotation tool and an online checkout. Both versions initially give the right answer. A new discount policy then requires developers to locate and update both copies.

Miss one, and customers could see a checkout price that differs from their quotation. Update both correctly, and there is still the repeated work of making edits and checking that the versions agree. The debt sits in that maintenance burden, not just in the possibility of a pricing error.

Ask developers where the calculation appears and review recent policy changes. Identify repeated edits and any support queries caused by missed updates, keeping observed consequences separate from potential risks.

Sharing the calculation could remove the repeated edits. Before combining the code, confirm that both features apply the same business rule. Similar-looking calculations can reflect different contractual terms, which the revised design must preserve.

3. Tight coupling makes small changes bigger

Consider a reporting feature that reads an order-processing module’s internal data structures directly. When developers reorganise the structures the report relies on, they also have to rewrite parts of the reporting feature. The report’s business purpose remains unchanged, yet maintaining it requires additional work.

This is tight coupling: one component depends heavily on another’s internal details, so a local change spreads across the application.

The change history should reveal the burden. Which internal adjustments prompted reporting edits? Which teams had to coordinate? Separate the effort needed for the requested improvement from the extra effort imposed by the dependency.

Introducing a clearer interface could shield reporting from internal reorganisation. Focus the proposed fix on that boundary before considering a wider split into separate services.

Refactoring restructures code without intending to change its external behaviour. It still needs verification, so include that effort when comparing the proposed improvement with leaving the dependency in place.

Deciding whether to fix, contain or defer the debt

An incorrect button label might need a straightforward correction. To identify technical debt, look beyond the symptom for the underlying constraint and the extra work it creates in later changes or maintenance.

For each item, consider four questions:

  • Frequency: how often does the constraint create additional work?
  • Impact: does it delay business changes, consume maintenance capacity or generate recurring support problems?
  • Upcoming work: will a planned feature encounter the same constraint?
  • Remediation risk: how extensive is the proposed change, and what must be checked afterwards?

Fixing debt is easier to justify when repeated effort is documented and planned work will encounter it again. Addressing the relevant area alongside a new feature may save the team from returning to it separately.

Where a full fix would be too disruptive, containment offers an intermediate option. Documenting the duplicated discount calculation and requiring coordinated updates reduces the chance of omissions while leaving the duplication in place.

Deferral deserves an explicit decision too. Name an owner and set a review trigger, such as a new pricing policy or another change delayed by the same dependency.

Start with one documented constraint. Record the implementation involved, the recurring effort, who feels the consequence and the next decision required. That gives a maintenance discussion something concrete to resolve, rather than an open-ended demand to eliminate technical debt.