Technical debt (TD) is a metaphor used in software engineering to describe a situation where a non-optimal solution is used in a technical decision during software development.
The metaphor was first coined in 1992 by Ward Cunningham, when he described technical debt as follows:
‘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)
The original definition by Ward Cunningham (1992) shows that technical debt as a metaphor describes a situation in software development where implementing non-optimal code can speed up development in the short term, but in the long term it can incur a risk, if these non-optimal solutions are not fixed. Michael Lutz (1993) states that it is important for software companies to borrow time sometimes to get a product to market, but it will include an interest later on.
“Just as new firms borrow capital to get started, new software projects borrow ‘design capital’ (time) to get a product to market. Maintenance problems that ensue are the interest you pay for design errors introduced by schedule pressure” – Michael Lutz (1993)
Martin Fowler (2003) has simplified the metaphor later, as he describes technical debt ultimately as a decision between a messy solution done quick versus a clean solution done with time. Steve McConnell (2008) emphasizes in his own technical debt definition the perspective on cost, where implementing a non-optimal design or construct can have an
impact on future work, where it will take more time and resources to repay than it would take if done immediately.
‘You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place. – Martin Fowler (2003)
‘A design or construction approach that's expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time)’ – Steve McConnell (2008)
Technical debt can be a useful metaphor in communicating about software and its quality between technical staff, but interestingly it can also be used as an important technical concept for non-technical stakeholders (McConnell, 2007). Therefore, technical debt has been tried to be explained and defined through other domains, such as finance (Allman, 2012). Martin Fowler (2003) suggests that technical debt can be explained through finance debt because both share similar main properties.
‘Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.’ – Martin Fowler (2003)
Technical debt has three main attributes that are similar to financial debt: Repayment, interest and high cost (Allman, 2012). These attributes are used to define technical debt in a non-technical manner (Allman, 2012). In a financial debt, the person who grants the loan has the expectation that the debt will get repaid as soon as possible or in a given deadline. With a debt, there is often an interest included, which is some percentage that has to be paid with the debt. A person often pays the debt back on a monthly basis, until the whole debt has been paid back. However, it is also possible that the person is not able to fulfil the repayment, which then results in e.g. bankruptcy. A similar situation can happen also in software development with technical debt. A developer implements a non-optimal code or design approach and decides to incur some technical debt. With this debt, the developer can usually finalize the current urgent development task. There is an expectation in the software project that the debt will be fixed as soon as possible to avoid later consequences. In software development, shortcuts and workarounds in the code can start to omit overall quality, because it generates complexity (Lim et al., 2012). The time required to improve this omitted quality can be seen as a principal. In software development, when too much technical debt has been taken and not repaid in time, the overall quality can decrease under a certain level, where it may not be possible to do any changes to the software without breaking it, due to complexity. In worst cases, this could mean the end of the software, similar to bankruptcy.
In the past few years, the definition of technical debt has evolved from its origin (Tom et al., 2013). There exists a number of different definitions and opinions of technical debt in the academic literature at the moment (Tom et al., 2013). Tom et al. (ibid.) have conducted a systematic literature review (SLR) to explore the current understanding on technical debt. The results showed that technical debt as a definition can have multiple meanings in the literature, which can make it a challenging metaphor to define and discuss. Although most definitions of technical debt are still referred to as design and implementation related issues, similarly to the original definitions (Cunningham, 1992;
Fowler, 2003; McConnell, 2008), there are some questions about the definition (Tom et al., 2013). Since the original definitions of technical debt did not take an accurate stand on what the actual technical debt is in software, it has generated a lot of confusion to the terminology (Tom et al., 2013) concerning technical debt. According to some definitions, technical debt should be everything ‘incomplete’ in software ( ibid.). However, some definitions do not agree that e.g. defects and bugs should be included in technical debt (Li et al., 2015; McConnell, 2007; Tom et al., 2013). In addition, the original definition indicated that technical debt happens as part of software implementation (Cunningham, 1992). However, today several definitions also take in consideration other stages of software development (Tom et al., 2013). Therefore, the current definition of technical debt in the academic literature can be considered incoherent, requiring more research and discussion to reach a common consensus.
To address the issue of definition, the most recent notable definition of technical debt was developed in April 2016, when a technical debt seminar gathered technical debt researchers together to discuss the current status of technical debt. As a result, the definition of technical debt was refined, and it can be seen as the latest attempt to simplify the metaphor (Avgeriou et al., 2016):
“In software-intensive systems, technical debt consists of design or implementation constructs that are expedient in the short term, but set up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability.”
Overall, the technical debt metaphor unites the technical and economic perspectives of software development. Even though technical debt can be considered as a technical approach in code design or implementation (Avgeriou et al., 2016; Cunningham, 1992;
McConnell, 2008), it also includes economical aspects related to time and cost (McConnell, 2008). Some of the definitions of technical debt take account of a more technical perspective with technical attributes of software, while some discuss economic perspectives with attributes like people and social aspects of software development (Alves et al., 2016; Li et al., 2015; Tom et al., 2013). At the moment, there is not necessarily one accepted definition available for technical debt. This suggests that technical debt is a complicated phenomenon in software development that requires more research and understanding to reach a consensus on its definition in the academia and in practice.