Background: There is a growing body of knowledge on Technical Debt (TD) in recent years. This knowledge provides various explanations of the term and suggests different remedies for it. However, the knowledge is yet to be validated in software development processes.Aims: The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in Serbian IT industry. Second, to contribute towards precise conceptualization of the TD concept.Method: We conducted a national-wide survey to collect feedback from industry practitioners. The survey is a part of InsighTD–an international initiative to investigate causes and effects of TD.Results: In total, 93 responses were collected, mostly from developers. Results indicate that the concept of TD is not widely accepted for use by the industry, only 35% of practitioners have practical experiences with projects that explicitly considered or managed TD. The most common types of TD are: code, test and design debt that together account for 61% of all reported cases. The archetypal TD case is caused by a tight schedule and resulted with non-optimal solutions that are difficult to evolve and in constant need of rework.Conclusions: Implications are at one hand for academics, who should consider TD as a topic for their curriculums since the results revealed that novice developers are unfamiliar with the concept. At the other hand, industry practitioners have a well aligned understanding of the TD concept, which is consistent with TD literature. However, we perceive that the wider use of the existing tools and techniques for managing TD can significantly help practitioners to deal with the top three occurring TD types.
{"title":"The Prevalence of the Technical Debt Concept in Serbian IT Industry: Results of a National-Wide Survey","authors":"Vladimir Mandic, Nebojša Taušan, R. Ramač","doi":"10.1145/3387906.3388622","DOIUrl":"https://doi.org/10.1145/3387906.3388622","url":null,"abstract":"Background: There is a growing body of knowledge on Technical Debt (TD) in recent years. This knowledge provides various explanations of the term and suggests different remedies for it. However, the knowledge is yet to be validated in software development processes.Aims: The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in Serbian IT industry. Second, to contribute towards precise conceptualization of the TD concept.Method: We conducted a national-wide survey to collect feedback from industry practitioners. The survey is a part of InsighTD–an international initiative to investigate causes and effects of TD.Results: In total, 93 responses were collected, mostly from developers. Results indicate that the concept of TD is not widely accepted for use by the industry, only 35% of practitioners have practical experiences with projects that explicitly considered or managed TD. The most common types of TD are: code, test and design debt that together account for 61% of all reported cases. The archetypal TD case is caused by a tight schedule and resulted with non-optimal solutions that are difficult to evolve and in constant need of rework.Conclusions: Implications are at one hand for academics, who should consider TD as a topic for their curriculums since the results revealed that novice developers are unfamiliar with the concept. At the other hand, industry practitioners have a well aligned understanding of the TD concept, which is consistent with TD literature. However, we perceive that the wider use of the existing tools and techniques for managing TD can significantly help practitioners to deal with the top three occurring TD types.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"178 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115479294","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}
François Gauthier, Alexander Jordan, P. Krishnan, Behnaz Hassanshahi, Jörn Guy Süß, Sora Bae, Hyunjun Lee
Nowadays, industrial research labs operate like startups. In a relatively short amount of time, researchers are expected not only to explore innovative ideas but also show how the new ideas can add value to the organisation. One way to do this, especially when developing tools, is to construct usable prototypes. When the technology underlying the research tool is highly complex or niche, like program analysis, field trials with potential users also help explaining and demonstrating the benefits of the tool. Getting support from potential users helps demonstrate value to the organisation, which in turn justifies conducting more extensive research and investing more resources to enhance the initial prototype.Thus, research that involves the construction of tools need to manage both short and long term risk, and the technical debt that arises throughout the lifecycle of a research prototype. As not all prototypes will result in a technology transfer, one has to carefully manage the project resources dedicated to paying the technical debt. For example, failure to pay the debt early in the project might result in unstable prototypes that can have a negative influence on potential customers and make technology transfer harder. On the other hand, over committing resources to reduce the technical debt might result in slower research progress and failure to show improvement over state-of-the-art. In this paper, we will present experience reports from two dynamic program analysis projects. at Oracle Labs Australia.
{"title":"Trade-offs in Managing Risk and Technical Debt in Industrial Research Labs: An Experience Report","authors":"François Gauthier, Alexander Jordan, P. Krishnan, Behnaz Hassanshahi, Jörn Guy Süß, Sora Bae, Hyunjun Lee","doi":"10.1145/3387906.3388623","DOIUrl":"https://doi.org/10.1145/3387906.3388623","url":null,"abstract":"Nowadays, industrial research labs operate like startups. In a relatively short amount of time, researchers are expected not only to explore innovative ideas but also show how the new ideas can add value to the organisation. One way to do this, especially when developing tools, is to construct usable prototypes. When the technology underlying the research tool is highly complex or niche, like program analysis, field trials with potential users also help explaining and demonstrating the benefits of the tool. Getting support from potential users helps demonstrate value to the organisation, which in turn justifies conducting more extensive research and investing more resources to enhance the initial prototype.Thus, research that involves the construction of tools need to manage both short and long term risk, and the technical debt that arises throughout the lifecycle of a research prototype. As not all prototypes will result in a technology transfer, one has to carefully manage the project resources dedicated to paying the technical debt. For example, failure to pay the debt early in the project might result in unstable prototypes that can have a negative influence on potential customers and make technology transfer harder. On the other hand, over committing resources to reduce the technical debt might result in slower research progress and failure to show improvement over state-of-the-art. In this paper, we will present experience reports from two dynamic program analysis projects. at Oracle Labs Australia.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"35 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115840985","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}
Fabian Gilson, Miguel Morales Trujillo, Moffat Mathews
Technical debt is a metaphor that measures the additional effort needed to continue to add more features in a software due to its inherent decrease in code quality. Most software systems suffer from technical debt at some point so that dedicated tools and metrics have been developed to monitor such debt. Alongside tools, appropriate engineering practices must be put in place by the development team to keep that debt at an acceptable level. In this empirical study, we observed and surveyed Scrum development teams composed of experienced students in order to understand their quality-related processes on a year-long academic project. We found that (1) students do use static analysis tools of many forms, but their actual usage is limited due to time pressure; (2) retrospective and non-constraining feedback on code quality has little to no effect, even when given regularly during the course of the project; and (3) junior developers value composite quality indicators (e.g., maintainability, reliability in SonarQube), even if they do not fully understand their meaning. From our findings, we propose a series of recommendations, both technical and methodological, on how to train junior developers to understand and manage technical debt.
{"title":"How Junior Developers Deal with Their Technical Debt?","authors":"Fabian Gilson, Miguel Morales Trujillo, Moffat Mathews","doi":"10.1145/3387906.3388624","DOIUrl":"https://doi.org/10.1145/3387906.3388624","url":null,"abstract":"Technical debt is a metaphor that measures the additional effort needed to continue to add more features in a software due to its inherent decrease in code quality. Most software systems suffer from technical debt at some point so that dedicated tools and metrics have been developed to monitor such debt. Alongside tools, appropriate engineering practices must be put in place by the development team to keep that debt at an acceptable level. In this empirical study, we observed and surveyed Scrum development teams composed of experienced students in order to understand their quality-related processes on a year-long academic project. We found that (1) students do use static analysis tools of many forms, but their actual usage is limited due to time pressure; (2) retrospective and non-constraining feedback on code quality has little to no effect, even when given regularly during the course of the project; and (3) junior developers value composite quality indicators (e.g., maintainability, reliability in SonarQube), even if they do not fully understand their meaning. From our findings, we propose a series of recommendations, both technical and methodological, on how to train junior developers to understand and manage technical debt.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129756013","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}
Bad smells are symptoms of bad design choices implemented on the source code. They are one of the key indicators of technical debts, specifically, design debt. To manage this kind of debt, it is important to be aware of bad smells and refactor them whenever possible. Therefore, several bad smell detection tools and techniques have been proposed over the years. These tools and techniques present different strategies to perform detections. More recently, machine learning algorithms have also been proposed to support bad smell detection. However, we lack empirical evidence on the accuracy and efficiency of these machine learning based techniques. In this paper, we present an evaluation of seven different machine learning algorithms on the task of detecting four types of bad smells. We also provide an analysis of the impact of software metrics for bad smell detection using a unified approach for interpreting the models’ decisions. We found that with the right optimization, machine learning algorithms can achieve good performance (F1 score) for two bad smells: God Class (0.86) and Refused Parent Bequest (0.67). We also uncovered which metrics play fundamental roles for detecting each bad smell.
{"title":"Detecting Bad Smells with Machine Learning Algorithms: an Empirical Study","authors":"Daniel Cruz, Amanda Santana, Eduardo Figueiredo","doi":"10.1145/3387906.3388618","DOIUrl":"https://doi.org/10.1145/3387906.3388618","url":null,"abstract":"Bad smells are symptoms of bad design choices implemented on the source code. They are one of the key indicators of technical debts, specifically, design debt. To manage this kind of debt, it is important to be aware of bad smells and refactor them whenever possible. Therefore, several bad smell detection tools and techniques have been proposed over the years. These tools and techniques present different strategies to perform detections. More recently, machine learning algorithms have also been proposed to support bad smell detection. However, we lack empirical evidence on the accuracy and efficiency of these machine learning based techniques. In this paper, we present an evaluation of seven different machine learning algorithms on the task of detecting four types of bad smells. We also provide an analysis of the impact of software metrics for bad smell detection using a unified approach for interpreting the models’ decisions. We found that with the right optimization, machine learning algorithms can achieve good performance (F1 score) for two bad smells: God Class (0.86) and Refused Parent Bequest (0.67). We also uncovered which metrics play fundamental roles for detecting each bad smell.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"128 22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121092713","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}
B. Pérez, C. Castellanos, D. Correal, Nicolli Rios, Sávio Freire, R. Spínola, C. Seaman
Context: Technical debt (TD) is a metaphor used to describe technical decisions that can give the company a benefit in the short term but possibly hurting the overall quality of the software in the long term.Objective: This study aims to characterize the current state of practices related to TD payment from the point of view of software practitioners.Method: We used a survey research method to collect and analyze - both quantitatively and qualitatively - a corpus of responses from a survey of 432 software practitioners from Colombia, Chile, Brazil, and the United States, as a part of the InsighTD project.Results: We were able to identify that refactoring (24.3%) was the main practice related to TD payment, along with improving testing (6.2%) and improve design (5.8%). Also, we identify that small-sized systems and big-sized systems, along with young systems (less than one year) tend to use more refactoring. As a part of these results, we also could identify that some practices do not eliminate the debt by itself, but support a favorable scenario for TD payment or prevention. Additionally, after comparing the three major TD types cited (code debt, test debt and design debt) we could discover an important similarity of TD payment practices between code debt and design debt. Lastly, we identified that no matter the cause leading to TD occurrence, refactoring remained the most common practice.Conclusion: Definition of practices related to TD payment is an essential activity for software development teams. Developing healthy software systems that can be maintained in the future requires that companies find the right approaches for TD payment.
{"title":"What are the Practices used by Software Practitioners on Technical Debt Payment? Results From an International Family of Surveys","authors":"B. Pérez, C. Castellanos, D. Correal, Nicolli Rios, Sávio Freire, R. Spínola, C. Seaman","doi":"10.1145/3387906.3388632","DOIUrl":"https://doi.org/10.1145/3387906.3388632","url":null,"abstract":"Context: Technical debt (TD) is a metaphor used to describe technical decisions that can give the company a benefit in the short term but possibly hurting the overall quality of the software in the long term.Objective: This study aims to characterize the current state of practices related to TD payment from the point of view of software practitioners.Method: We used a survey research method to collect and analyze - both quantitatively and qualitatively - a corpus of responses from a survey of 432 software practitioners from Colombia, Chile, Brazil, and the United States, as a part of the InsighTD project.Results: We were able to identify that refactoring (24.3%) was the main practice related to TD payment, along with improving testing (6.2%) and improve design (5.8%). Also, we identify that small-sized systems and big-sized systems, along with young systems (less than one year) tend to use more refactoring. As a part of these results, we also could identify that some practices do not eliminate the debt by itself, but support a favorable scenario for TD payment or prevention. Additionally, after comparing the three major TD types cited (code debt, test debt and design debt) we could discover an important similarity of TD payment practices between code debt and design debt. Lastly, we identified that no matter the cause leading to TD occurrence, refactoring remained the most common practice.Conclusion: Definition of practices related to TD payment is an essential activity for software development teams. Developing healthy software systems that can be maintained in the future requires that companies find the right approaches for TD payment.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"4 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117027901","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}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：