Technical debt

In software development and other information technology fields, technical debt (also known as design debt^[1] or code debt) is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.^[2]

Analogous with monetary debt,^[3] 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.^[4]^[5]

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.

In a Dagstuhl seminar held in 2016, technical debt was defined by academic and industrial experts of the topic as follows: "In software-intensive systems, technical debt is a collection of design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible. Technical debt presents an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability."^[6]

Ongoing development, long series of project enhancements over time renders old solutions sub-optimal.

Insufficient up-front definition, where are still being defined during development, development starts before any design takes place. This is done to save time but often has to be reworked later.^[7]

requirements

Business pressures, where the business considers getting something released sooner before the necessary changes are completed, hence builds up technical debt involving those uncompleted changes.^: 4^[9]^: 22

[8]

Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications.

where functions are not modular, the software is not flexible enough to adapt to changes in business needs.

Tightly coupled components

Lack of a , which encourages quick and risky band-aid bug fixes.

test suite

Lack of , where code is created without supporting documentation. The work to create documentation represents debt.^[8]

software documentation

Lack of collaboration, where knowledge isn't shared around the organization and business efficiency suffers, or junior developers are not properly mentored.

Parallel development on multiple branches accrues technical debt because of the work required to merge the changes into a single source base. The more changes done in isolation, the more debt.

Deferred ; As the requirements for a project evolve, it may become clear that parts of the code have become inefficient or difficult to edit and must be refactored in order to support future requirements. The longer refactoring is delayed, and the more code is added, the bigger the debt.^[9]^: 29

refactoring

Lack of alignment to standards, where industry standard features, , and technologies are ignored. Eventually integration with standards will come and doing so sooner will cost less (similar to "delayed refactoring").^[8]^: 7

frameworks

Lack of knowledge, when the developer doesn't know how to write elegant code.

[9]

Lack of ownership, when outsourced software efforts result in in-house engineering being required to or rewrite outsourced code.

refactor

Poor technological leadership, where poorly thought out commands are handed down the chain of command.

Last minute specification changes. These have potential to percolate throughout a project, but there is insufficient time or budget to document and test the changes.

[7]

Common causes of technical debt include:

Happened-upon technical debt—debt that the development team was unaware existed until it was exposed during the normal course of performing work on the product. For example, the team is adding a new feature to the product and in doing so it realizes that a work-around had been built into the code years before by someone who has long since departed.

Known technical debt—debt that is known to the development team and has been made visible using one of many approaches.

Targeted technical debt—debt that is known and has been targeted for servicing by the development team.

Kenny Rubin uses the following status categories:^[10]

(symptoms of inferior code quality that can contribute to technical debt)

Code smell

Big ball of mud

Bus factor

Escalation of commitment

Manumation

Overengineering

Shotgun surgery

Software entropy

Software rot

Spaghetti code

SQALE

Sunk cost

TODO, FIXME, XXX

video from Ward Cunningham

Ward Explains Debt Metaphor

The online community for discussing technical debt

OnTechnicalDebt

Experts interviews on Technical Debt: , Philippe KRUCHTEN, Ipek OZKAYA, Jean-Louis LETOUZEY

Ward Cunningham

Steve McConnell discusses technical debt

from Martin Fowler Bliki

TechnicalDebt

by Doug Knesek

Averting a "Technical Debt" Crisis

a talk by Andy Lester

"Get out of Technical Debt Now!"

Lehman's Law

Managing Technical Debt Webinar by Steve McConnell

Software cancer: the seven early warning signs or here, ACM SIGSOFT Software Engineering Notes, Vol. 18 No. 2 (April 1993), Association for Computing Machinery, New York, New York, US