{{Short description|Cost of maintaining a low quality system}}
'''Technical debt''' (also known as '''design debt'''<ref name="Girish 2014">{{cite book|last1=Suryanarayana|first1=Girish|title=Refactoring for Software Design Smells|date=November 2014|publisher=Morgan Kaufmann|isbn=978-0128013977|pages=258|edition=1st}}</ref> or '''code debt''') is a qualitative description of the cost to maintain a system that is attributable to choosing an expedient solution for its development.<ref>{{cite web|url=https://www.techopedia.com/definition/27913/technical-debt|website=Techopedia|title=Definition of the term "Technical Debt" (plus, some background information and an "explanation")|access-date=August 11, 2016}}</ref> While an expedited solution can accelerate development in the short term, the resulting low quality may increase future costs if left unresolved.<ref name="Managing_Technical_Debt">{{cite journal|last1=Allman|first1=Eric|title=Managing Technical Debt|journal=Communications of the ACM|date=May 2012|volume=55|issue=5|pages=50–55|doi=10.1145/2160718.2160733|s2cid=53246391}}</ref> The term is often used in the context of information technology and especially software development.
Technical debt is similar to yet differs significantly from monetary debt. Incurring either generally makes future goals more challenging to attain. But unlike monetary debt, technical debt is often incurred without intention. The choice to minimize development time and cost, an ever-present aspect of business, is the primary factor. Technical debt is generally only assessed retroactively (after a development effort).
Properly managing technical debt is essential for maintaining software quality and long-term sustainability. In some cases, taking on technical debt is a strategic choice to meet immediate goals, such as delivering a proof of concept or a quick release. However, failure to prioritize and address the debt can result in reduced maintainability, increased development costs, and risk to production systems.<ref name="Jeffries 2015">{{cite web|last=Jeffries|first=Ron|access-date=November 10, 2015|url=http://ronjeffries.com/articles/015-11/tech-debt/|archive-url=https://web.archive.org/web/20151111011323/http://ronjeffries.com/articles/015-11/tech-debt/|archive-date=November 11, 2015 |title=Technical Debt – Bad metaphor or worst metaphor?}}</ref><ref name="Knesek 2016">{{cite web|last=Knesek|first=Doug|access-date=April 7, 2016|url=https://www.linkedin.com/pulse/averting-technical-debt-crisis-part-1-doug-knesek|title=Averting a 'Technical Debt' Crisis}}</ref>
Technical debt results from design and implementation decisions that may optimize for the short term, but at the expense of future adaptability and maintainability. System aspects that incur technical debt can be described as a collection of design or implementation constructs that make future changes more costly or impossible, primarily impacting internal system qualities such as maintainability and evolvability.<ref>{{cite journal |last1=Avgeriou |first1=Paris |last2=Kruchten |first2=Philippe |last3=Ozkaya |first3=Ipek |last4=Seaman |first4=Carolyn |title=Managing technical debt in software engineering (Dagstuhl seminar 16162) |journal=Dagstuhl Reports |date=2016 |volume=6 |issue=4 |url=https://drops.dagstuhl.de/opus/volltexte/2016/6693/pdf/dagrep_v006_i004_p110_s16162.pdf#page=3}}</ref>
== Origin == Ward Cunningham coined the term ''technical debt'' in 1992.<ref>{{Cite web |date=2024-06-13 |title=Technical Debt |url=https://www.techopedia.com/definition/27913/technical-debt |access-date=2025-02-06 |website=Techopedia |language=en-US}}</ref> After reading ''Metaphors We Live By'', Cunningham devised this debt metaphor to explain to his boss the need to refactor the financial product they were working on:<ref>{{Cite AV media |url=https://www.youtube.com/watch?v=pqeJFYwnkjE |title=Debt Metaphor |date=2009-02-14 |last=Ward Cunningham |access-date=2025-02-06 |via=YouTube}}</ref><ref>{{Cite web |title=Ward Explains Debt Metaphor |url=https://wiki.c2.com/?WardExplainsDebtMetaphor |access-date=2025-02-06 |website=wiki.c2.com |quote=The explanation I gave to my boss, and this was financial software, was a financial analogy I called "the debt metaphor". And that said that if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan.}}</ref>
<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 or otherwise.<ref name='oopsla92'>{{cite web|url=http://c2.com/doc/oopsla92.html|title=The WyCash Portfolio Management System|date=1992-03-26|access-date=2008-09-26|first1=Ward |last1=Cunningham|author-link=Ward Cunningham}}</ref></blockquote>
Similar concepts had existed before this. In 1980, Meir "Manny" Lehman had published a similar law using an "architectural metaphor" for the deteriorating nature of software. Manny's Law states: "As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it."<ref>{{cite journal|last1=Lehman|first1=MM|title=Laws of Software Evolution Revisited|journal=EWSPT '96 Proceedings of the 5th European Workshop on Software Process Technology|date=1996|pages=108–24|isbn=9783540617716 |url=http://dl.acm.org/citation.cfm?id=681473|access-date=19 November 2014}}</ref>
==Causes== {{expand section|date=February 2025}} Common causes of technical debt include:
; Pressure to minimize development time: An ever-present aspect of business.
; Unexpected and ill-defined features and changes: The implementation of last-minute specification changes or changes that are insufficiently documented or tested,{{r|SuryanarayanaSamarthyam2014|p=4}}{{r|Sterling2010|p=22}}{{r|RiosNicolliSpínolaMendonçaSeaman2018}}
; Gaps in knowledge or skills: May manifest as a lack of process understanding, insufficient knowledge, poor technological leadership, or inadequate mentoring or knowledge sharing practices.<ref name="Sterling2010">{{cite book|author=Chris Sterling|title=Managing Software Debt: Building for Inevitable Change (Adobe Reader)|url=https://books.google.com/books?id=LYQlOaRwpnEC&pg=PA17|date=10 December 2010|publisher=Addison-Wesley Professional|isbn=978-0-321-70055-1|page=17}}</ref>{{r|Sterling2010|p=17}}
; Issues in the development process: Such as sub-optimal solutions, insufficient requirements (from process inefficiencies), conflicting requirements on parallel branches, deferred refactoring, or delayed upstream contributions.<ref name="RiosNicolliSpínolaMendonçaSeaman2018">{{Cite book |last1=Rios |first1=Nicolli |last2=Spínola |first2=Rodrigo Oliveira |last3=Mendonça |first3=Manoel |last4=Seaman |first4=Carolyn |chapter=The most common causes and effects of technical debt: First results from a global family of industrial surveys |date=2018-10-11 |title=Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement |chapter-url=https://doi.org/10.1145/3239235.3268917 |series=ESEM '18 |location=New York, NY, USA |publisher=Association for Computing Machinery |pages=1–10 |doi=10.1145/3239235.3268917 |isbn=978-1-4503-5823-1}}</ref>{{r|Sterling2010|p=29}}
; Non-compliance with best practice: Such as insufficient software documentation, poor collaboration practices, lack of ownership, rewrites for outsourced software, inadequate attention to code quality, tightly coupled components, lack of a test suite, or failure to align to standards (including ignoring industry standard frameworks).<ref name="SuryanarayanaSamarthyam2014">{{cite book|author1=Girish Suryanarayana|author2=Ganesh Samarthyam|author3=Tushar Sharma|title=Refactoring for Software Design Smells: Managing Technical Debt|url=https://books.google.com/books?id=1SaOAwAAQBAJ&pg=PA3|date=11 November 2014|publisher=Elsevier Science|isbn=978-0-12-801646-6|page=3}}</ref>{{r|SuryanarayanaSamarthyam2014|p=7}}{{r|Sterling2010}}
==Consequences== {{expand section|date=February 2025}} By increasing the cost of ongoing maintenance, technical debt makes it harder to predict release schedules. "Interest payments" result from incomplete work and escalating integration costs due to changes in the upstream project. Increases in complexity and the amount of uncompleted work make it increasingly difficult to accurately estimate effort, resulting in delays, missed deadlines, and stress on engineering teams, which can result in higher staff turnover, compounding the problem.<ref>{{cite book|last1=Ali|first1=Junade|title=Mastering PHP Design Patterns {{!}} PACKT Books|date=September 2016|publisher=Packt Publishing Limited|location=Birmingham, England, UK|isbn=978-1-78588-713-0|page=11|edition=1|url=https://www.packtpub.com/application-development/mastering-php-design-patterns|access-date=11 December 2017|language=en|archive-date=1 June 2020|archive-url=https://web.archive.org/web/20200601123650/https://www.packtpub.com/application-development/mastering-php-design-patterns|url-status=dead}}</ref> Carrying technical debt into production can significantly increase the risk of system outages, financial losses, and legal complications due to breached service-level agreements. Additionally, future refactoring efforts may become more complex and costly, with changes to production code posing higher risks of disruption.<ref>{{cite journal |title=Characteristics, causes, and consequences of technical debt |journal=ScienceDirect |url=https://www.sciencedirect.com/science/article/pii/S0164121223001206 |access-date=2026-05-05}}</ref>
Poor source code quality causes plenty of headaches, overworked days, and sleepless nights for developers and product owners alike. If the quality of the source code is left to deteriorate, adding new features becomes increasingly difficult, bug fixes take up more time, and future development estimations become less accurate. This can lead to missed deadlines, reduced productivity, and a negative impact on user satisfaction and business outcomes.<ref>{{cite web |title=5 Great PHP Code Analysis Tools Recommended by Developers |url=https://www.rabitsolutions.com/blog/5-php-code-analysis-tools/ |website=Rabit Solutions Blog |access-date=2026-05-05}}</ref>
Failure to address technical debt can cause productivity to decline and slow down the delivery of features. The cumulative effects of technical debt result in increasingly fragile systems that can make bold improvements difficult. The domination of incremental changes, along with delays to critical refactoring, can result in stressed systems with inconsistent design, causing users to suffer from degraded performance and limited functionality while developers struggle to maintain quality.<ref name="Girish 2014"/><ref name="rtp">{{cite book|isbn=978-0-321-21335-8|first=Joshua|last=Kerievsky|title=Refactoring to Patterns|year=2004|publisher=Addison-Wesley }}</ref>
==Planning== {{expand section|date=February 2025}}
Kenny Rubin uses the following categories to help manage technical debt:<ref name="Essential Scrum: Velocity">{{Citation |last=Rubin |first=Kenneth |title=Essential Scrum. A Practical Guide to the Most Popular Agile Process |date=2013 |page=155 |publisher=Addison-Wesley |language=EN |isbn=978-0-13-704329-3}}</ref>
; Happened-upon: The development team was unaware it 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: Known to the development team and has been made visible using one of many approaches.
; Targeted: Known and has been targeted for servicing by the development team.
==Limitations== The concept of technical debt presumes that an overly-expedient development effort results in additional future costs and that the costs would be avoided if different decisions were made during the effort. While true, other considerations impact the potential cost of expedient development decisions. For example, if the system does not survive long enough to be modified for a subsequent release, then the savings due to the expedient development choices are true savings since there is no future development cost.<ref name="Fowler">{{Cite web |last=Fowler |first=Martin |title=Technical Debt |url=https://martinfowler.com/bliki/TechnicalDebt.html |website=martinfowler.com}}</ref> Future events may render expedient "long-term" designs obsolete.<ref name="FowlerQuadrant">{{Cite web |last=Fowler |first=Martin |title=Technical Debt Quadrant |url=https://martinfowler.com/bliki/TechnicalDebtQuadrant.html |website=martinfowler.com}}</ref> New tools and techniques might reduce the cost of future rework, challenging current debt assumptions.<ref name="FowlerQuadrant" />
==See also== {{div col}} * {{Annotated link |Anti-pattern}} * {{Annotated link |Bus factor}} * {{Annotated link |Code smell}} * {{Annotated link |Escalation of commitment}} * {{Annotated link |Manumation}} * {{Annotated link |Overengineering}} * {{Annotated link |Software brittleness}} * {{Annotated link |Software maintenance}} * {{Annotated link |Software rot}} * {{Annotated link |Spaghetti code}} * {{Annotated link |SQALE}} * {{Annotated link |Sunk cost}} * TODO (tag) {{endash}} Source code comment often used to indicate technical debt * {{Annotated link |Tyranny of small decisions}} {{div col end}}
==References== <references/>
==External links== * Experts interviews on Technical Debt: [https://web.archive.org/web/20120621171342/http://blog.techdebt.org/resources-links/67/ward-cunningham-interview-about-technical-debt-sqale-agile Ward Cunningham], [https://web.archive.org/web/20120717083235/http://blog.techdebt.org/interviews/156/interview-with-philippe-kruchten-on-technical-debt-rup-ubc-decision-process-architecture Philippe KRUCHTEN], [https://web.archive.org/web/20121129073247/http://blog.techdebt.org/interviews/189/technical-debt-interview-with-ipek-ozkaya-on-technical-debt-sei-ieee-software-architecture-agile Ipek OZKAYA], [https://web.archive.org/web/20120714053317/http://blog.techdebt.org/interviews/118/interview-with-jean-louis-letouzey-on-technical-debt-and-sqale Jean-Louis LETOUZEY] * [http://www.construx.com/10x_Software_Development/Technical_Debt/ Steve McConnell discusses technical debt] * [https://www.linkedin.com/pulse/averting-technical-debt-crisis-part-1-doug-knesek Averting a "Technical Debt" Crisis] by Doug Knesek * David E. Boundy, [http://dl.acm.org/citation.cfm?id=156632 Software cancer: the seven early warning signs], ACM SIGSOFT Software Engineering Notes, Vol. 18 No. 2 (April 1993), Association for Computing Machinery, New York, New York, US
Category:Metaphors Category:Software architecture Category:Software engineering terminology Category:Software maintenance