Review Technical Debt

Expedient software design or construction choices that increase later change cost.

Technical debt appears when a software approach helps a team move sooner but leaves the code or architecture harder or more expensive to change later. The original choice may be rational. The debt is the extra future work created by the technical context that choice leaves behind.

Unmanaged technical debt raises development and sustainment costs and can narrow the team's options. Making it visible lets the team decide which debt is useful, which debt is becoming risky, and when repayment is cheaper than building another layer on top of it.

To meet a release date, a team copies the same validation rule into four services instead of creating one maintained component. The release ships sooner, but the next rule change must be found, updated, and tested in four places.

Technical debt is not every bug, old component, or imperfect design. It describes a technical approach whose short-term benefit creates a context in which later work costs more. Some debt can support exploration when it is visible and managed.

Move sooner now; pay more to change it later.

* [[debt|Debt]] * [[rework-loop|Rework Loop]] * [[system|System]] * [[workaround-dependency|Workaround Dependency]] * [[build-vs-buy|Build vs. Buy]]

* [Software Engineering Institute, “Managing Technical Debt in Complex Software Systems”](https://www.sei.cmu.edu/library/managing-technical-debt-in-complex-software-systems/) — defines technical debt as a short-term expedient design or construction approach that makes the same work cost more later, and notes that managed debt can support design exploration.

* [CMU SEI technical-debt overview](https://www.sei.cmu.edu/library/managing-technical-debt-in-complex-software-systems/). * Compare with [[debt|Debt]] for the RS family boundary and [[rework-loop|Rework Loop]] for one possible operational consequence.