Better Projects: Technical Debt: A Systems Perspective

by Kelsey van Haaster

Abstract

The term technical debt is usually associated only with badly written or designed source code. It is thought of as an engineering problem and described analogously as like accumulating financial debt. Recently the practitioner and research communities have begun taking a broader view of what should and should not be called technical debt. Approaches for identifying, analysing and managing technical debt are being developed and the problem of how the metaphor is best used to communicate the impacts, broader risks and issues to non-technical decision makers

Keywords: Technical debt, Software Development, Software Governance

Introduction

The term technical debt describes the result of trade-offs and compromises made between the multiple dimensions and demands inherent in a software engineering project. First coined in 1992 by Ward Cunningham the metaphor is used to explain the possible consequences of choosing not to do various internal things for various reasons. Used specifically in reference to the quality aspects of the software architecture and development processes it allows a comparison to be drawn between the result of deferring technical decisions to a later time and accumulating financial debt. (Cunningham, 2013)

There is some discussion amongst members of both the software practitioner and the academic research communities about the kinds of deferred activities which should be described as technical debt (Buschmann, 2011) It is also argued that the technical debt/financial debt metaphor is inadequate and over simplifies a complex problem (Siebra et al., 2012). This paper provides an introduction to the term technical debt and its manifestations and provides an overview of recent thinking and emergent research directions on the topic.

What is technical debt?

In its simplest form the term technical debt refers to architectural and engineering shortcuts, taken deliberately, in order to meet a more pressing business need. Technical debt does not usually include as yet undeveloped features or functions but refers to inadequacies in already developed or partially developed functionality.

Technical debt is repaid usually with interest in exactly the same way that financial debt is, but there is a key difference. Financial debt has two well understood dimensions: the amount owing and its cost to repay over time, consequently when you take on financial debt, the total cost of that debt over time is either known or can be calculated. This is where the simple version of the metaphor breaks down: when technical debt is accumulated without a full understanding of its potential costs, it would be better compared with a stock trading metaphor such as taking an unhedged call option (Freeman, 2013).

Technical debt can be accumulated by every dimension of a software development project, including: system architectures, code, requirements, testing, end user documentation, project management and software governance. Like financial debt, it can be both deliberately and inadvertently accrued.

What kinds of technical debt are there?

Figure 1 The Technical Debt Quadrant

In his 2007 blog post, Steve McConnell (McConnell, 2013) builds on the financial metaphor by describing technical debt terms of both short term and long term debt. Short term debt, in financial terms represents a decision to put an item on a credit card in order to take advantage of interest free days; whereas long term debt represents such things as purchasing a property via a mortgage. Martin Fowler proposes the technical debt quadrant which categorises both the deliberate and inadvertent acquisition of technical debt, as reckless or prudent, according to the justification for accumulating it (Fowler, 2013).

Long term technical debt can be accumulated as part of a deliberate and strategic decision; an example might be that a company may decide to release a product for only one platform which meets the needs of most of its existing customers. The decision may be made in the full knowledge that work to support alternate platforms will need to be done in the future, before new markets can be explored. In this scenario, the deliberate and prudent accumulation of technical debt can pay dividends especially where it allows an organisation to gain an advantage over their competition, or secure an existing customer base. However, these kinds of decisions will always be trade-off between what is known at a given point in time and the risk that new information will emerge which had it been available earlier would have resulted in a different decision (Lim, Taksande, & Seaman, 2012).

Inadvertently acquired long term technical debt can also be the result of what appeared to be prudent decision making based on the information available at a given point in time. One such example of this is where a software product has been heavily customised to suit particular customers, making it very difficult for those customers to migrate to a newer version of the product. The outcome of this scenario is an ongoing need to support legacy products which have increasing maintenance costs. This is a particularly difficult problem especially, where it impacts a teams’ capacity to deliver a higher quality and more maintainable product (Klinger, Tarr, Wagstrom, & Williams, 2011).

Particularly in Agile projects, the prudent and deliberate acquisition of short term technical debt is the expected result of emergent and evolving requirements and implementation choices which support the rapid delivery of a solution in order to gain rapid feedback. There is an expectation that there will be the need to continuously refactor and refine in order to produce a high quality product. Agile methodologies incorporate concepts such as refactoring, continuous improvement and automated regression testing as mitigation strategies and provided that development teams understand the consequences of the choices they are making and are able to employ these debt mitigation strategies the short term advantages of taking on this kind of debt outweigh the risks (Lim et al., 2012).

Examples of short term, inadvertently acquired technical debt are the kinds of problems which are the result of inadequate or undocumented requirements, poor test coverage, poor quality code or sloppy practices. This kind of debt is can remain invisible or be ignored for a considerable time. Analogous with maxing out a credit card this kind of behaviour is always reckless and attracts interest which becomes payable by slowing down a team’s velocity (Kaiser & Royse, 2011).

What are the causes of technical debt?

