Technical Debt: Broadening Perspectives
Report on the Seventh Workshop on Managing Technical Debt (MTD 2015) Paris Avgeriou
University of Groningen Groningen, NL
paris@cs.rug.nl
Neil A. Ernst, Robert L. Nord
Software Engineering Institute Pittsburgh, PA, US
nernst, rn@sei.cmu.edu
Philippe Kruchten
University of British Columbia Vancouver, BC, CA
philippe@kruchten.ca
ABSTRACT
Increasingly software engineers use the metaphor of technical debt to communicate issues related to the growing cost of change. In this article, we report on the Seventh Workshop on Managing Technical Debt (MTD 2015), held in Bremen, Germany, on October 2, 2015, collocated with the International Conference on Software Maintenance and Evolution (ICSME). The 30 workshop participants from industry and academia engaged in lively discussions, which helped clarify issues, refine questions, and promote common understanding about technical debt in software.
Categories and Subject Descriptors
D.2.7 [Software Engineering]: Distribution, Maintenance, and Enhancement – restructuring.
General Terms
Management, Measurement, Design, Economics
Keywords
Technical Debt, Software Quality, Software Evolution, Software Economics
1.! INTRODUCTION
The metaphor of technical debt introduced by Ward Cunningham in 1992 [3] has recently spawned an entire movement in software engineering research and practice. Steve McConnell defines technical debt as “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” [10].
Researchers in this area have met regularly since 2010, in the workshop series on Managing Technical Debt (MTD), to further study and better define the concept and its applicability to software development.
Discussion in these workshops has focused in large part on what should be considered debt. For example, participants of the second MTD workshop debated questions such as whether to treat defects as technical debt or whether a lack of documentation constitutes technical debt [11].
The third workshop on technical debt aimed to address this confusion by delineating a technical debt landscape [8]. The fourth edition made further progress toward a crisper definition of technical debt [7], while the fifth one focused on existing lines of research in software engineering and how they form the basis on which technical-debt research can develop [5].
Last year during the sixth edition, the conversation shifted to the issue of how we might, as a community, move past the definitional stage. The nature of the main discussion topics was a sign of a field reaching a level of maturity; examples included benchmarks or gold standards, reaching out to other communities, and reused code [12]. A follow-up article [1]
summarized the state of the art in the topic and the future directions regarding the management process, the intrinsic link with software economics, the urgency to treat technical debt at the architecture level and through empiricism and data science, and finally the need to teach it in school.
This article reports the results and discussion from the seventh MTD workshop—held in conjunction with the International Conference on Software Maintenance and Evolution (ICSME) 2015 in Bremen, Germany, on October 2, 2015. Proceedings available at http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=7321917
2.! CONTRIBUTIONS
We started the workshop with an excellent keynote from Prof. Arie van Deursen, from Delft University of Technology, titled “Lehman vs.
Lehman: Dealing with Debt.” His talk covered the notion of software evolution in the context of legacy systems (from the work of Lazlo Belady and Manny Lehman [2]) and rampant framework usage. Arie raised the question of whether breaking API changes constitutes technical debt. This positions technical debt as a knowledge problem, namely, how to cope as new knowledge emerges. Arie’s slides are available:
https://speakerdeck.com/avandeursen/lehman-versus-lehman-dealing- with-debt
The workshop then continued with two presentation sessions, with 7 minutes for presentation, then 8 minutes of managed discussion (available from http://www.sei.cmu.edu/community/td2015/program) from authors of accepted papers:
•! Andreas Reichel, “Towards an Open-Source Tool for Measuring and Visualizing the Interest of Technical Debt” [13]
•! Andreas Reichel, “Validating and Prioritizing Quality Rules for Managing Technical Debt: An Industrial Case Study” (Joint Presentation) [18]
•! Emad Shihab, “Detecting and Quantifying Different Types of Self-Admitted Technical Debt” [14]
•! Francesca Arcelli Fontana, “Towards a Prioritization of Code Debt: A Code Smell Intensity Index” [15]
•! Mário André Freitas Farias, “A Contextualized Vocabulary Model for Identifying Technical Debt on Code Comments”
[16]
•! Ulf Eliasson, “Identifying and Visualizing Architectural Debt and Its Efficiency Interest in the Automotive Domain: A Case Study” [17]
•! Birgit Vogel-Heuser, “Technical Debt in Automated Production Systems” [19]
•! Areti Ampatzoglou, “Estimating the Breaking Point for Technical Debt” [20]
•! Attila Kovács, “Technical Debt of Standardized Test Software”
[21]
•! Marko Leppänen, “Decision-Making Framework for Refactoring” [22]
•! Carlos Fernández-Sánchez, “An Analysis of the Elements of Technical Debt Management” [23]
DOI: 10.1145/2894784.2894800 http://doi.acm.org/10.1145/2894784.2894800
ACM SIGSOFT Software Engineering Notes Page 38 March 2016 Volume 41 Number 2
•! Raul Zablah, “The Restructuring and Refinancing of Technical Debt” [24]
After a break, we continued with discussion sessions, which we summarize in Section 3. Following the discussions, we heard from Jean- Louis Letouzey, who is chairing an Agile Alliance program on agile software and technical debt. Find out more about this program at http://www.agilealliance.org/programs/technical-debt/
3.! DISCUSSION
An important aspect of the MTD series is the opportunity to engage in discussion about how participants view technical debt, both from research and practice perspectives.
3.1! Theme 1 – Defects and Interest
Motivating questions: Are defects used in interest calculation all equally important? How should we prioritize them?
Defect proneness, change proneness, and cost of change are often used as indicators of technical debt. Participants at the workshop focused on the issue of defects to get insight into measuring the interest accrued by technical debt. In previous workshops, we established that the presence of defects are not in themselves technical debt [7]. Low external quality visible to the user in the form of defects should not be considered as technical debt, rather as possible symptoms or interest. Most defects have an immediate impact on the value of the product and need to be resolved immediately, while it is possible to delay paying off technical debt (principal). Thus, time is an important factor to qualify technical debt.
Much centers around the definition of defect, of course: defects that have complex remediation strategies can be candidate technical-debt items, and some organizations track technical debt in this fashion (using bug trackers, for example [4]).
Thus, not all defects used in interest calculation are equally important.
Prioritizing involves considering a number of properties of the defect including severity, risk, impact, amount of change, cost of change, and added value (the positive side of risk to turn it into an opportunity to learn). There are a number of stakeholder perspectives to consider.
Priority comes from the customer since someone has to pay for it, whether fixing defects or paying the interest. The business is involved in providing features and controlling development costs. Customers may see defects as being of interchangeable importance, desiring simply to fix the most defects for the lowest costs. They may not see the relationships among the defects as engineers do or the need to understand technical dependency. For example, if engineers address duplicate code first, then they can fix defects within the code once rather than multiple times.
Once the important defects are recognized, then the tradeoff can be analyzed whether to make the fix (pay off the debt) or keep the debt (and make interest payments). This tradeoff can be characterized in a two- dimensional chart with variations of business value and cost of change on the axes to support a shift of thinking to making decisions that obtain the highest return on investment. Ampatzoglou et al. presented an interesting paper showing a model that did exactly this, and an open question was whether the response curve – business value to cost of change – was constant, linear, or exponential. In other words, as interest accumulates, does the cost grow beyond the rate of interest; that is, does it compound? Participants agreed that the answer likely depended on the type of interest and debt, but that there are empirical observations of hard crashes induced by technical debt, similar to mortgage defaults.
3.2! Theme 2 – Decisions in Retrospect
Motivating question: Is making a decision that, in retrospect, is wrong or suboptimal technical debt?
There are occasions when, at the time a decision is made, it seems like the right or optimal choice. However, in the course of time, the decision proves to be problematic, but this is only evident in hindsight. This was extensively exemplified during the keynote session: the use of third-party libraries may seem like an optimal choice at a given point of time, but
after a few releases, they cause maintenance and evolution issues. Then the development team needs to decide whether they want to upgrade the library and spend the effort to update the rest of the system or leave it as is (“if it ain’t broke don’t fix it”). The workshop debated whether such decisions constitute technical debt or not, as elaborated in the following two paragraphs.
It is not technical debt: Such decisions do not have the typical characteristics of technical debt. First, there is no compromise involved;
the development team did not try to cut corners or do a workaround to avoid spending effort. There was no explicit or implicit choice between doing the right thing (taking the optimal alternative) and following a quick-and-dirty approach. Furthermore, the team did not really benefit by incurring debt: there was no short-time gain in development effort, time, or budget because of the workaround. Finally, the development team performed due diligence; they looked into the problem and solution space and made what they thought was a good decision; they could not have predicted the future.
It is technical debt: Such decisions have the typical aftermath of technical debt. Specifically, these decisions put the team in a difficult position as the architecture, code, requirements, and other elements are “not quite right,” so they need to be fixed. In other words, the system now has an issue that causes maintenance or evolution overhead, and it has become more expensive to change the system because of this issue. This is the definition of interest on technical debt. Eventually, the team will need to apply typical solutions for paying back debt, like refactoring.
The workshop reached the verdict that the answer to the question has a temporal dependency: a) it was not technical debt at the point of time in the past when the decision was made; b) it becomes technical debt at the moment you know about it and need to make the decision of either fixing it or not. This distinction is aligned with the previous discussions in the MTD series of workshops, where it was agreed that not everything should be technical debt to avoid losing the value of the metaphor [7]. Thus, we avoid calling it technical debt for the time before the issue becomes explicit, as any decision can be potentially suboptimal for a future iteration. But it should become a technical debt item and added to the backlog as soon as it becomes an explicit issue that causes overhead in maintenance and evolution.
3.3! Theme 3 – Other Domains
Motivating question: Does the technical debt metaphor apply to other domains?
Participants of the workshop have worked with domains of systems comprised of mechanical, electrical, electronic, and software components, so we discussed the application of technical debt in these domains. We confirmed the existence of technical debt in the aforementioned domains by finding instances of various types of technical debt that have been identified in the software domain [9]:
•! Documentation/design/engineering debt: when architecture- related or otherwise significant information remains implicit and is never documented or incorporated into the design
•! Requirements debt: when requirements are vague or ill-defined
•! Social/organization debt: when team members are not assigned to roles in an optimal way and end up underperforming or not optimally using their skills
The concepts behind the technical debt metaphor in the software realm also seem to apply in the electrical, mechanical, and electronics domains.
Engineers must make compromises because of business goals and organizational constraints. These compromises take a form very familiar to software engineers: cutting corners during any phase of the engineering lifecycle and not spending the required R&D resources to get the job done right. Participants gave several examples of engineers who made a decision and then simply stopped exploring the design space, hoping that it would somehow work out in the future. Anecdotal reports
ACM SIGSOFT Software Engineering Notes Page 39 March 2016 Volume 41 Number 2
from the workshop participants suggest that even though the concepts related to technical debt (and the resulting pain) in the aforementioned disciplines are well known and understood, the term itself is unknown and therefore not used. In addition to the term technical debt, the term refactoring is also unknown in other domains, which usually call this concept re-engineering or optimization.
An interesting notion that the software technical-debt community has not discussed is that of technical debt crossing multiple disciplines. In this sense, technical debt is incurred in one discipline, but it burdens and has to be repaid in another discipline. As an example, consider a manufacturer who decides to buy cheap hardware, hoping that any negative consequences on performance or reliability will be resolved in the software. After all, industry maintains the assumption that manufacturing is expensive while software is cheap, although this balance seems to be visibly shifting. This cross-disciplinary technical debt happens mostly because in a multidisciplinary system, the different disciplines operate largely as “islands,” optimizing only within the disciplinary boundaries and ignoring potential consequences for other disciplines. The only aspect of this kind of interdisciplinary technical debt that is being actively research is the detection of inconsistencies between disciplines: as soon as these inconsistencies become explicit and prove to hurt maintenance, they become technical debt.
One important difference between technical debt in software and other disciplines is the time when consequences start to manifest. In the software domain, technical debt hurts the maintainability and evolvability of the software system by making it hard to make changes in future iterations. In other disciplines, technical debt may also hurt the same iteration as the one that incurs it by raising production costs. For example, choosing the wrong cable may cause the manufacturing process to become costlier.
4.! Theme 4 – Technical Debt and Refactoring
Motivating Question: How does refactoring influence technical debt?
Refactoring was a big focus of Arie van Deursen’s opening keynote, and the workshop discussed how refactoring was involved in reducing technical debt. Refactoring typically refers to improving code’s internal quality without affecting external functionality, but even in [3]
Cunningham seems to use the term refactoring to mean improving the design of the software, which could encompass external quality as well.
Another question was the difference between so-called floss and big- bang refactoring. Floss refactoring characterizes the small, daily changes programmers should make to improve code quality (like nightly flossing of teeth, hence, the name). Big-bang refactoring, by contrast, is closer to efforts that could also be termed re-architecting or re-engineering. We discussed to what extent refactoring could remedy the interest (e.g., defects) or principal (poor internal quality) of technical debt. Van Deursen made the point that refactoring technical debt greatly depends on the knowledge you have about the system, particularly in systems that depend on external libraries. For instance, you may have included a library version that contains a known exploit.
Workshop participants agreed that iterative refactoring as ongoing effort was better than big-bang refactoring sprints. We saw this activity as a better way to eliminate technical debt, foregoing for as long as possible the need for large-scale rewrites.
5.! CONCLUSIONS
This seventh version of the workshop was an excellent opportunity to bring different viewpoints together—industry, research, those new to the area, and those with different perspectives. It represented a broadening of the enthusiasm seen for the area of technical debt. While there was the perhaps inevitable discussion of the definition of the metaphor, there was also much work that leveraged the concept to build practical tools for solving real problems, whether they take the form of test prioritization, supply-chain management, self-admitted code comments, or other solutions.
6.! ACKNOWLEDGMENTS
Thanks to the organizers of ICSME 2015, our host conference, and in particular Rainer Koschke, general chair of ICSME, for facilitating this workshop. Thanks to the session chairs, and in particular to the attendees for the stimulating day of discussion and presentation. We look forward to seeing you at the Eighth International Workshop on Managing Technical Debt in conjunction with ICSME 2016, in Raleigh, NC.
7.! DISCLAIMER
Copyright 2015 ACM. This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721- 05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. [Distribution Statement A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for non-US Government use and distribution. DM- 0003103
8.! REFERENCES
[1]! Avgeriou, P., Kruchten, P., Nord, R. L., Ozkaya, I., and Seaman, C. 2016. Reducing friction in software development. IEEE Software 33, 1 (Jan. 2016).
[2]! Belady, L. and Lehman, M. M. 1976. A model of large program development. IBM Syst. J. 15, 3 (Sep. 1976), 225-252.
[3]! Cunningham, W. 1992. The WyCash Portfolio Management System. In OOPSLA’ 92 Experience Report (Vancouver, CA, Oct.
18-22, 1992). ACM, New York, NY, 29-30.
[4]! Ernst, N., Bellomo, S., Ozkaya, I., Nord, R., and Gorton, I. 2015.
Measure it? Manage it? Ignore it? Software practitioners and technical debt. In SIGSOFT Conference on Foundations of Software Engineering (Bergamo, IT, Aug. 30-Sep. 4, 2015).
[5]! Falessi, D., Kruchten, P., Nord, R. L., and Ozkaya, I. 2014.
Technical debt at the crossroads of research and practice: report on the 5th International Workshop on Managing Technical Debt.
ACM SIGSOFT 39, 2 (Mar. 2014), 31-33.
[6]! Kruchten, P., Nord, R. L., and Ozkaya, I. 2012. Technical debt:
from metaphor to theory and practice. IEEE Software 29, 6 (Nov./Dec. 2012), 18-21.
[7]! Kruchten, P., Nord, R. L., Ozkaya, I., and Falessi, D. 2013.
Technical debt: towards a crisper definition; report on the 4th International Workshop on Managing Technical Debt. ACM SIGSOFT 38, 5 (Aug. 2013), 51-54.
[8]! Kruchten, P., Nord, R. L., Ozkaya, I., and Visser, J. 2012.
Technical debt in software development: from metaphor to theory;
report on the Third International Workshop on Managing Technical Debt. ACM SIGSOFT 37, 5 (Sep. 2012), 36-38.
[9]! Li, Z., Avgeriou, P., and Liang, P. 2015. A systematic mapping study on technical debt and its management. J. Syst. Softw. 101 (Mar. 2015), 193-220.
[10]!McConnell, S. 2011. Managing Technical Debt. Webinar. Sep.
2011. Available from
http://www.youtube.com/watch?v=lEKvzEyNtbk
[11]!Ozkaya, I., Kruchten, P., Nord, R., and Brown, N. 2011. Managing technical debt in software development: report on the 2nd
International Workshop on Managing Technical Debt, held at ICSE 2011. ACM SIGSOFT 36, 5 (Sep. 2011), 33-35.
[12]!Seaman, C., Nord, R. L., Kruchten, P., and Ozkaya, I. 2015.
Technical debt: beyond definition to understanding: report on the Sixth International Workshop on Managing Technical Debt. ACM SIGSOFT 40, 2 (Mar. 2015), 32-34.
[13]!Falessi D., Reichel A. 2015. Towards an open-source tool for measuring and visualizing the interest of technical debt.
ACM SIGSOFT Software Engineering Notes Page 40 March 2016 Volume 41 Number 2
International Workshop on Managing Technical Debt (Bremen, DE, Oct 2 2015), 1-8
[14]!da Maldonado, E., Shihab E. 2015. Detecting and quantifying different types of self-admitted technical Debt. International Workshop on Managing Technical Debt (Bremen, DE, Oct 2 2015), 9-15
[15]!Fontana F., Ferme V., Zanoni M., Roveda R. 2015. Towards a prioritization of code debt: A code smell Intensity Index.
International Workshop on Managing Technical Debt (Bremen, DE, Oct 2 2015), 16-24
[16]!Farias M. A. F., Neto M. G. M., da Silva A., Spínola R. 2015. A Contextualized Vocabulary Model for identifying technical debt on code comments. International Workshop on Managing Technical Debt (Bremen, DE, Oct 2 2015), 25-32
[17]!Eliasson U., Martini A., Kaufmann R., Odeh S. 2015. Identifying and visualizing Architectural Debt and its efficiency interest in the automotive domain: A case study. International Workshop on Managing Technical Debt (Bremen, DE, Oct 2 2015), 33-40 [18]!Falessi D., Voegele A. 2015. Validating and prioritizing quality
rules for managing technical debt: An industrial case study.
International Workshop on Managing Technical Debt (Bremen, DE, Oct 2 2015), 41-48
[19]!Vogel-Heuser B, Rösch S, Martini A, Tichy M. 2015. Technical debt in Automated Production Systems. International Workshop on Managing Technical Debt (Bremen, DE, Oct 2 2015), 49-52 [20]!Chatzigeorgiou A, Ampatzoglou A, Ampatzoglou A, Amanatidis
T. 2015. Estimating the breaking point for technical debt.
International Workshop on Managing Technical Debt (Bremen, DE, Oct 2 2015), 53-56
[21]!Szabados K, Kovács A. Technical debt of standardized test software. International Workshop on Managing Technical Debt (Bremen, DE, Oct 2 2015), 57-60
[22]!Leppänen M, Lahtinen S, Kuusinen K, Mäkinen S, Männistö T, Itkonen J, Yli-Huumo J, Lehtonen T. 2015. Decision-making framework for refactoring. International Workshop on Managing Technical Debt (Bremen, DE, Oct 2 2015), 61-68
[23]!Fernandez-Sanchez C, Garbajosa J, Yagüe A. 2015. A framework to aid in decision making for technical debt management.
International Workshop on Managing Technical Debt (Bremen, DE, Oct 2 2015), 69-76
[24]!Zablah R, Murphy C. 2015. Restructuring and refinancing technical debt. International Workshop on Managing Technical Debt (Bremen, DE, Oct 2 2015), 77-80
