Technical debt

Technical debt (also known as design debt[1] or code debt) is a recent metaphor referring to the eventual consequences of poor system design, software architecture or software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy.

As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future. Just like financial debt, these uncompleted changes incur interest on top of interest, making it cumbersome to build a project. Although the term is used in software development primarily, it can also be applied to other professions.

Causes

Common causes of technical debt include (a combination of):

Kinds of technical debt

It is useful to differentiate between kinds of technical debt. Fowler differentiates "Reckless" vs. "Prudent" and "Deliberate" vs. "Inadvertent" in his discussion on Technical Debt quadrant.[2]

Consequences

"Interest payments" are both in the necessary local maintenance and the absence of maintenance by other users of the project. Ongoing development in the upstream project can increase the cost of "paying off the debt" in the future. One pays off the debt by simply completing the uncompleted work.

The buildup of technical debt is a major cause for projects to miss deadlines. It is difficult to estimate exactly how much work is necessary to pay off the debt. For each change that is initiated, an uncertain amount of uncompleted work is committed to the project. The deadline is missed when the project realizes that there is more uncompleted work (debt) than there is time to complete it in. To have predictable release schedules, a development team should limit the amount of work in progress in order to keep the amount of uncompleted work (or debt) small at all times.

"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it."[3]

— Meir Manny Lehman, 1980

While Manny Lehman's Law already indicated that evolving programs continually add to their complexity and deteriorating structure unless work is done to maintain them, Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise."[4]

— Ward Cunningham, 1992

In his 2004 text, Refactoring to Patterns, Joshua Kerievsky presents a comparable argument concerning the costs associated with architectural negligence, which he describes as "design debt".[5]

Activities that might be postponed include documentation, writing tests, attending to TODO comments and tackling compiler and static code analysis warnings. Other instances of technical debt include knowledge that isn't shared around the organization and code that is too confusing to be modified easily.

Grady Booch compares how evolving cities is similar to evolving software-intensive systems and how lack of refactoring can lead to technical debt.

"The concept of technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed. In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones. So it is again in software-intensive systems. Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up."[1]

— Grady Booch, 2014

In open source software, postponing sending local changes to the upstream project is a technical debt.

See also

References

  1. ↑ 1.0 1.1 Suryanarayana, Girish (November 2014). Refactoring for Software Design Smells (1st ed.). Morgan Kaufmann. p. 258. ISBN 978-0128013977. Retrieved 19 November 2014.
  2. ↑ Fowler, Martin. "Technical Debt Quadrant". Retrieved 20 November 2014.
  3. ↑ Lehman, MM (1996). "Laws of Software Evolution Revisited". EWSPT '96 Proceedings of the 5th European Workshop on Software Process Technology: 108–124. Retrieved 19 November 2014.
  4. ↑ Ward Cunningham (1992-03-26). "The WyCash Portfolio Management System". Retrieved 2008-09-26.
  5. ↑ Kerievsky, Joshua (2004). Refactoring to Patterns. ISBN 0-321-21335-1.

External links