ICSME 2015 Workshops
2015 IEEE International Conference on Software Maintenance and Evolution (ICSME)
Powered by
Conference Publishing Consulting

2015 IEEE 7th International Workshop on Managing Technical Debt (MTD), October 2, 2015, Bremen, Germany

MTD 2015 – Proceedings

Contents - Abstracts - Authors
Online Calendar - iCal File
Twitter: https://twitter.com/IEEEICSME


Title Page

Message from the Chairs
Welcome to the Seventh International Workshop on Managing Technical Debt (MTD 2015), co-located with the 31st International Conference on Software Maintenance and Evolution (ICSME) in Bremen, Germany. MTD is collocated with ICSME for the second time. Technical debt is a metaphor that software developers and managers increasingly use to communicate key trade-offs related to time planning and quality issues. The Managing Technical Debt workshop series has, since 2010, brought together practitioners and researchers to discuss and define issues related to technical debt and how they can be studied. Workshop participants have reiterated the usefulness of the metaphor each year, shared emerging practices used in software development organizations, and emphasized the need for more research and better means for sharing emerging practices and results

Tools and Technical Debt
Fri, Oct 2, 11:00 - 12:30, GW2 B2900 (Chair: Robert Nord)

Towards an Open-Source Tool for Measuring and Visualizing the Interest of Technical Debt
Davide Falessi ORCID logo and Andreas Reichel
(California Polytechnic State University, USA; Mannheim University of Applied Sciences, Germany)
Current tools for managing technical debt are able to report the principal of the debt, i.e., the amount of effort required to fix all the quality rules violated in a project. However, they do not report the interest, i.e., the disadvantages the project had or will have due to quality rules violations. As a consequence, the user lacks support in understanding how much the principal should be reduced and why. We claim that information about the interest is, at least, as important as the information about the principal; the interest should be quantified and treated as a first-class entity like the principal. In this paper we aim to advance the state of the art of how the interest is measured and visualized. The goal of the paper is to describe MIND, an open-source tool which is, to the best of our knowledge, the first tool supporting the quantification and visualization of the interest. MIND, by analyzing historical data coming from Redmine and Git repositories, reports the interest incurring in a software project in terms of how many extra defects occurred, or will occur, due to quality rules violations. We evaluated MIND by using it to analyze a software project stored in a dataset of more than a million lines of code. Results suggest that MIND accurately measures the interest of technical debt.

Detecting and Quantifying Different Types of Self-Admitted Technical Debt
Everton da S. Maldonado and Emad Shihab ORCID logo
(Concordia University, Canada)
Technical Debt is a term that has been used to express non-optimal solutions during the development of software projects. These non optimal solutions are often shortcuts that allow the project to move faster in the short term, at the cost of increased maintenance in the future. To help alleviate the impact of technical debt, a number of studies focused on the detection of technical debt. More recently, our work shown that one possible source to detect technical debt is using source code comments, also referred to as self-admitted technical debt. However, what types of technical debt can be detected using source code comments remains as an open question. Therefore, in this paper we examine code comments to determine the different types of technical debt. First, we propose four simple filtering heuristics to eliminate comments that are not likely to contain technical debt. Second, we read through more than 33K comments, and we find that self-admitted technical debt can be classified into five main types - design debt, defect debt, documentation debt, requirement debt and test debt. The most common type of self-admitted technical debt is design debt, making up between 42% to 84% of the classified comments. Lastly, we make the classified dataset of more than 33K comments publicly available for the community as a way to encourage future research and the evolution of the technical debt landscape.

Towards a Prioritization of Code Debt: A Code Smell Intensity Index
Francesca Arcelli Fontana, Vincenzo Ferme, Marco Zanoni, and Riccardo Roveda
(University of Milano-Bicocca, Italy; University of Lugano, Switzerland)
Code smells can be used to capture symptoms of code decay and potential maintenance problems that can be avoided by applying the right refactoring. They can be seen as a source of technical debt. However, tools for code smell detection often provide far too many and different results, and identify many false positive code smell instances. In fact, these tools are rooted on initial and rather informal code smell definitions. This represents a challenge to interpret their results in different ways. In this paper, we provide an Intensity Index, to be used as an estimator to determine the most critical instances, prioritizing the examination of smells and, potentially, their removal. We apply Intensity on the detection of six well known and common smells and we report their Intensity distribution from an analysis performed on 74 systems of the Qualitas Corpus, showing how Intensity could be used to prioritize code smells inspection.

