Technical debt

The cost appears in later work

Suppose an illustrative application stores the same business rule in four services. The original duplication may have helped a team meet a deadline. Months later, every policy change requires coordinated edits, repeated testing, and a careful check for inconsistent behavior.

The consolidation work is one cost. The extra effort paid on every intervening change is another. Thinking about both helps explain why a small-looking design problem can become expensive over time.

Not every imperfect design is urgent debt. If an isolated component is unlikely to change again and operates reliably, replacing it may offer little practical return.

Distinguish debt from ordinary unfinished work

A missing feature is not automatically technical debt. Neither is every bug. Ask whether a technical decision creates recurring difficulty beyond the immediate task.

Debt can also be discovered after a reasonable decision. New requirements may expose assumptions that were sensible when the software was built. Describing the issue accurately is more useful than assigning blame for a choice made with different information.

Choosing what to address

Start with a specific source of friction and the work it affects. Estimate the improvement in terms the team can examine, such as fewer coordinated edits or a simpler release process. Compare that benefit with the cost and risk of the change.

Use code metrics as leads, not verdicts. A frequently edited module may be important and well designed. Read the code, ask its maintainers, and connect the proposed cleanup to an actual engineering need.