MTD '15: "Estimating the Breaking Point ..."
Estimating the Breaking Point for Technical Debt
Alexander Chatzigeorgiou, 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.
@InProceedings{MTD15p53,
author = {Alexander Chatzigeorgiou and Apostolos Ampatzoglou and Areti Ampatzoglou and Theodoros Amanatidis},
title = {Estimating the Breaking Point for Technical Debt},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {53--56},
doi = {},
year = {2015},
}
MTD '15: "Estimating the Breaking Point ..."
Estimating the Breaking Point for Technical Debt
Alexander Chatzigeorgiou, 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.
@InProceedings{MTD15p53,
author = {Alexander Chatzigeorgiou and Apostolos Ampatzoglou and Areti Ampatzoglou and Theodoros Amanatidis},
title = {Estimating the Breaking Point for Technical Debt},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {53--56},
doi = {},
year = {2015},
}
MTD '15: "Estimating the Breaking Point ..."
Estimating the Breaking Point for Technical Debt
Alexander Chatzigeorgiou, 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.
@InProceedings{MTD15p53,
author = {Alexander Chatzigeorgiou and Apostolos Ampatzoglou and Areti Ampatzoglou and Theodoros Amanatidis},
title = {Estimating the Breaking Point for Technical Debt},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {53--56},
doi = {},
year = {2015},
}
MTD '15: "Estimating the Breaking Point ..."
Estimating the Breaking Point for Technical Debt
Alexander Chatzigeorgiou, 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.
@InProceedings{MTD15p53,
author = {Alexander Chatzigeorgiou and Apostolos Ampatzoglou and Areti Ampatzoglou and Theodoros Amanatidis},
title = {Estimating the Breaking Point for Technical Debt},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {53--56},
doi = {},
year = {2015},
}
MTD '15: "Detecting and Quantifying ..."
Detecting and Quantifying Different Types of Self-Admitted Technical Debt
Everton da S. Maldonado and Emad Shihab
(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.
@InProceedings{MTD15p9,
author = {Everton da S. Maldonado and Emad Shihab},
title = {Detecting and Quantifying Different Types of Self-Admitted Technical Debt},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {9--15},
doi = {},
year = {2015},
}
MTD '15: "Identifying and Visualizing ..."
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.
@InProceedings{MTD15p33,
author = {Ulf Eliasson and Antonio Martini and Robert Kaufmann and Sam Odeh},
title = {Identifying and Visualizing Architectural Debt and Its Efficiency Interest in the Automotive Domain: A Case Study},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {33--40},
doi = {},
year = {2015},
}
MTD '15: "Validating and Prioritizing ..."
Validating and Prioritizing Quality Rules for Managing Technical Debt: An Industrial Case Study
Davide Falessi 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.
@InProceedings{MTD15p41,
author = {Davide Falessi and Alexander Voegele},
title = {Validating and Prioritizing Quality Rules for Managing Technical Debt: An Industrial Case Study},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {41--48},
doi = {},
year = {2015},
}
MTD '15: "Towards an Open-Source Tool ..."
Towards an Open-Source Tool for Measuring and Visualizing the Interest of Technical Debt
Davide Falessi 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.
@InProceedings{MTD15p1,
author = {Davide Falessi and Andreas Reichel},
title = {Towards an Open-Source Tool for Measuring and Visualizing the Interest of Technical Debt},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {1--8},
doi = {},
year = {2015},
}
MTD '15: "A Contextualized Vocabulary ..."
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.
@InProceedings{MTD15p25,
author = {Mário André de Freitas Farias and André Batista da Silva and Manoel Gomes de Mendonça Neto and Rodrigo Oliveira Spínola},
title = {A Contextualized Vocabulary Model for Identifying Technical Debt on Code Comments},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {25--32},
doi = {},
year = {2015},
}
MTD '15: "Towards a Prioritization of ..."
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.
@InProceedings{MTD15p16,
author = {Francesca Arcelli Fontana and Vincenzo Ferme and Marco Zanoni and Riccardo Roveda},
title = {Towards a Prioritization of Code Debt: A Code Smell Intensity Index},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {16--24},
doi = {},
year = {2015},
}
MTD '15: "A Framework to Aid in Decision ..."
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.
@InProceedings{MTD15p69,
author = {Carlos Fernández-Sánchez and Juan Garbajosa and Agustín Yagüe},
title = {A Framework to Aid in Decision Making for Technical Debt Management},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {69--76},
doi = {},
year = {2015},
}
MTD '15: "Towards a Prioritization of ..."
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.
@InProceedings{MTD15p16,
author = {Francesca Arcelli Fontana and Vincenzo Ferme and Marco Zanoni and Riccardo Roveda},
title = {Towards a Prioritization of Code Debt: A Code Smell Intensity Index},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {16--24},
doi = {},
year = {2015},
}
MTD '15: "A Framework to Aid in Decision ..."
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.
@InProceedings{MTD15p69,
author = {Carlos Fernández-Sánchez and Juan Garbajosa and Agustín Yagüe},
title = {A Framework to Aid in Decision Making for Technical Debt Management},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {69--76},
doi = {},
year = {2015},
}
MTD '15: "Decision-Making Framework ..."
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.
@InProceedings{MTD15p61,
author = {Marko Leppänen and Samuel Lahtinen and Kati Kuusinen and Simo Mäkinen and Tomi Männistö and Juha Itkonen and Jesse Yli-Huumo and Timo Lehtonen},
title = {Decision-Making Framework for Refactoring},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {61--68},
doi = {},
year = {2015},
}
MTD '15: "Identifying and Visualizing ..."
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.
@InProceedings{MTD15p33,
author = {Ulf Eliasson and Antonio Martini and Robert Kaufmann and Sam Odeh},
title = {Identifying and Visualizing Architectural Debt and Its Efficiency Interest in the Automotive Domain: A Case Study},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {33--40},
doi = {},
year = {2015},
}
MTD '15: "Technical Debt of Standardized ..."
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.
@InProceedings{MTD15p57,
author = {Kristóf Szabados and Attila Kovács},
title = {Technical Debt of Standardized Test Software},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {57--60},
doi = {},
year = {2015},
}
MTD '15: "Decision-Making Framework ..."
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.
@InProceedings{MTD15p61,
author = {Marko Leppänen and Samuel Lahtinen and Kati Kuusinen and Simo Mäkinen and Tomi Männistö and Juha Itkonen and Jesse Yli-Huumo and Timo Lehtonen},
title = {Decision-Making Framework for Refactoring},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {61--68},
doi = {},
year = {2015},
}
MTD '15: "Decision-Making Framework ..."
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.
@InProceedings{MTD15p61,
author = {Marko Leppänen and Samuel Lahtinen and Kati Kuusinen and Simo Mäkinen and Tomi Männistö and Juha Itkonen and Jesse Yli-Huumo and Timo Lehtonen},
title = {Decision-Making Framework for Refactoring},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {61--68},
doi = {},
year = {2015},
}
MTD '15: "Decision-Making Framework ..."
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.
@InProceedings{MTD15p61,
author = {Marko Leppänen and Samuel Lahtinen and Kati Kuusinen and Simo Mäkinen and Tomi Männistö and Juha Itkonen and Jesse Yli-Huumo and Timo Lehtonen},
title = {Decision-Making Framework for Refactoring},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {61--68},
doi = {},
year = {2015},
}
MTD '15: "Decision-Making Framework ..."
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.
@InProceedings{MTD15p61,
author = {Marko Leppänen and Samuel Lahtinen and Kati Kuusinen and Simo Mäkinen and Tomi Männistö and Juha Itkonen and Jesse Yli-Huumo and Timo Lehtonen},
title = {Decision-Making Framework for Refactoring},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {61--68},
doi = {},
year = {2015},
}
MTD '15: "Decision-Making Framework ..."
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.
@InProceedings{MTD15p61,
author = {Marko Leppänen and Samuel Lahtinen and Kati Kuusinen and Simo Mäkinen and Tomi Männistö and Juha Itkonen and Jesse Yli-Huumo and Timo Lehtonen},
title = {Decision-Making Framework for Refactoring},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {61--68},
doi = {},
year = {2015},
}
MTD '15: "Decision-Making Framework ..."
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.
@InProceedings{MTD15p61,
author = {Marko Leppänen and Samuel Lahtinen and Kati Kuusinen and Simo Mäkinen and Tomi Männistö and Juha Itkonen and Jesse Yli-Huumo and Timo Lehtonen},
title = {Decision-Making Framework for Refactoring},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {61--68},
doi = {},
year = {2015},
}
MTD '15: "Identifying and Visualizing ..."
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.
@InProceedings{MTD15p33,
author = {Ulf Eliasson and Antonio Martini and Robert Kaufmann and Sam Odeh},
title = {Identifying and Visualizing Architectural Debt and Its Efficiency Interest in the Automotive Domain: A Case Study},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {33--40},
doi = {},
year = {2015},
}
MTD '15: "Technical Debt in Automated ..."
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.
@InProceedings{MTD15p49,
author = {Birgit Vogel-Heuser and Susanne Rösch and Antonio Martini and Matthias Tichy},
title = {Technical Debt in Automated Production Systems},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {49--52},
doi = {},
year = {2015},
}
MTD '15: "Restructuring and Refinancing ..."
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.
@InProceedings{MTD15p77,
author = {Raul Zablah and Christian Murphy},
title = {Restructuring and Refinancing Technical Debt},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {77--80},
doi = {},
year = {2015},
}
MTD '15: "A Contextualized Vocabulary ..."
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.
@InProceedings{MTD15p25,
author = {Mário André de Freitas Farias and André Batista da Silva and Manoel Gomes de Mendonça Neto and Rodrigo Oliveira Spínola},
title = {A Contextualized Vocabulary Model for Identifying Technical Debt on Code Comments},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {25--32},
doi = {},
year = {2015},
}
MTD '15: "Identifying and Visualizing ..."
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.
@InProceedings{MTD15p33,
author = {Ulf Eliasson and Antonio Martini and Robert Kaufmann and Sam Odeh},
title = {Identifying and Visualizing Architectural Debt and Its Efficiency Interest in the Automotive Domain: A Case Study},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {33--40},
doi = {},
year = {2015},
}
MTD '15: "Towards an Open-Source Tool ..."
Towards an Open-Source Tool for Measuring and Visualizing the Interest of Technical Debt
Davide Falessi 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.
@InProceedings{MTD15p1,
author = {Davide Falessi and Andreas Reichel},
title = {Towards an Open-Source Tool for Measuring and Visualizing the Interest of Technical Debt},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {1--8},
doi = {},
year = {2015},
}
MTD '15: "Technical Debt in Automated ..."
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.
@InProceedings{MTD15p49,
author = {Birgit Vogel-Heuser and Susanne Rösch and Antonio Martini and Matthias Tichy},
title = {Technical Debt in Automated Production Systems},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {49--52},
doi = {},
year = {2015},
}
MTD '15: "Towards a Prioritization of ..."
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.
@InProceedings{MTD15p16,
author = {Francesca Arcelli Fontana and Vincenzo Ferme and Marco Zanoni and Riccardo Roveda},
title = {Towards a Prioritization of Code Debt: A Code Smell Intensity Index},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {16--24},
doi = {},
year = {2015},
}
MTD '15: "Detecting and Quantifying ..."
Detecting and Quantifying Different Types of Self-Admitted Technical Debt
Everton da S. Maldonado and Emad Shihab
(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.
@InProceedings{MTD15p9,
author = {Everton da S. Maldonado and Emad Shihab},
title = {Detecting and Quantifying Different Types of Self-Admitted Technical Debt},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {9--15},
doi = {},
year = {2015},
}
MTD '15: "A Contextualized Vocabulary ..."
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.
@InProceedings{MTD15p25,
author = {Mário André de Freitas Farias and André Batista da Silva and Manoel Gomes de Mendonça Neto and Rodrigo Oliveira Spínola},
title = {A Contextualized Vocabulary Model for Identifying Technical Debt on Code Comments},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {25--32},
doi = {},
year = {2015},
}
MTD '15: "A Contextualized Vocabulary ..."
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.
@InProceedings{MTD15p25,
author = {Mário André de Freitas Farias and André Batista da Silva and Manoel Gomes de Mendonça Neto and Rodrigo Oliveira Spínola},
title = {A Contextualized Vocabulary Model for Identifying Technical Debt on Code Comments},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {25--32},
doi = {},
year = {2015},
}
MTD '15: "Technical Debt of Standardized ..."
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.
@InProceedings{MTD15p57,
author = {Kristóf Szabados and Attila Kovács},
title = {Technical Debt of Standardized Test Software},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {57--60},
doi = {},
year = {2015},
}
MTD '15: "Technical Debt in Automated ..."
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.
@InProceedings{MTD15p49,
author = {Birgit Vogel-Heuser and Susanne Rösch and Antonio Martini and Matthias Tichy},
title = {Technical Debt in Automated Production Systems},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {49--52},
doi = {},
year = {2015},
}
MTD '15: "Validating and Prioritizing ..."
Validating and Prioritizing Quality Rules for Managing Technical Debt: An Industrial Case Study
Davide Falessi 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.
@InProceedings{MTD15p41,
author = {Davide Falessi and Alexander Voegele},
title = {Validating and Prioritizing Quality Rules for Managing Technical Debt: An Industrial Case Study},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {41--48},
doi = {},
year = {2015},
}
MTD '15: "Technical Debt in Automated ..."
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.
@InProceedings{MTD15p49,
author = {Birgit Vogel-Heuser and Susanne Rösch and Antonio Martini and Matthias Tichy},
title = {Technical Debt in Automated Production Systems},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {49--52},
doi = {},
year = {2015},
}
MTD '15: "A Framework to Aid in Decision ..."
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.
@InProceedings{MTD15p69,
author = {Carlos Fernández-Sánchez and Juan Garbajosa and Agustín Yagüe},
title = {A Framework to Aid in Decision Making for Technical Debt Management},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {69--76},
doi = {},
year = {2015},
}
MTD '15: "Decision-Making Framework ..."
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.
@InProceedings{MTD15p61,
author = {Marko Leppänen and Samuel Lahtinen and Kati Kuusinen and Simo Mäkinen and Tomi Männistö and Juha Itkonen and Jesse Yli-Huumo and Timo Lehtonen},
title = {Decision-Making Framework for Refactoring},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {61--68},
doi = {},
year = {2015},
}
MTD '15: "Restructuring and Refinancing ..."
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.
@InProceedings{MTD15p77,
author = {Raul Zablah and Christian Murphy},
title = {Restructuring and Refinancing Technical Debt},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {77--80},
doi = {},
year = {2015},
}
MTD '15: "Towards a Prioritization of ..."
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.
@InProceedings{MTD15p16,
author = {Francesca Arcelli Fontana and Vincenzo Ferme and Marco Zanoni and Riccardo Roveda},
title = {Towards a Prioritization of Code Debt: A Code Smell Intensity Index},
booktitle = {Proc.\ MTD},
publisher = {IEEE},
pages = {16--24},
doi = {},
year = {2015},
}