A Contextualized Vocabulary Model for Identifying Technical Debt on Code Comments
Mário André de Freitas Farias, André Batista da Silva, Manoel Gomes de Mendonça Neto, and Rodrigo Oliveira Spínola
(Federal Institute of Sergipe, Brazil; Federal University of Bahia, Brazil; Federal University of Sergipe, Brazil; FPC-UFBA, Brazil; Salvador University, Brazil)
Context: The identification of technical debt (TD) is an important step to effectively manage it. In this context, a set of indicators has been used by automated approaches to identify TD items, but some debt may not be directly identified using only metrics collected from the source code. Goal: In this work we propose CVM-TD, a model to support the identification of technical debt through code comment analysis. Method: we performed an exploratory study on two large open sources projects with the goal of characterizing the feasibility of the proposed model to support the detection of TD through code comments analysis. Results: The results indicate that (1) developers use the dimensions considered by CVM-TD when writing code comments, (2) CVM-TD provides a vocabulary that may be used to detect TD items, and (iii) the proposed model needs to be calibrated in order calibrated in order to reduce the difference between comments returned by the vocabulary and those that may indicate a TD item. Conclusion: Code comments analysis can be used to detect TD in software projects and CVM-TD may support the development team to perform this task.

Identifying and Visualizing Architectural Debt and Its Efficiency Interest in the Automotive Domain: A Case Study
Ulf Eliasson, Antonio Martini, Robert Kaufmann, and Sam Odeh
(Volvo, Sweden; Chalmers University of Technology, Sweden; University of Gothenburg, Sweden)
Architectural Technical Debt has recently received the attention of the scientific community, as a suitable metaphor for describing sub-optimal architectural solutions having short-term benefits but causing a long-term negative impact. We study such phenomenon in the context of Volvo Car Group, where the development of modern cars includes complex systems with mechanical components, electronics and software working together in a complicated network to perform an increasing number of functions and meet the demands of many customers. This puts high requirements on having an architecture and design that can handle these demands. Therefore, it is of utmost importance to manage Architecture Technical Debt, in order to make sure that the advantages of sub-optimal solutions do not lead to the payment of a large interest. We conducted a case study at Volvo Car Group and we discovered that architectural violations in the detailed design had an impact on the efficiency of the communication between components, which is an essential quality in cars and other embedded systems. Such interest is not studied in literature, which usually focuses on the maintainability aspects of Technical Debt. To explore how this Architectural Technical Debt and its interest could be communicated to stakeholders, we developed a visual tool. We found that not only was the Architectural Debt highly interesting for the architects and other stakeholders at VCG, but the proposed visualization was useful in increasing the awareness of the impact that Architectural Technical Debt had on efficiency.

Validating and Prioritizing Quality Rules for Managing Technical Debt: An Industrial Case Study
Davide Falessi ORCID logo and Alexander Voegele
(California Polytechnic State University, USA; Elsevier, Germany)
One major problem in using static analyzers to manage, monitor, control, and reason about technical debt is that industrial projects have a huge amount of technical debt which reflects hundreds of quality rule violations (e.g., high complex module or low comment density). Moreover the negative impact of violating quality rules (i.e., technical debt interest) may vary across rules or even across contexts. Thus, without a context-specific validation and prioritization of quality rules, developers cannot effectively manage technical debt. This paper reports on a case study aimed at exploring the interest associated with violating quality rules; i.e., we investigate if and which quality rules are important for software developers. Our empirical method consists of a survey and a quantitative analysis of the historical data of a CMMI Level 5 software company. The main result of the quantitative analysis is that classes violating several quality rules are five times more defect prone than classes not violating any rule. The main result of the survey is that some rules are perceived by developers as more important than others; however, there is no false positive (i.e., incorrect rule or null interest). These results pave the way to a better practical use of quality rules to manage technical debt and describe new research directions for building a scientific foundation to the technical debt metaphor.

Emerging Ideas in Technical Debt
Fri, Oct 2, 14:00 - 15:30, GW2 B2900 (Chair: Alexander Serebrenik)

