What is technical debt, and how does it affect custom software?

Technical debt describes friction in future change

Technical debt is a metaphor for internal design problems that make software harder to modify than it needs to be. A team may gain a short-term benefit from a compromise, then spend extra effort working around it later. Debt can also become apparent as a team learns more about the problem; it is not limited to intentional shortcuts.

Martin Fowler attributes the metaphor to Ward Cunningham. The useful business question is what a design limitation is costing now, which planned changes it affects and whether improving it would reduce that burden. A slow feature is a reason to investigate, not proof that technical debt is the only cause.

Distinguish design friction from other causes

Changing requirements, unfamiliar integrations, unclear ownership and missing test data can slow delivery too. Ask the team to identify the concrete obstacle rather than describe the entire codebase as bad. A useful debt item names the affected component and explains the extra work it creates.

For example, a duplicated validation rule might require three edits whenever a form changes. A tightly connected module might force broad regression checks for a small update. Those observations provide a clearer starting point than a claim that developer frustration or staff turnover proves the system needs a rewrite.

Use Fowler’s quadrant to discuss how a compromise arose

Fowler’s 2009 quadrant distinguishes deliberate from inadvertent debt, and prudent from reckless debt. It is a discussion aid, not a scoring formula or a moral judgment about a developer. The distinction helps a team examine what was known and how the tradeoff was assessed.

• Deliberate and prudent: a conscious compromise with a considered benefit and cost.
• Deliberate and reckless: an acknowledged shortcut without enough attention to its consequences.
• Inadvertent and prudent: limitations become visible as a capable team learns more.
• Inadvertent and reckless: design problems accumulate without being recognized.

A hypothetical internal-tool shortcut

Imagine a fictional equipment team launching an internal request tool. For the first release, one approval rule is copied into two places. The team records the duplication and accepts it while the workflow is still being tested with a small set of requests. This example is not a client case or a claim about actual delivery results.

Later, the business adds a second approval level. One copy changes while the other does not, and testers find inconsistent decisions. The debt item becomes specific: consolidate the rule, add checks for both approval paths and document the intended behavior.

The original compromise did not guarantee failure, and a simpler first implementation was not automatically wrong. What matters is that assumptions changed and the recorded limitation now interferes with a planned feature. The team should reassess it before adding more exceptions.

Prioritize by impact, change frequency and risk

Start with areas the team changes frequently, repeated sources of confusion and limitations that block an agreed outcome. Review whether the issue can be improved during nearby feature work. Treat a security defect or dangerous data-loss behavior as a risk requiring its own response, rather than quietly parking it in a general debt backlog.

There is no universal rule that every team should reserve 15–20% of each sprint. Agree a capacity allocation appropriate to the backlog, product plans and operational risk, then revisit it with evidence. Nor does every awkward but stable component need immediate cleanup.

For each candidate, compare a bounded improvement with the cost and uncertainty of leaving it alone. Estimates are imperfect; small changes and tests can reveal more than a sweeping rewrite proposal.

Keep a debt register that supports decisions

Make the register useful to both technical and business owners. Describe the observed problem, affected workflow, proposed improvement and acceptance criteria. Assign an owner and a review trigger, such as adding a new approval level, rather than relying only on a distant calendar date.

• Component: where the problem is located.
• Evidence: the extra edits, incidents or testing burden observed.
• Impact: the users or planned features affected.
• Options: bounded remediation, temporary containment or deliberate deferral.
• Validation: tests or operating checks that show improvement.
• Owner and review trigger: who decides and when the assumption must be revisited.

Improve in steps and verify the result

For the equipment example, first add a test that demonstrates the inconsistent approval behavior. Consolidate the rule in a small change, check both existing and new paths, and observe the next policy update. The acceptance result is consistent behavior and a simpler update process, not merely fewer lines of code.

A technical-debt review should end with prioritized decisions and known limits. Keep changes reversible where possible, avoid mixing a broad cleanup with unrelated features, and record what was verified. The goal is software that can support the next useful change with less uncertainty.