Technical debt is a neologistic 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:
Business pressures, where the business considers getting something released sooner before all
of the necessary changes are complete, builds up technical debt comprising those uncompleted
changes. Lack of process or understanding, where businesses
are blind to the concept of technical debt, and make decisions without considering the
implications. Lack of building loosely coupled components,
where functions are not modular, the software is not flexible enough to adapt to changes
in business needs. Lack of test suite, which encourages quick
and risky band-aids to fix bugs. Lack of documentation, where code is created
without necessary supporting documentation. That work to create the supporting documentation
represents a debt that must be paid. Lack of collaboration, where knowledge isn't
shared around the organization and business efficiency suffers, or junior developers are
not properly mentored Parallel development at the same time on two
or more branches can cause the buildup of technical debt because of the work that will
eventually be required to merge the changes into a single source base. The more changes
that are done in isolation, the more debt that is piled up.
Delayed refactoring – As the requirements for a project evolve, it may become clear
that parts of the code have become unwieldy and must be refactored in order to support
future requirements. The longer that refactoring is delayed, and the more code is written to
use the current form, the more debt that piles up that must be paid at the time the refactoring
is finally done. Lack of knowledge, when the developer simply
doesn't know how to write elegant code. 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 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 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."
— 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 it, 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." — 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". 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.
In open source software, postponing sending local changes to the upstream project is a
technical debt. See also
Bus factor Big ball of mud
Bit rot TODO, FIXME, XXX
Software entropy SQALE
References ^ Ward Cunningham. "The WyCash Portfolio Management
System". Retrieved 2008-09-26. ^ Kerievsky, Joshua. Refactoring
to Patterns. ISBN 0-321-21335-1. External links
Ward Explains Debt Metaphor, video from Ward Cunningham
OnTechnicalDebt The online community for discussing technical debt
TechDebt The first collaborative & live benchmark on technical debt and software quality
Experts interviews on Technical Debt: Ward Cunningham, Philippe KRUCHTEN, Ipek OZKAYA,
Jean-Louis LETOUZEY Steve McConnell discusses technical debt
TechnicalDebt from Martin Fowler Bliki An Andy Lester talk entitled "Get out of Technical
Debt Now!" Lehman's Law
Limited WIP Society website discusses techniques to avoid building up technical debt
Managing Technical Debt Webinar by Steve McConnell