View source for Technical debt

'''Technical debt''' (also known as '''design debt''' or '''code debt''') is a metaphor referring to the eventual consequences of any system design, [[software architecture]] or [[software development]] within a [[codebase]].

== Description ==

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]].

Analogous to monetary debt, technical debt is not necessarily a bad thing, and sometimes technical debt is required to move projects forward. 

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):

* '''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 programming|modular]], the software is not flexible enough to adapt to changes in business needs.
* '''Lack of test suite''', which encourages quick and risky [[band-aid (Computing)|band-aid]]s 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'''&nbsp;– 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 alignment to standards''', where industry standard features, frameworks, technologies are ignored. Eventually, integration with standards will come, doing sooner will cost less (similar to 'delayed refactoring').
* '''Lack of knowledge''', when the developer simply doesn't know how to write elegant code.

== 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.

== 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 (software development)|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.

<blockquote>"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it."
</blockquote>

While [[Meir Manny Lehman|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:

<blockquote>"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 programming|object-oriented]] or otherwise."
</blockquote>

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".

== Commonly postponed activities ==

Activities that might be postponed include:

* [[documentation]]
* Writing [[Test automation|tests]]
* Attending to [[Comment (computer programming)#Tags|TODO comments]]
* Tackling compiler and [[static code analysis]] warnings

Other instances of technical debt include:

* [[Knowledge]] that isn't shared around the organization
* Code that is too confusing to be modified easily

== Grady Booch ==

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

<blockquote>"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."
</blockquote>

== Postpost sending local changes upstream ==

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

== See also ==

* [[Big ball of mud]]
* [[Bus factor]]
* [[Codebase]]
* [[Code reuse]]
* [[Comment (computer programming)#Tags]]
* [[Escalation of commitment]]
* [[Intellectual property]]
* [[Link rot]]
* [[Project management]]
* [[Software architecture]] 
* [[Software development]] 
* [[Software development process]] 
* [[Software entropy]]
* [[Software rot]]
* [[SQALE]]
* [[Sunk costs]]
* [[Technology]]

==External links==

* [https://en.wikipedia.org/wiki/Technical_debt Technical debt] @ Wikipedia
* [http://c2.com/cgi/wiki?WardExplainsDebtMetaphor ''Ward Explains Debt Metaphor''], video from Ward Cunningham
* [http://www.ontechnicaldebt.com OnTechnicalDebt] The online community for discussing technical debt
* [http://www.techdebt.org TechDebt] The first collaborative & live benchmark on technical debt and software quality
* Experts interviews on Technical Debt: [http://blog.techdebt.org/resources-links/67/ward-cunningham-interview-about-technical-debt-sqale-agile Ward Cunningham]{{dead link|date=April 2014}}, [http://blog.techdebt.org/interviews/156/interview-with-philippe-kruchten-on-technical-debt-rup-ubc-decision-process-architecture Philippe KRUCHTEN]{{dead link|date=April 2014}}, [http://blog.techdebt.org/interviews/189/technical-debt-interview-with-ipek-ozkaya-on-technical-debt-sei-ieee-software-architecture-agile Ipek OZKAYA]{{dead link|date=April 2014}}, [http://blog.techdebt.org/interviews/118/interview-with-jean-louis-letouzey-on-technical-debt-and-sqale Jean-Louis LETOUZEY]{{dead link|date=April 2014}}
* [http://www.construx.com/10x_Software_Development/Technical_Debt/ Steve McConnell discusses technical debt]
* [http://www.martinfowler.com/bliki/TechnicalDebt.html TechnicalDebt] from Martin Fowler Bliki
* [http://www.media-landscape.com/yapc/2006-06-26.AndyLester/ An Andy Lester talk entitled] "Get out of Technical Debt Now!"
* [http://www.inf.ed.ac.uk/teaching/courses/rtse/Lectures/lehmanslaws.pdf Lehman's Law]
* [http://www.limitedwipsociety.org/ Limited WIP Society] website discusses techniques to avoid building up technical debt
* [http://www.youtube.com/watch?v=lEKvzEyNtbk Managing Technical Debt Webinar by Steve McConnell]
* Boundy, David, [http://dl.acm.org/citation.cfm?id=156632 Software cancer: the seven early warning signs] or [https://www.academia.edu/2303865/Software_cancer_the_seven_early_warning_signs here], ACM SIGSOFT Software Engineering Notes, Vol. 18 No. 2 (April 1993), Association for Computing Machinery, New York, NY, USA

[[Category:Computation]]
[[Category:Computer science]]
[[Category:Information]]
[[Category:Software]]
[[Category:Software development]]
[[Category:Web design and development]]