=Paper=
{{Paper
|id=Vol-1771/paper14
|storemode=property
|title=Co-Existence of the 'Technical Debt' and 'Software Legacy' Concepts
|pdfUrl=https://ceur-ws.org/Vol-1771/paper14.pdf
|volume=Vol-1771
|authors=Johannes Holvitie,Sherlock Licorish,Antonio Martini,Ville Leppnen
|dblpUrl=https://dblp.org/rec/conf/apsec/HolvitieLML16
}}
==Co-Existence of the 'Technical Debt' and 'Software Legacy' Concepts==
https://ceur-ws.org/Vol-1771/paper14.pdf
1st International Workshop on Technical Debt Analytics (TDA 2016)
Co-Existence of the ‘Technical Debt’ and
‘Software Legacy’ Concepts
Johannes Holvitie∗ , Sherlock A. Licorish† , Antonio Martini‡ , and Ville Leppänen∗
∗ Turku Centre for Computer Science,
Software Development Laboratory & † University of Otago, ‡ Chalmers University of Technology,
University of Turku, Department of Information Science, Computer Science and Engineering,
Dept. of Information Technology, Dunedin, Otago, New Zealand Göteborg, Sweden,
Turku, Finland sherlock.licorish@otago.ac.nz antonio.martini@chalmers.se
{jjholv, ville.leppanen}@utu.fi
Abstract—‘Technical debt’ and ‘software legacy’ are concepts practitioners having communication issues or being unaware
that both discuss a state of software that is sub-optimal, time of all applicable best practices. In these scenarios, exercises to
constrained, and explain how this state can decrease an organi- enhance social togetherness and focused training, respectively,
zation’s development efficiency. However, there is significant con-
fusion in the way the software engineering community perceive can be utilized to reduce technical debt instances.
these concepts. In this paper we perform an initial examination Different strategies are required when dealing with legacy
of technical debt and software legacy concepts, and examine their software. Legacy software has a variety of definitions, but it
somewhat challenging co-existence. In motivating our work, we generally captures software artifacts which cannot be subjected
discuss previous survey results which show that practitioners to the same maintenance and management efforts as newly cre-
believe that technical debt largely emerges from software legacy.
We then identify sources of confusion in comparing popular ated artifacts [10]. In practice, these are often implementation
definitions of both concepts. Finally, we map the use of the ‘tech- artifacts which are old, undocumented and/or untested, and for
nical debt’ and ‘software legacy’ concepts in existing research. which the original developer is no longer available. This could
We conclude that structured co-existence of these terms can be be due to: (1) a new team has taken over in the organization,
pursued with mutually beneficial gains. or (2) the implementation has been acquired from somewhere
else. If we consider technical debt accumulated in a “delayed
I. I NTRODUCTION AND BACKGROUND
fashion” to capture sub-optimalities that emerge due to the
All software products are static. That is, after they have environment progressing around a static software product, we
been developed, prior to being extended or maintained at a could argue that legacy software is quite close conceptually to
later stage, they remain in the exact same state (formalized technical debt.
for technical debt by Schmid in [1]). The environment around In fact, we previously conducted a practitioner survey to
software development, however, is dynamic. Technologies, shed light into the accumulation and composition of technical
people, organizational structures and processes all change debt that software organizations face today. This survey was
over software development project duration. These variables, administered as a web-based questionnaire in Brazil, Finland,
and many others, can be seen to have a link back to the and New Zealand. We collected 184 responses from a diverse
static software product. For instance, consider the continued set of respondents using both agile and traditional development
updates to a technology that is used to implement a software methods in which the practitioners assumed several roles rang-
product: here the software product, for which development ing from developers to managers and client representatives.
has stopped, does not abide by the latest changes made to the We have discussed outcomes from the Finnish responses in
technology, and it becomes detached from the updates. Hence, more detail before [11], while a forthcoming article reviews
when software development is continued for this software the multi-national results. As part of the results, the multi-
product, we note that it has accumulated technical debt in a national data-set captured 69 descriptions of concrete technical
“delayed fashion”, as current assumptions (i.e. strategic and/or debt instances from the respondents.
accidental technical debt) do not apply to it. For the captured technical debt instance descriptions, Figure
From a management perspective, there are considerable 1 visualizes the distribution of the perceived origins of tech-
differences between immediate and delayed accumulation of nical debt. While these results are somewhat preliminary, for
technical debt. Immediate accumulation is affected mainly by over 75% of the instances, the indicated origins of technical
matters that reside within the producing organization and its debt are in software legacy. This indicates that practitioners
project. We may look into altering strategies and implementing perceive there to be a strong connection between ‘technical
new processes to affect the management of immediate, in- debt’ and ‘legacy software’. This outcome and the general
tended technical debt. Management of immediate, involuntary confusion around the technical debt and software legacy
(or unintended) debt is often more indirect. For example, concepts motivates us to examine these two domains together,
implementation and design quality issues often arise from to identify cross-compatible solutions and enhancements for
80
1st International Workshop on Technical Debt Analytics (TDA 2016)
both. Is not legacy
24%
Examining these two domains together, technical debt could
be seen to benefit from integration of legacy software man-
agement procedures, as this field has a very established status. Legacy from an earlier
team/invididual working on
the same project/product
However, several issues should be taken into account when 50%
Legacy from outside
the organization
(e.g. from an acquisition)
legacy software is integrated with technical debt management. 9%
Firstly, is legacy software only a component of technical debt
accumulated in “delayed fashion”? Arguably not, as the overall Legacy from an unrelated
project/product within
current state of the software product, to which legacy can the organization
17%
be a part, has an effect on technical debt accumulation and
management [12]. Hence, the domains seem to be distinctively Fig. 1. Origins of technical debt instances (N=78 as multiple origins were
different, which motivates us to explore these concepts. indicated for some of the 69 instances)
Second, legacy software is generally used as a negative term
for “derelict code”, while technical debt implies pursuing asset by providing insights into avenues for how the co-existence
management functions for sub-optimalities in varying software of the two concepts could be organized, and outline future
artifacts. Reviewing Figure 1, one identifies a potential danger directions.
in legacy being re-branded under the more favorable technical
debt concept. Here, the asset management possibilities are II. C LOSENESS OF THE T ECHNICAL D EBT AND L EGACY
left unexplored if legacy is not diligently converted into C ONCEPTS
technical debt instances enabling full management. Noting the To facilitate examining the closeness in definitions of the
unobtrusive nature of legacy software, this is not an easy task ‘technical debt’ and ‘legacy’ concepts, commonly accepted
to do, and having technical debt instances with varying levels definitions for both are provided in Table I. Due to space
of accuracy is bound to deteriorate technical debt management limitations, detailed descriptions and examples have been
efforts overall. excluded from the definitions.
Revisiting our position above, ‘software legacy’ and ‘tech- Reviewing Table I, we note that in Cunningham’s definition
nical debt’ are closely related and as such the software engi- [2] technical debt (TD) is created always when new code
neering community should pursue narrowing the gap between releases are made. The definition leaves very little room for
these fields. We make the first step towards bridging this gap “debt-free code". If the consensus from the legacy definitions
in this work. In the following section (Section II) we provide communicates that the “legacy" status is something the code
a short evaluation of the two concepts, examining similarities can only gain over time, being pristine at the time of im-
in their definitions. We next conduct a short mapping study plementation, then Cunningham’s definition clearly deviates
of the concepts’ joint use in contemporary research literature from this. However, Cunningham describes the effects of TD
in Section III. Finally, in Section IV we conclude this study as emergent from “not-quite-right code" which again is able
TABLE I. Definitions for the ‘Technical Debt’ and the ‘Software Legacy’ Concepts
Cunningham [2] McConnell [3] Dagstuhl 16162 [4]
Technical . . . Shipping first time code is like going into The first kind of technical debt . . . is incurred In software-intensive systems, technical debt
Debt debt. A little debt speeds development so unintentionally. . . . [It] is the non-strategic is a design or implementation construct that
long as it is paid back promptly with a result of doing a poor job. . . . this kind of is expedient in the short term, but sets up
rewrite. Objects make the cost of this trans- debt can be incurred unknowingly, for exam- a technical context that can make a future
action tolerable. The danger occurs when ple, your company might acquire a company change more costly or impossible. Technical
the debt is not repaid. Every minute spent that has accumulated significant technical debt is a contingent liability whose impact is
on not-quite-right code counts as interest on debt that you don’t identify until after the limited to internal system qualities, primarily
that debt. Entire engineering organizations acquisition. . . . maintainability and evolvability.
can be brought to a stand-still under the debt The second kind . . . is incurred intentionally.
load of an unconsolidated implementation, This commonly occurs when an organization
object-oriented or otherwise. makes a conscious decision to optimize for
the present rather than for the future. . . .
Bennett [5] Dayani-Fard [6] and Liu & al. [7] in [8] Sommerville [9]
Software “large software systems that we don’t know Legacy software systems . . . were developed Legacy systems are socio-technical
Legacy how to cope with but that are vital to our decades ago and have been continually mod- computer-based systems that have been
organization." . . . ified to meet changes in business require- developed in the past, often using older or
Moreover, many legacy systems are per- ments and computing platforms. The prolif- obsolete technology. These systems include
forming crucial work for their organization. eration of such systems is causing headaches not only hardware and software but also
Hence the decision on how to manage them for large organizations who find them costly legacy processes and procedures—old ways
is crucial: . . . the very future of the business to maintain and risky to evolve. [6] of doing things that are difficult to change
may be at stake. Legacy systems may rep- . . . many legacy systems remain supportive to because they rely on legacy software.
resent years of accumulated experience and core business functions and are indispens- Legacy systems are often business-critical
knowledge. able to the business. [7] systems. they are maintained because it is
too risky to replace them.
81
1st International Workshop on Technical Debt Analytics (TDA 2016)
to accommodate the effects of code that has transformed into TABLE II. Publications Matching Both the ‘Technical Debt’ and ‘Legacy’
“less-right code" overtime (i.e. legacy). Search Terms
McConnell’s definition [3] is more lenient towards “debt- Database Matches
free code" existing. Technical debt accumulation in both the ACM 2
unintentional and the intentional scenarios is immediately dblp 1
EBSCO 3
related to the software elements creation, and hence, disallows Elsevier (Science Direct) 33
degradation over time, however other (i.e. initially “debt-free”) IEEE (Xplore) 2
scenarios are not excluded. Also, the unintentional incurrence Springer (SpringerLink) 55
Thomson Reuters (WoS) 1
includes acquisition-based accumulation of technical debt, Wiley (WOL) 7
wherein, the acquisition decision can be a “non-strategic result total 104
of doing a poor job”. This can include legacy acquisition.
Finally, the recent Dagstuhl 16162 definition [4] explicitly (aged vs. contemporary) and scopes (solution vs. elements).
states that the software design or implementation construct has
been expedient in the short-term. This implies that software III. R EVIEW OF R ESEARCH ON T ECHNICAL D EBT AND
elements, from the beginning of their development, must have L EGACY C ONCEPTS
a state that, interdependent with other factors, can induce To understand the scale of joint use of the ‘technical debt’
sub-optimalities that contribute as technical debt. This, again, and ‘software legacy’ concepts in research (noted among
excludes legacy which is initially “debt-free”. The description industry practitioners), we performed a preliminary mapping
promotes technical debt to be a “contingent liability" with an study over popular publication databases. We used the search
impact on “internal system qualities". This can accommodate phrase "technical debt" AND "legacy". The soft-
effects commonly perceived for legacy software [8]. ware context was not explicitly interrogated, as both terms can
Moving to the lower half of Table I, we note that Bennett’s be seen to already limit the query outcomes. Table II shows the
definition of ‘legacy’ [5] focuses on the operation phase of the number of matches received for the range of popular databases.
software life-cycle [IEEE 12207-2008], and as such does not For the matched publications, we reviewed their contents
explain legacy’s emergence. However, the “how to cope with" and constructed an initial classification scheme based on
effect description for legacy is very similar to Cunningham’s how they handled the ‘technical debt’ and ‘legacy’ concepts
“stand-still". The similarity in effect descriptions continues in together. This classification is provided in Figure 2. Over half
Dayani-Fard’s definition [6]. Here, legacy effects encompass (N=55) of the matched publications discussed the ‘technical
problems that relate to proliferation of a system that has debt’ and ‘legacy’ concepts in separate sections of the pub-
been continuously developed over decades. With very little lications, and thus, were deemed Non-related. We could not
effort, this can be classified under the “contingent liability access a seventh (N=16) of the publications, which we plan
affecting evolvability" from the Dagstuhl 16162 definition [4] to further explore in a further systematic review. Two of the
for ‘technical debt’. matched publications were also duplicates.
Finally, Sommerville’s definition [9] expands ‘legacy’ to From the 104 matched publications, 31 discussed ‘technical
include socio-technical matters. That is, legacy systems include debt’ and ‘legacy’ concepts together. Our initial classification
processes and procedures which rely on the legacy software. for these matches shows that over a third of this amount
We note that a very similar association has also been found (N=12) discussed the concepts as comparable with each other.
for technical debt in the form of ‘social debt’ [13]. For example, in Kennedy et al. [14]: “This could also be
Reviewing the previous comparisons, we note that de- considered as paying off your technical debt. Try to get rid
pending on the interpretation of the definitions, the concepts of any legacy code and consider whether there are other ways
partially accommodate one another. The effects described for you can format your CSS in order to get the most out of
both the ‘technical debt’ and ‘software legacy’ concepts are a minimization algorithm or better rendering. . . ". A similar
similar. Arguably, this can be a source of confusion. However, portion of the studies (N=9) discussed legacy as an explicit
when it comes to emergence, only McConnell’s definition for cause for technical debt emergence. For example, in Knodel
technical debt can accommodate legacy (in a very limited et al. [15]: “. . . in particular for legacy systems, which have
fashion). The two concept’s differ here. a history of design decisions made in the past . . . inadequate
Technical debt seems to be associated with a level of for today’s requirements, and causing technical debt".
immediateness and clarity that implies the debt to be promptly The remainder of the matches conceptualized technical debt
manageable. That is, technical debt management requires and legacy along two threads. The first half (N=5) described
information that indicates a particular software element to legacy as a modifier of technical debt. Generally, this meant
be sub-optimal. For legacy, there is information indicating that existence of legacy software in the development orga-
a software solution (several software elements) to be sub- nization emphasized the negative effect caused by technical
optimal in the current context. That is, this context and solution debt. For example, in Shull et al. [16]: “If an organization
combination produces a sub-optimal outcome (this may again has a history of damaging cost overruns during maintenance
induce more technical debt). Hence, the connection between on a large legacy system, then they would be most interested
legacy and technical debt seems to be one of given contexts in controlling design debt by refactoring code that is brittle,
82
1st International Workshop on Technical Debt Analytics (TDA 2016)
of technical debt and legacy seem to be the main challenge
and strength for research conceptualization. This could be
an excellent starting point for facilitating the structured co-
existence of these concepts. The challenges presented by the
given similarity in the conceptualization of these concepts may
be reduced by providing clear definitions for each. We thus
look to pursue this opportunity, first by extending the mapping
work that is started here. Ideally, explicit definitions could lead
to a process whereby legacy could be transferred into technical
debt through a systematic approach.
In fact, the conceptual similarity could be exploited imme-
Fig. 2. Matched publications classified based on their relation to the ‘legacy’ diately. If the effects caused by legacy are comparable to those
concept (N = 104)
induced by technical debt, then this is a clear opportunity for
overly complex, or hard to maintain". Finally, the second half technical debt management to adapt suitable procedures from
(N=5) of publications emphasized an explicit difference be- the legacy domain. Software legacy has been an active research
tween ‘technical debt’ and ‘legacy’. For example, in Williams field for much longer than technical debt, and could thus yield
[17]: “Phases 1 and 2 address PCI DSS 3.1 [conversion from mature solutions for this issue. This would allow technical debt
a legacy system], while phases 3 and 4 address the technical researchers to direct more resources to the challenges that are
debt associated with neglecting this IT system". unique to this field.
Reviewing the matched studies above we note that there R EFERENCES
are a variety of contexts and ways with which technical debt
[1] K. Schmid, “A formal approach to technical debt decision making,” in
and legacy are joined in research. While most of these con- Proceedings of the 9th International ACM Sigsoft Conference on Quality
texts demonstrate an awareness of the concepts’ co-existence of Software Architectures. ACM, 2013, pp. 153–162.
(i.e. legacy may be both a modifier and a cause for technical [2] W. Cunningham, “The wycash portfolio management system,” ACM
SIGPLAN OOPS Messenger, vol. 4, no. 2, pp. 29–30, 1992.
debt), there are also combinations which seem to exclude [3] S. McConnell, “Technical debt,” 2007, 10x Software
either concept (i.e. if legacy is different from technical debt, Development Blog. Construx Conversations. URL=
then these concepts should not be compared). http://www.construx.com/10x_Software_Development/Technical_Debt/.
[4] P. Avgeriou, P. Kruchten, I. Ozkaya, and C. Seaman, “Managing
IV. S TRUCTURED C O -E XISTENCE OF T ECHNICAL D EBT Technical Debt in Software Engineering (Dagstuhl Seminar 16162),”
Dagstuhl Reports, vol. 6, no. 4, pp. 110–138, 2016. [Online]. Available:
AND L EGACY, AND F UTURE D IRECTIONS http://drops.dagstuhl.de/opus/volltexte/2016/6693
Reviewing the survey results in Section I, the comparison [5] K. Bennett, “Legacy systems: Coping with success,” IEEE software,
vol. 12, no. 1, pp. 19–23, 1995.
highlighting the closeness in definitions for ‘technical debt’ [6] H. Dayani-Fard and e. al, Legacy Software Systems: Issues, Progress
and ‘legacy’ concepts in Section II, and the current state of and Challenges. IBM: Technical Report TR-74.165-k, 1999.
compound use of the concepts in research mapped in Section [7] K. Liu and e. al, “Report on the first sebpc workshop on legacy systems.”
Durham University, 1998.
III, we may conclude that there is considerable interplay [8] R. S. Pressman, Software engineering: a practitioner’s approach. Pal-
between the technical debt and legacy domains. To this end, grave Macmillan, 2005.
we believe that these concepts may be substituted, which could [9] I. Sommerville, Software Engineering. International computer science
series. Addison Wesley, 2008.
be possible source of confusion. The research mapping further [10] M. Feathers, Working effectively with legacy code. Prentice Hall
highlighted this, where we found several different—partially Professional, 2004.
exclusive—considerations of technical debt and legacy. [11] J. Holvitie, V. Leppänen, and S. Hyrynsalmi, “Technical debt and
the effect of agile software development practices on it-an industry
The current state of obfuscation between the concepts is a practitioner survey,” in Managing Technical Debt (MTD), 2014 Sixth
potential challenge. Notably, technical debt research is trying International Workshop on. IEEE, 2014, pp. 35–42.
to come up with ways to identify, track, and manage concise [12] A. Nugroho, J. Visser, and T. Kuipers, “An empirical model of technical
debt and interest,” in Proceedings of the 2nd Workshop on Managing
technical debt instances, which would allow for technical debt Technical Debt. ACM, 2011, pp. 1–8.
to be managed in a systematic manner. We discussed in Section [13] D. A. Tamburri, P. Kruchten, P. Lago, and H. van Vliet, “What is social
I that there is a danger of legacy being re-branded as technical debt in software engineering?” in Cooperative and Human Aspects of
Software Engineering (CHASE), 2013 6th International Workshop on.
debt, which may be seen to have less negative connotations. IEEE, 2013, pp. 93–96.
As legacy implies a severely reduced level of clarity around a [14] A. Kennedy, I. De Leon, and D. Storey, Pro CSS for High Traffic
particular set of software elements, re-branding such elements Websites. Springer, 2011.
[15] J. Knodel and M. Naab, “What is the background of architecture?” in
as technical debt without a systematic procedure can severely Pragmatic Evaluation of Software Architectures. Springer, 2016, pp.
undermine technical debt management efforts. 11–20.
Moving forward, we argue that the co-existence of the two [16] F. Shull, D. Falessi, C. Seaman, M. Diep, and L. Layman, “Technical
debt: Showing the way for better transfer of empirical results,” in
concepts requires structuring in order to alleviate the possible Perspectives on the Future of Software Engineering. Springer, 2013,
confusion between their use, to allow for their concurrent use, pp. 179–190.
and to facilitate mutually beneficial research for these fields. [17] B. R. Williams, PCI DSS 3.1: The Standard That Killed SSL. Syngress,
2015.
According to our short review, the similarity in the effects
83