technical debt

The concept of “technical debt” was first coined by Ward Cunningham in 1992.{{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}} After reading Metaphors We Live By, Ward devised this "debt metaphor" to explain to his boss the need to refactor the financial product they were working on.{{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}}{{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.}} He wrote that:

{{quotation |"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."{{cite web|url=http://c2.com/doc/oopsla92.html|title=The WyCash Portfolio Management System|date=1992-03-26|access-date=2008-09-26|author=Ward Cunningham|author-link=Ward Cunningham}} |Ward Cunningham}}

Similar concepts had existed before this. In 1980, Manny Lehman had published a similar law using an "architectural metaphor" for the deteriorating nature of software. Manny's Law states that:

{{quotation |"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it."{{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–124|isbn=9783540617716 |url=http://dl.acm.org/citation.cfm?id=681473|access-date=19 November 2014}} |Meir Manny Lehman}}

It is important to understand that software architecture has been contrasted with civil engineering since the 1960s.{{Cite web |last=NATO SCIENCE COMMITTEE |date=January 1969 |title=SOFTWARE ENGINEERING |url=http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF |access-date=February 7, 2025 |website=School of Computing at the University of Newcastle |quote=»… software designers are in a similar position to architects and civil engineers, particularly those concerned with the design of large heterogeneous constructions, such as towns and industrial plants. It therefore seems natural that we should turn to these subjects for ideas about how to attack the design problem.}}

{{expand section|date=February 2025}}

;Frequent causes of technical debt

• Pressures by businesses to release sooner
• 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, which may manifest as a lack of process understanding, insufficient knowledge, poor technological leadership, or inadequate mentoring or knowledge sharing practices.{{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}}{{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.{{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}}{{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
• the lack of a test suite, or
• failure to align to standards (including ignoring industry standard frameworks).{{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}}{{r|SuryanarayanaSamarthyam2014|p=7}}{{r|Sterling2010}}

{{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.{{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}} Carrying technical debt into production increases the risk of outages, financial losses, and potential legal issues due to breached service-level agreements. Future refactoring becomes riskier and costlier, with modifications to production code introducing greater chances of disruption.{{Citation needed|date=February 2025}}

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.{{cite book|isbn=978-0-321-21335-8|first=Joshua|last=Kerievsky|title=Refactoring to Patterns|year=2004|publisher=Addison-Wesley }}

{{expand section|date=February 2025}}

Kenny Rubin uses the following categories to help manage technical debt:{{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}}

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

The concept of technical debt assumes that an expedient design saves present costs at the expense of higher future costs. While often valid, this premise relies on assumptions that may not always hold, such as the assumption that the product must survive long enough for the deferred work to matter, {{Cite web |last=Fowler |first=Martin |title=Technical Debt |url=https://martinfowler.com/bliki/TechnicalDebt.html |website=martinfowler.com}} or that future events or advancements may render expedient and "long-term" designs obsolete, {{Cite web |last=Fowler |first=Martin |title=Technical Debt Quadrant |url=https://martinfowler.com/bliki/TechnicalDebtQuadrant.html |website=martinfowler.com}} or that new tools and techniques might reduce the cost of future rework, challenging current debt assumptions.

Given the uncertainty of the future, what appears to be technical debt today may ultimately prove to be an example of savings. Furthermore, traditional calculations of technical debt tend to focus only on development time, overlooking broader costs such as training and onboarding when debt affects code readability, {{Cite web |title=Software Maintenance Costs: How to Estimate and Optimize |url=https://www.scnsoft.com/software-development/maintenance-and-support/costs |website=ScienceSoft}} licensing, tools, and infrastructure needed to manage or resolve the debt, {{Cite web |title=Estimating Total Cost of Ownership (TCO) |url=https://galorath.com/blog/total-cost-of-ownership/ |website=Galorath|date=11 February 2022 }} and opportunity costs related to delayed features or lost market opportunities.

Without accounting for these factors, technical debt assessments risk oversimplifying complex trade-offs, leading to suboptimal decisions.

{{div col}}

• Code smell
• Big ball of mud
• Bus factor
• Escalation of commitment
• Manumation
• Overengineering
• Shotgun surgery
• Software rot
• Spaghetti code
• SQALE
• Sunk cost
• TODO, FIXME, XXX

{{div col end}}

• 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
• Boundy, David, [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