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.
References
Cunningham,
W. (2013). The WyCash Portfolio Management System. Retrieved 19/07/2013, 2013, from http://c2.com/doc/oopsla92.html
Fowler,
M. (2013). The Technical Debt Quadrant.
Retrieved 19/07/201, from http://www.ontechnicaldebt.com/wp-content/uploads/2012/03/Technical-Debt-Quadrant-from-Martin-Fowler.png
Freeman,
S. (2013). Bad code isn’t Technical Debt, it’s an unhedged Call Option – Steve
Freeman. Retrieved 21/07/2013, from http://www.higherorderlogic.com/2010/07/bad-code-isnt-technical-debt-its-an-unhedged-call-option/
Gourly,
R. (2013). Technical Debt and Interest.
Retrieved from http://renegourley.wordpress.com/2011/08/09/technical-debt-and-interest/
McConnell,
S. (2013). Technical Debt-10x Software Development. Retrieved 20/07/2013, from http://www.construx.com/10x_Software_Development/Technical_Debt/
No comments:
Post a comment