Technical debt

Technical debt is the accumulated cost of expedient engineering decisions. Ward Cunningham coined the metaphor in 1992: shipping code that is not quite right is like borrowing money, and you pay interest on it in every subsequent change.

The metaphor’s important half is usually dropped. Cunningham’s point was that taking on debt deliberately can be correct, provided you repay it. Debt taken unknowingly, and never repaid, is not a strategy.

Why it concerns designers

It is frequently the real answer to “why can’t we just”. A change that looks trivial can be expensive because it touches something built quickly three years ago, and understanding that is the difference between a productive conversation and a frustrating one.

It also constrains design directly. If every screen is bespoke rather than composed from components, every design change costs proportionally more, which quietly narrows what the team is willing to consider.

The relationship with design debt

They are the same mechanism in different materials, and they compound. Inconsistent components produce inconsistent code; inconsistent code makes consolidating components expensive. Teams usually have to address both together or neither.

In practice

The useful question in planning is not whether debt exists but whether it is being taken knowingly. A team that can name its debts is managing them. A team surprised by them every sprint is not.