Last updated on July 7th, 2021 at 10:47 am
Ward Cunningham coined the technical debt metaphor in the context of developing a software asset [Cunningham 1992] [Cunningham 2011]. He observed that when the development process leads to new learning, re-executing the development project—or parts of the project—could lead to a better result. For this reason, among others, newly developed operational software assets can contain or depend upon artifacts he regarded as technical debt. In hindsight, the developers recognize they could remove these artifacts altogether. Or they could replace them with more elegant, effective, or appropriate forms. In this way, they could enhance maintainability, defensibility, and extensibility. To deploy the asset in pre-hindsight condition would entail an obligation to return to it in the future to implement the improvements. That obligation is Cunningham’s conception of the asset’s technical debt.
In the decades since Cunningham coined the term, the meaning of technical debt has evolved. It now includes much more than Cunningham’s original concept. Martin Fowler developed a 2×2 matrix (which I interpret as Intentionality x Wisdom) that describes four different pathways that lead to technical debt creation. Cunningham’s concept corresponds to what Martin Fowler describes as, “now we know how we should have done it” [Fowler 2009].
At a conference in Dagstuhl, Germany (“Managing Technical Debt in Software Engineering”) in 2016, leading experts in software technical debt research developed a verbal definition of technical debt for software-intensive systems [Avgeriou 2016]:
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.
With the definition of technical debt enlarged in this way, software engineers can focus on instances of software technical debt that reduce enterprise productivity and agility. But is this definition sufficient as a foundation for enterprise policy? I explore that question in “A policymaker’s definition of technical debt.”
References
[Avgeriou 2016] Paris Avgeriou, Philippe Kruchten, Ipek Ozkaya, and Carolyn Seaman, eds. “Managing Technical Debt in Software Engineering,” Dagstuhl Reports, 6:4, 110–138, 2016.
Available: here; Retrieved: March 10, 2017.
[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.
- Metaphors and the term technical debt
- Technical debt in software engineering
- Exogenous technical debt
[Cunningham 2011] Ward Cunningham. “Ward Explains Debt Metaphor” (video; here; ).
- Metaphors and the term technical debt
- Technical debt in software engineering
- Exogenous technical debt
[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.
Available here; Retrieved January 10, 2016.
