Technical debt is a metaphor in software engineering interpreted as a trade-off between short-term benefits of postponing development activities and long-term consequences of postponing those activities. Most of the research in technical debt literature focus on identifying technical debt, justifying what to include and what to exclude in the technical debt scope and how to deal with them: either to defer the development activity or to avoid debt. However, there are only a few studies which considered technical debt as a financial obligation. In this paper, we propose to record technical debt item in the balance sheet as a kind of liability. We also review the effect of having technical debt liabilities in the balance sheet.
{"title":"Adjusting the Balance Sheet by Appending Technical Debt","authors":"S. Akbarinasaji, A. Bener","doi":"10.1109/MTD.2016.14","DOIUrl":"https://doi.org/10.1109/MTD.2016.14","url":null,"abstract":"Technical debt is a metaphor in software engineering interpreted as a trade-off between short-term benefits of postponing development activities and long-term consequences of postponing those activities. Most of the research in technical debt literature focus on identifying technical debt, justifying what to include and what to exclude in the technical debt scope and how to deal with them: either to defer the development activity or to avoid debt. However, there are only a few studies which considered technical debt as a financial obligation. In this paper, we propose to record technical debt item in the balance sheet as a kind of liability. We also review the effect of having technical debt liabilities in the balance sheet.","PeriodicalId":371173,"journal":{"name":"2016 IEEE 8th International Workshop on Managing Technical Debt (MTD)","volume":"14 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117182568","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
This article reflects on experiences collected by doing technical debt assessments for many years as a primary job. It argues for a model that represents software source code and other informational artifacts as a graph with metadata describing these artifacts. Technical debt items are discovered with graph matching patterns that represent technical debt discovery patterns. These patterns automate manual work, avoid effort duplication, and boost assessment performance. The overall approach is illustrated with a prototype implementation and a case study.
{"title":"Practical Technical Debt Discovery by Matching Patterns in Assessment Graph","authors":"Andriy Shapochka, B. Omelayenko","doi":"10.1109/MTD.2016.7","DOIUrl":"https://doi.org/10.1109/MTD.2016.7","url":null,"abstract":"This article reflects on experiences collected by doing technical debt assessments for many years as a primary job. It argues for a model that represents software source code and other informational artifacts as a graph with metadata describing these artifacts. Technical debt items are discovered with graph matching patterns that represent technical debt discovery patterns. These patterns automate manual work, avoid effort duplication, and boost assessment performance. The overall approach is illustrated with a prototype implementation and a case study.","PeriodicalId":371173,"journal":{"name":"2016 IEEE 8th International Workshop on Managing Technical Debt (MTD)","volume":"29 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127791358","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
This paper is an industrial experience report of applying the "Specification by Example" methodology and test-driven development to the development of a core component of a healthcare product. The methods are mapped to the four quadrants of technical debt introduced by Martin Fowler in order to show how they can help to avoid the accumulation of technical debt. The resulting data show that a very low defect density can be achieved with these practices, which helps to avoid technical debt introduced for example by quick fixes during a late project phase. Performance indicators measured during development and system test are presented. These results are informally compared to approaches based on formal methods further indicating the advantage of the presented approach.
{"title":"How “Specification by Example” and Test-Driven Development Help to Avoid Technial Debt","authors":"W. Trumler, Frances Paulisch","doi":"10.1109/MTD.2016.10","DOIUrl":"https://doi.org/10.1109/MTD.2016.10","url":null,"abstract":"This paper is an industrial experience report of applying the \"Specification by Example\" methodology and test-driven development to the development of a core component of a healthcare product. The methods are mapped to the four quadrants of technical debt introduced by Martin Fowler in order to show how they can help to avoid the accumulation of technical debt. The resulting data show that a very low defect density can be achieved with these practices, which helps to avoid technical debt introduced for example by quick fixes during a late project phase. Performance indicators measured during development and system test are presented. These results are informally compared to approaches based on formal methods further indicating the advantage of the presented approach.","PeriodicalId":371173,"journal":{"name":"2016 IEEE 8th International Workshop on Managing Technical Debt (MTD)","volume":"71 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132747683","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Areti Ampatzoglou, Apostolos Ampatzoglou, A. Chatzigeorgiou, P. Avgeriou, P. Abrahamsson, A. Martini, Uwe Zdun, Kari Systä
Technical Debt Management (TDM) has drawn the attention of software industries during the last years, including embedded systems. However, we currently lack an overview of how practitioners from this application domain perceive technical debt. To this end, we conducted a multiple case study in the embedded systems industry, to investigate: (a) the expected life-time of components that have TD, (b) the most frequently occurring types of TD in them, and (c) the significance of TD against run-time quality attributes. The case study was performed on seven embedded systems industries (telecommunications, printing, smart manufacturing, sensors, etc.) from five countries (Greece, Netherlands, Sweden, Austria, and Finland). The results of the case study suggest that: (a) maintainability is more seriously considered when the expected lifetime of components is larger than ten years, (b) the most frequent types of debt are test, architectural, and code debt, and (c) in embedded systems the run-time qualities are prioritized compared to design-time qualities that are usually associated with TD. The obtained results can be useful for both researchers and practitioners: the former can focus their research on the most industrially-relevant aspects of TD, whereas the latter can be informed about the most common types of TD and how to focus their TDM processes.
{"title":"The Perception of Technical Debt in the Embedded Systems Domain: An Industrial Case Study","authors":"Areti Ampatzoglou, Apostolos Ampatzoglou, A. Chatzigeorgiou, P. Avgeriou, P. Abrahamsson, A. Martini, Uwe Zdun, Kari Systä","doi":"10.1109/MTD.2016.8","DOIUrl":"https://doi.org/10.1109/MTD.2016.8","url":null,"abstract":"Technical Debt Management (TDM) has drawn the attention of software industries during the last years, including embedded systems. However, we currently lack an overview of how practitioners from this application domain perceive technical debt. To this end, we conducted a multiple case study in the embedded systems industry, to investigate: (a) the expected life-time of components that have TD, (b) the most frequently occurring types of TD in them, and (c) the significance of TD against run-time quality attributes. The case study was performed on seven embedded systems industries (telecommunications, printing, smart manufacturing, sensors, etc.) from five countries (Greece, Netherlands, Sweden, Austria, and Finland). The results of the case study suggest that: (a) maintainability is more seriously considered when the expected lifetime of components is larger than ten years, (b) the most frequent types of debt are test, architectural, and code debt, and (c) in embedded systems the run-time qualities are prioritized compared to design-time qualities that are usually associated with TD. The obtained results can be useful for both researchers and practitioners: the former can focus their research on the most industrially-relevant aspects of TD, whereas the latter can be informed about the most common types of TD and how to focus their TDM processes.","PeriodicalId":371173,"journal":{"name":"2016 IEEE 8th International Workshop on Managing Technical Debt (MTD)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129221094","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Providing software developers and researchers with useful technical debt analysis tools is an instrumental outcome of software engineering and technical debt research. Such tools aggregate industry best practices to provide users with organized and quantifiable metrics that can help minimize the time it takes to synthesize and make an intelligent future decision regarding a system. Today, most tools rely primarily on structural measurements from static analysis to generate results. However, it is also necessary to consider measurements that capture the behavior of software, as these represent additional complexities within a system that structural measurements are incapable of detecting. Herein, we present our position, that more effort needs to be placed towards understanding software behavior so that technical debt analysis tools can begin supporting them, in order to provide tool users with a more accurate and complete view of their system. In this paper, we describe this problem in the context of design patterns and outline an effective method to talk about behaviors in the future. We create and classify two example behaviors using our method, both of which increase the technical debt in their respective design pattern applications.
{"title":"Towards Assessing the Technical Debt of Undesired Software Behaviors in Design Patterns","authors":"Derek Reimanis, C. Izurieta","doi":"10.1109/MTD.2016.13","DOIUrl":"https://doi.org/10.1109/MTD.2016.13","url":null,"abstract":"Providing software developers and researchers with useful technical debt analysis tools is an instrumental outcome of software engineering and technical debt research. Such tools aggregate industry best practices to provide users with organized and quantifiable metrics that can help minimize the time it takes to synthesize and make an intelligent future decision regarding a system. Today, most tools rely primarily on structural measurements from static analysis to generate results. However, it is also necessary to consider measurements that capture the behavior of software, as these represent additional complexities within a system that structural measurements are incapable of detecting. Herein, we present our position, that more effort needs to be placed towards understanding software behavior so that technical debt analysis tools can begin supporting them, in order to provide tool users with a more accurate and complete view of their system. In this paper, we describe this problem in the context of design patterns and outline an effective method to talk about behaviors in the future. We create and classify two example behaviors using our method, both of which increase the technical debt in their respective design pattern applications.","PeriodicalId":371173,"journal":{"name":"2016 IEEE 8th International Workshop on Managing Technical Debt (MTD)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129323845","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Causes of the database debt can stem from ill-conceptual, logical, and/or physical database design decisions, violations to key design databases principles, use of anti-patterns etc. In this paper, we explore the problem of relational database design debt and define the problem. We develop a taxonomy, which classifies various types of debts that can relate to conceptual, logical and physical design of a database. We define the concept of Database Design Debt, discuss their origin, causes and preventive mechanisms. We draw on MediaWiki case study and examine its database schema evolution to support our work. The contribution hopes to make database designers and application developers aware of these debts so they can minimize/avoid their consequences on a given system.
{"title":"Database Design Debts through Examining Schema Evolution","authors":"Mashel Al-Barak, R. Bahsoon","doi":"10.1109/MTD.2016.9","DOIUrl":"https://doi.org/10.1109/MTD.2016.9","url":null,"abstract":"Causes of the database debt can stem from ill-conceptual, logical, and/or physical database design decisions, violations to key design databases principles, use of anti-patterns etc. In this paper, we explore the problem of relational database design debt and define the problem. We develop a taxonomy, which classifies various types of debts that can relate to conceptual, logical and physical design of a database. We define the concept of Database Design Debt, discuss their origin, causes and preventive mechanisms. We draw on MediaWiki case study and examine its database schema evolution to support our work. The contribution hopes to make database designers and application developers aware of these debts so they can minimize/avoid their consequences on a given system.","PeriodicalId":371173,"journal":{"name":"2016 IEEE 8th International Workshop on Managing Technical Debt (MTD)","volume":"46 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124390904","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
In software maintenance and evolution, it is important to assess both code and architecture in order to identify issues to be solved to improve software quality. Different tools provide some kind of index giving us an overall evaluation of a project to be used when managing its technical debt. In this paper, we outline how the indexes, that we call in general Technical Debt Indexes, provided by five different tools are computed. We describe their principal features and differences, what aspects they are missing, and we outline if (and how) the indexes take into account architectural problems that could have a major impact on the architectural debt. We show that the indexes rely on different information sources and measure different quantities.
{"title":"Technical Debt Indexes Provided by Tools: A Preliminary Discussion","authors":"F. Fontana, Riccardo Roveda, M. Zanoni","doi":"10.1109/MTD.2016.11","DOIUrl":"https://doi.org/10.1109/MTD.2016.11","url":null,"abstract":"In software maintenance and evolution, it is important to assess both code and architecture in order to identify issues to be solved to improve software quality. Different tools provide some kind of index giving us an overall evaluation of a project to be used when managing its technical debt. In this paper, we outline how the indexes, that we call in general Technical Debt Indexes, provided by five different tools are computed. We describe their principal features and differences, what aspects they are missing, and we outline if (and how) the indexes take into account architectural problems that could have a major impact on the architectural debt. We show that the indexes rely on different information sources and measure different quantities.","PeriodicalId":371173,"journal":{"name":"2016 IEEE 8th International Workshop on Managing Technical Debt (MTD)","volume":"55 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124816665","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}