Technical Debt

Definition

Ward Cunningham

Technical debt is the idea that you can gain a temporary speed boost by rushing software development, at the cost of slowing down future development.

Ward Explains Debt Metaphor

Wikipedia

In software development, technical debt (also known as design debt or code debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
Analogous with monetary debt, if technical debt is not repaid, it can accumulate "interest", making it harder to implement changes. Unaddressed technical debt increases software entropy and cost of further rework. Similarly to monetary debt, technical debt is not necessarily a bad thing, and sometimes (e.g. as a proof-of-concept) is required to move projects forward. On the other hand, some experts claim that the "technical debt" metaphor tends to minimize the ramifications, which results in insufficient prioritization of the necessary work to correct it.
As a change is started on a codebase, there is often the need to make other coordinated changes in other parts of the codebase or documentation. Changes required that are not completed are considered debt, and until paid, will incur interest on top of interest, making it cumbersome to build a project. Although the term is primarily used in software development, it can also be applied to other professions.

Wikipedia (2023-02-05)

Causes

Studies

venters.etal.2018.softwaresustainabilityresearch (pg. 11)

Many factors can lead to architecture erosion and drift, from the accumulation of wrong or sub-optimal design decisions to communication problems between design and development teams [Jaktman et al., 1999].

venters.etal.2018.softwaresustainabilityresearch (pg. 17)

The appearance of the different dimensions of technical debt [McConnell, 2007] [Fowler, 2009] as a quality indicator of suboptimal design decisions and coding practices, led software developers to keep this debt under control [Letouzey, 2012] to reduce the remediation cost of technical debt management. Therefore, we need to discover the root and sources of the debt [Kazman, 2015] and those "hot-spots" [Mo, 2015] in long-living systems to be able to measure software sustainability both in architecture and code [Le, 2016].

venters.etal.2018.softwaresustainabilityresearch (pg. 18)

A number of approaches have investigated modularity metrics as an indicator of technical debt [Liang, 2014]

Similar Debts

πŸ”— References

Towards an understanding of technical debt | Kellan Elliott-McCrea by Kellan Elliott-McCrea

There are at least 5 distinct things we mean we say β€œtechnical debt”.

  1. Maintenance work
  2. Features of the codebase that resist change
  3. Operability choices that resist change
  4. Code choices that suck the will to live
  5. Dependencies that resist upgrading

All code is technical debt. All code is, to varying degrees, an incorrect bet on what the future will look like. You can address issues that are damaging to productivity, operability and morale, but only way to β€œfix technical debt” is β€œrm -rf”.

All code is technical debt – Paul McMahon