The different kinds of technical debt have different causes, signs, symptoms and costs. In the article, Technical Debt in the Code, Dan O’Neil describes three groups of conditions which when they occur can result in the accumulation of technical debt. Management debt triggers include tight and highly prioritised completion schedules, squeezed budgets and poor communication between management and engineering. Engineering triggers include poor architectural design, product complexity, inadequate requirements and poor domain knowledge. Process triggers include, poor project management, a lack of metrics, poor adherence to standards and inadequate test coverage (O'Neill, 2013). Examples of other technical debt triggers are the cascade effect of decisions made in other projects or in the wider organisation which result in changes to deadlines or resourcing. Ad- hoc decision making processes and the lack of an effective way to communicate with different stakeholder groups about technical debt and its impact (Klinger et al., 2011).

In new to Agile software development teams, technical debt can be accumulated as a result of teams transitioning to Agile without the benefit of experience in techniques such as Test Driven Development (TDD). Cultural reasons, such as lack of colocation, or poor understanding of Agile principles and practices can also present a problem (Bavani, 2012). Organisational culture can also play a significant role; where an organisation has a blame culture identifying technical debt can be a particular challenge (Kaiser & Royse, 2011).

What are the signs and symptoms of technical debt?

Whilst technical debt is often the result of decisions other than technical ones, its symptoms and the costs associated with it are always evident in the engineering aspects of a software development project (Lim et al., 2012). For example; where the architecture of a system forces developers to violate the principles of good object oriented software design, code is copied, rather than reused and as a consequence the system becomes fragile and hard to change (Gourly, 2013). Where testing skills or resources are scarce or are inadequate or where test automation is not available, code test coverage suffers, resulting in higher defect counts (Bavani, 2012).

Measuring and Costing Technical Debt

Understanding and identifying that a software development project is being negatively impacted by technical debt is the first step towards remediating it. The next challenge is to measure the size and cost of the debt before deciding whether and how it should be paid off.

Measuring technical debt and calculating its cost is subject of several recent studies which present methodological approaches. Examples of these are ; “The Software Quality Assessment Based on Lifecycle Expectations” (SQALE) method, (Letouzey, 2012) which describes the use of the source tools provided by SonarQube ("SonarQube™," 2013) to measure a software system against a set of quality indices. These include; reusability, portability, maintainability, security, efficiency, changeability, reliability and testability. The SQALE method assigns a remediation value, measured in days to each instance of a violation of one of the quality indices, so assigning a cost to fix the technical debt.

The use of automated tools and concepts such as code smells (Guo, Seaman, Zazworka, & Shull, 2010) are effective ways to quantitatively identify and measure the technical symptoms of technical debt. However the discussion amongst both the professional and research communities, has recently focussed on the need for broader measures.

In ‘A Case Study on Effectively Identifying Technical Debt’ (Zazworka et al., 2013) the effectiveness of the human identification of technical debt was compared to the use of tool based analysis. Whilst the tool based analysis was more effective, against the metrics selected, the identification and analysis of technical debt by the human participants which was not identified through the tools. This study highlighted the idea that not all technical debt should be treated equally.

A number of studies suggest a theory based approach to identifying, analysing and managing technical debt, these include; “Managing Technical Debt in Practice: An Industrial Report “(Siebra et al., 2012). This is experiential report which used the decision making process used to assess technical debt at Samsung to develop and test a theory to which could be used to guide the assessment process in the future. The assessment of technical debt using a meaningful taxonomy in conjunction with a financial cost is supported by the identification of the following dimensions of technical debt described in detail in, “Managing Technical Debt in Software Systems” (Brown et al., 2010) and summarised in the following table.

Dimension	Explanation
Visibility	To what extent is there a shared and accurate understanding of the scope and size of the debt?
Value	What is the difference between the potential value of the product in its current state and its ideal state?
Present Value	How much pain is it causing you now?
Debt Accretion	What is the rate of software decay as a result of the technical debt?
Environment	Is it actually good enough?
Origin	Is it deliberately or inadvertently acquired debt?
Impact	Is it localised to one area or aspect of a system or widely distributed?

Figure 2 The Dimensions of Technical Debt

Once you have identified a technical debt what are the options?

The inadequacy of the financial/technical debt metaphor becomes apparent when deciding how technical debt should be managed. There is a general view amongst software professionals that technical debt is an unavoidable reality of software engineering (Lim et al., 2012) as well as an assumption that like financial debt, technical debt must come due for payment. More recently however a view which challenges this assumption has emerged (Buschmann, 2011).

Technical debt like financial debt can be paid out, (paying principle and interest); it can be serviced and not paid out, (interest only). Technical debt differs significantly from financial debt in that it can be simply retired and never paid because when a product reaches the end of its life and is retired; any technical debt carried by the product and the process of supporting it simply disappears.

Technical debt can be repaid with interest where it makes sense to do so, a number of studies have looked at ways of doing this including an approach to making the extent and location of the engineering (code quality) problems in a product visible in order to promote awareness of the problem and encourage discussion about how and why the debt accumulated in the first place (Kaiser & Royse, 2011).

Technical debt can be refinanced, that is converted to something with lower interest rates, which may be cheaper from a longer term business perspective. In “ To Pay or Not to Pay Technical Debt” (Buschmann, 2011) argues that once both business and technical considerations have been applied it may be sensible conclude that the benefits of re-architecting or refactoring a system are not worth the risks or the costs of doing so.

Conclusion

The technical debt/financial debt metaphor has been around for some time and is relevant to all software engineering projects regardless of their methodological approach. The interest from the research community with regard to the adequacy of the metaphor as a guideline for managing technical debt is more recent. Recent research into the topic reveals the need for additional work to develop a set of heuristics which can be used to measure and assess technical debt. Any heuristic developed must take both the business and technical perspectives into consideration. Another challenge is developing effective ways of communicating the extent and possible impact of technical debt to the non-technical stakeholders, who must understand the issue in order to make sensible decisions about how or whether it should be accrued and managed.