Technical Debt in Automated Production Systems
Birgit Vogel-Heuser, Susanne Rösch, Antonio Martini, and Matthias Tichy
(TU München, Germany; Chalmers University of Technology, Sweden; University of Gothenburg, Sweden; University of Ulm, Germany)
The term technical debt borrowed from financial debt describes the long-term negative effects of sub-optimal solutions to achieve short-term benefits. It has been widely studied so far in pure software systems. However, there is a lack of studies on tech-nical debt in technical systems, which contain mechanical, electrical and software parts. Automated Production Systems are such technical systems. In this position paper, we introduce technical debt for Automated Production Systems and give examples from the different disciplines. Based on that description, we outline future research directions on technical debt in this field.

Estimating the Breaking Point for Technical Debt
Alexander ChatzigeorgiouORCID logo, Apostolos Ampatzoglou, Areti Ampatzoglou, and Theodoros Amanatidis
(University of Macedonia, Greece; University of Groningen, Netherlands)
In classic economics, when borrowing an amount of money that causes a debt to the issuer, it is not usual to have interest which can become larger than the principal. In the context of technical debt however, accumulated debt in the form of interest can in some cases quickly sum up to an amount that at some point, be-comes larger than the effort required to repay the initial amount of technical debt. In this paper we propose an approach for estimating this breaking point. Anticipating how late the breaking point is expected to come can support decision making with respect to investments on improving quality. The approach is based on a search-based optimization tool that is capable of identifying the distance of an actual object-oriented design to the corresponding optimum one.

Technical Debt of Standardized Test Software
Kristóf Szabados and Attila Kovács
(Eötvös Loránd University, Hungary)
Recently, technical debt investigations became more and more important in the software development industry. In this paper we show that the same challenges are valid for the automated test systems. We present an internal quality analysis of standardized test software developed by ETSI and 3GPP, performed on the systems publicly available at www.ttcn-3.org.

Decision-Making Framework for Refactoring
Marko Leppänen, Samuel Lahtinen, Kati Kuusinen, Simo Mäkinen, Tomi Männistö, Juha Itkonen, Jesse Yli-Huumo, and Timo Lehtonen
(Tampere University of Technology, Finland; University of Helsinki, Finland; Aalto University, Finland; Lappeenranta University of Technology, Finland; Solita, Finland)
Refactoring has been defined as improving code quality without affecting its functionality. When refactoring is overlooked in daily development, the likelihood of larger refactorings increases with time. Disadvantages of larger refactorings include that they disrupt the daily work, require additional planning effort, and often they need to be justified to stakeholders. In this paper, we investigate with interviews how professionals make refactoring decisions. As a result, we present a framework for decision making for larger refactoring operations describing the key stages in a refactoring workflow. Furthermore, one actual industry case of refactoring decision making is presented in detail.

A Framework to Aid in Decision Making for Technical Debt Management
Carlos Fernández-Sánchez, Juan Garbajosa, and Agustín Yagüe
(Technical University of Madrid, Spain)
Current technical debt management approaches mainly address specific types of technical debt. This paper introduces a framework to aid in decision making for technical debt management, and it includes those elements considered in technical debt management in the available literature, which are classified in three groups and mapped into three stakeholders’ points of view. The research method was systematic mapping. In contrast to current approaches, the framework is not constrained by a concrete type of technical debt. Using this framework it will be possible to build specific models to assist in decision making for technical debt management.

Working Session
Fri, Oct 2, 15:45 - 17:30, GW2 B2900 (Chair: Neil Ernst)

Restructuring and Refinancing Technical Debt
Raul Zablah and Christian Murphy
(University of Pennsylvania, USA)
Given the increasing importance of software to society, the issue of technical debt is becoming more pervasive in software development. Its implications range from incurring small amounts of technical debt to speed up development - a positive - to stalling and making development no longer possible - a huge negative. In this paper, we present a framework that attempts to refine the understanding of technical debt by tracing more links to the financial metaphor, specifically focusing on the concepts of restructuring and refinancing technical debt. This paper looks at technical debt as a leverage product that is contingent upon the liquidity of the debtor. From this perspective, it is then possible to more effectively assess the incurment of technical debt and also to more effectively strategize the use of leverage in software development - accounting for the respective risks and benefits it provides.

proc time: 0.67