Pub Date : 2019-05-01DOI: 10.1109/TechDebt.2019.00014
G. Hanssen, Gunnar Brataas, A. Martini
Architectural technical debt can be generated by changes in the business and the environment of an organization. In this paper, we emphasize the change in scalability requirements due to new regulations. Scalability is the ability of a system to handle an increased workload. For complex systems that are abruptly exposed via open interfaces and hence a greater workload, the scalability requirements may quickly increase, leading to technical debt. We term this scalability debt. This paper describes scalability triage, a light-weight, novel technique for identifying scalability threats as a form of technical debt. We illustrate this technique with an open banking case from a large software organization. Open banking is partly caused by the new European PSD2 regulative that enforce banks to open interfaces to unknown third-party actors. Banking systems are well-established, mature systems. However, with the advent of open banking and PSD2, the workload may quickly rocket. This leads to tougher scalability requirements and accumulated architectural debt, despite previously sound architectural decisions. Using scalability triage, such risks may be identified fast. It will then be possible to prevent this form of technical debt with timely reengineering.
{"title":"Identifying Scalability Debt in Open Systems","authors":"G. Hanssen, Gunnar Brataas, A. Martini","doi":"10.1109/TechDebt.2019.00014","DOIUrl":"https://doi.org/10.1109/TechDebt.2019.00014","url":null,"abstract":"Architectural technical debt can be generated by changes in the business and the environment of an organization. In this paper, we emphasize the change in scalability requirements due to new regulations. Scalability is the ability of a system to handle an increased workload. For complex systems that are abruptly exposed via open interfaces and hence a greater workload, the scalability requirements may quickly increase, leading to technical debt. We term this scalability debt. This paper describes scalability triage, a light-weight, novel technique for identifying scalability threats as a form of technical debt. We illustrate this technique with an open banking case from a large software organization. Open banking is partly caused by the new European PSD2 regulative that enforce banks to open interfaces to unknown third-party actors. Banking systems are well-established, mature systems. However, with the advent of open banking and PSD2, the workload may quickly rocket. This leads to tougher scalability requirements and accumulated architectural debt, despite previously sound architectural decisions. Using scalability triage, such risks may be identified fast. It will then be possible to prevent this form of technical debt with timely reengineering.","PeriodicalId":197657,"journal":{"name":"2019 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124831700","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}
Pub Date : 2019-05-01DOI: 10.1109/TechDebt.2019.00028
Valentina Lenarduzzi, Nyyti Saarimaki, D. Taibi
Background. Companies commonly invest majorBackground. Companies commonly invest major effort into removing, respectively not introducing, technical debt issues detected by static analysis tools such as SonarQube, Cast, or Coverity. These tools classify technical debt issues into categories according to severity, and developers commonly pay attention to not introducing issues with a high level of severity that could generate bugs or make software maintenance more difficult. Objective. In this work, we aim to understand the diffuseness of Technical Debt (TD) issues and the speed with which developers remove them from the code if they introduced such an issue. The goal is to understand which type of TD is more diffused and how much attention is paid by the developers, as well as to investigate whether TD issues with a higher level of severity are resolved faster than those with a lower level of severity. We conducted a case study across 78K commits of 33 Java projects from the Apache Software Foundation Ecosystem to investigate the distribution of 1.4M TD items. Results. TD items introduced into the code are mostly related to code smells (issues that can increase the maintenance effort). Moreover, developers commonly remove the most severe issues faster than less severe ones. However, the time needed to resolve issues increases when the level of severity increases (minor issues are removed faster that blocker ones). Conclusion. One possible answer to the unexpected issue of resolution time might be that severity is not correctly defined by the tools. Another possible answer is that the rules at an intermediate severity level could be the ones that technically require more time to be removed. The classification of TD items, including their severity and type, require thorough investigation from a research point of view.effort into removing, respectively not introducing, technical debtissues detected by static analysis tools such as SonarQube, Cast, or Coverity. These tools classify technical debt issues intocategories according to severity, and developers commonly payattention to not introducing issues with a high level of severitythat could generate bugs or make software maintenance moredifficult. Objective. In this work, we aim to understand the diffuseness ofTechnical Debt (TD) issues and the speed with which developersremove them from the code if they introduced such an issue. The goal is to understand which type of TD is more diffusedand how much attention is paid by the developers, as well asto investigate whether TD issues with a higher level of severityare resolved faster than those with a lower level of severity. Weconducted a case study across 78K commits of 33 Java projectsfrom the Apache Software Foundation Ecosystem to investigatethe distribution of 1.4M TD items. Results. TD items introduced into the code are mostly relatedto code smells (issues that can increase the maintenance effort). Moreover, developers commonly remove the most sev
{"title":"On the Diffuseness of Code Technical Debt in Open Source Projects","authors":"Valentina Lenarduzzi, Nyyti Saarimaki, D. Taibi","doi":"10.1109/TechDebt.2019.00028","DOIUrl":"https://doi.org/10.1109/TechDebt.2019.00028","url":null,"abstract":"Background. Companies commonly invest majorBackground. Companies commonly invest major effort into removing, respectively not introducing, technical debt issues detected by static analysis tools such as SonarQube, Cast, or Coverity. These tools classify technical debt issues into categories according to severity, and developers commonly pay attention to not introducing issues with a high level of severity that could generate bugs or make software maintenance more difficult. Objective. In this work, we aim to understand the diffuseness of Technical Debt (TD) issues and the speed with which developers remove them from the code if they introduced such an issue. The goal is to understand which type of TD is more diffused and how much attention is paid by the developers, as well as to investigate whether TD issues with a higher level of severity are resolved faster than those with a lower level of severity. We conducted a case study across 78K commits of 33 Java projects from the Apache Software Foundation Ecosystem to investigate the distribution of 1.4M TD items. Results. TD items introduced into the code are mostly related to code smells (issues that can increase the maintenance effort). Moreover, developers commonly remove the most severe issues faster than less severe ones. However, the time needed to resolve issues increases when the level of severity increases (minor issues are removed faster that blocker ones). Conclusion. One possible answer to the unexpected issue of resolution time might be that severity is not correctly defined by the tools. Another possible answer is that the rules at an intermediate severity level could be the ones that technically require more time to be removed. The classification of TD items, including their severity and type, require thorough investigation from a research point of view.effort into removing, respectively not introducing, technical debtissues detected by static analysis tools such as SonarQube, Cast, or Coverity. These tools classify technical debt issues intocategories according to severity, and developers commonly payattention to not introducing issues with a high level of severitythat could generate bugs or make software maintenance moredifficult. Objective. In this work, we aim to understand the diffuseness ofTechnical Debt (TD) issues and the speed with which developersremove them from the code if they introduced such an issue. The goal is to understand which type of TD is more diffusedand how much attention is paid by the developers, as well asto investigate whether TD issues with a higher level of severityare resolved faster than those with a lower level of severity. Weconducted a case study across 78K commits of 33 Java projectsfrom the Apache Software Foundation Ecosystem to investigatethe distribution of 1.4M TD items. Results. TD items introduced into the code are mostly relatedto code smells (issues that can increase the maintenance effort). Moreover, developers commonly remove the most sev","PeriodicalId":197657,"journal":{"name":"2019 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"96 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114585752","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}
Pub Date : 2019-05-01DOI: 10.1109/TechDebt.2019.00026
S. S. D. Toledo, A. Martini, Agata Przybyszewska, Dag I.K. Sjøberg
Introduction: Software companies aim to achieve continuous delivery to constantly provide value to their customers. A popular strategy is to use microservices architecture. However, such an architecture is also subject to debt, which hinders the continuous delivery process and thus negatively affects the software released to the customers. Objectives: The aim of this study is to identify issues, solutions and risks related to Architecture Technical Debt in microservices. Method: We conducted an exploratory case study of a real life project with about 1000 services in a large, international company. Through qualitative analysis of documents and interviews, we investigated Architecture Technical Debt in the communication layer of a system with microservices architecture. Results: Our main contributions are a list of Architecture Technical Debt issues specific for the communication layer in a system with microservices architecture, as well as their associated negative impact (interest), a solution to repay the debt and the its cost (principal). Among the found Architecture Technical Debt issues were the existence of business logic in the communication layer and a high amount of point-to-point connections between services. The studied solution consists of the implementation of different canonical models specific to different domains, the removal of business logic from the communication layer, and migration from services to use the communication layer correctly. We also contributed with a list of possible risks that can affect the payment of the debt, as lack of funding and inadequate prioritization. Conclusion: We found issues, solutions and possible risks that are specific for microservices architectures not yet encountered in the current literature. Our results may be useful for practitioners that want to avoid or repay Technical Debt in their microservices architecture.
{"title":"Architectural Technical Debt in Microservices: A Case Study in a Large Company","authors":"S. S. D. Toledo, A. Martini, Agata Przybyszewska, Dag I.K. Sjøberg","doi":"10.1109/TechDebt.2019.00026","DOIUrl":"https://doi.org/10.1109/TechDebt.2019.00026","url":null,"abstract":"Introduction: Software companies aim to achieve continuous delivery to constantly provide value to their customers. A popular strategy is to use microservices architecture. However, such an architecture is also subject to debt, which hinders the continuous delivery process and thus negatively affects the software released to the customers. Objectives: The aim of this study is to identify issues, solutions and risks related to Architecture Technical Debt in microservices. Method: We conducted an exploratory case study of a real life project with about 1000 services in a large, international company. Through qualitative analysis of documents and interviews, we investigated Architecture Technical Debt in the communication layer of a system with microservices architecture. Results: Our main contributions are a list of Architecture Technical Debt issues specific for the communication layer in a system with microservices architecture, as well as their associated negative impact (interest), a solution to repay the debt and the its cost (principal). Among the found Architecture Technical Debt issues were the existence of business logic in the communication layer and a high amount of point-to-point connections between services. The studied solution consists of the implementation of different canonical models specific to different domains, the removal of business logic from the communication layer, and migration from services to use the communication layer correctly. We also contributed with a list of possible risks that can affect the payment of the debt, as lack of funding and inadequate prioritization. Conclusion: We found issues, solutions and possible risks that are specific for microservices architectures not yet encountered in the current literature. Our results may be useful for practitioners that want to avoid or repay Technical Debt in their microservices architecture.","PeriodicalId":197657,"journal":{"name":"2019 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"20 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133414494","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}
Pub Date : 2019-05-01DOI: 10.1109/techdebt.2019.00006
Technical debt is a metaphor that software developers and managers increasingly use to communicate key trade-offs between business constraints and internal quality issues, especially those related to time to market. While other software engineering disciplines—such as software sustainability, maintenance and evolution, refactoring, software quality, and empirical software engineering—have produced results relevant to managing technical debt, none of them alone suffices to model, manage, and communicate the different facets of the complex trade-offs involved in managing technical debt. Similarly, while many software engineering practices can be used to get ahead of technical debt, organizations struggle with managing technical debt routinely and strategically.
{"title":"Message from the Chairs of TechDebt 2019","authors":"","doi":"10.1109/techdebt.2019.00006","DOIUrl":"https://doi.org/10.1109/techdebt.2019.00006","url":null,"abstract":"Technical debt is a metaphor that software developers and managers increasingly use to communicate key trade-offs between business constraints and internal quality issues, especially those related to time to market. While other software engineering disciplines—such as software sustainability, maintenance and evolution, refactoring, software quality, and empirical software engineering—have produced results relevant to managing technical debt, none of them alone suffices to model, manage, and communicate the different facets of the complex trade-offs involved in managing technical debt. Similarly, while many software engineering practices can be used to get ahead of technical debt, organizations struggle with managing technical debt routinely and strategically.","PeriodicalId":197657,"journal":{"name":"2019 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"28 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122070416","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}
Pub Date : 2019-01-21DOI: 10.1109/TechDebt.2019.00011
Christoph Becker, Fabian Fagerholm, Rahul Mohanani, A. Chatzigeorgiou
Technical Debt management decisions always imply a trade-off among outcomes at different points in time. In such intertemporal choices, distant outcomes are often valued lower than close ones, a phenomenon known as temporal discounting. Technical Debt research largely develops prescriptive approaches for how software engineers should make such decisions. Few have studied how they actually make them. This leaves open central questions about how software practitioners make decisions. This paper investigates how software practitioners discount uncertain future outcomes and whether they exhibit temporal discounting. We adopt experimental methods from intertemporal choice, an active area of research. We administered an online questionnaire to 33 developers from two companies in which we presented choices between developing a feature and making a longer-term investment in architecture. The results show wide-spread temporal discounting with notable differences in individual behavior. The results are consistent with similar studies in consumer behavior and raise a number of questions about the causal factors that influence temporal discounting in software engineering. As the first empirical study on intertemporal choice in SE, the paper establishes an empirical basis for understanding how software developers approach intertemporal choice and provides a blueprint for future studies.
{"title":"Temporal Discounting in Technical Debt: How do Software Practitioners Discount the Future?","authors":"Christoph Becker, Fabian Fagerholm, Rahul Mohanani, A. Chatzigeorgiou","doi":"10.1109/TechDebt.2019.00011","DOIUrl":"https://doi.org/10.1109/TechDebt.2019.00011","url":null,"abstract":"Technical Debt management decisions always imply a trade-off among outcomes at different points in time. In such intertemporal choices, distant outcomes are often valued lower than close ones, a phenomenon known as temporal discounting. Technical Debt research largely develops prescriptive approaches for how software engineers should make such decisions. Few have studied how they actually make them. This leaves open central questions about how software practitioners make decisions. This paper investigates how software practitioners discount uncertain future outcomes and whether they exhibit temporal discounting. We adopt experimental methods from intertemporal choice, an active area of research. We administered an online questionnaire to 33 developers from two companies in which we presented choices between developing a feature and making a longer-term investment in architecture. The results show wide-spread temporal discounting with notable differences in individual behavior. The results are consistent with similar studies in consumer behavior and raise a number of questions about the causal factors that influence temporal discounting in software engineering. As the first empirical study on intertemporal choice in SE, the paper establishes an empirical basis for understanding how software developers approach intertemporal choice and provides a blueprint for future studies.","PeriodicalId":197657,"journal":{"name":"2019 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"34 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-01-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125723630","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}
Pub Date : 1900-01-01DOI: 10.1109/TechDebt.2019.00022
Alexander von Zitzewitz
Sonargraph is a static analyzer with a focus on software architecture and metrics. The motivation to create Sonargraph came from the assumption that architectural debt (aka structural debt) is the most toxic form of technical debt. Repairing a broken architecture requires global and high-risk changes, while fixing other forms of technical debt mostly involves low-risk local changes. Therefore, the tool enables architects and developers to formally describe their architectural blueprint using a custom DSL (domain specific language). Once defined architectural rules can be checked and enforced in an automated way in all stages of the development process. This guarantees that a software system will never end up as the notorious "big ball of mud". Sonargraph currently supports Java, C#, C/C++ and Python and is used by hundreds of organizations worldwide.
{"title":"Mitigating Technical and Architectural Debt with Sonargraph","authors":"Alexander von Zitzewitz","doi":"10.1109/TechDebt.2019.00022","DOIUrl":"https://doi.org/10.1109/TechDebt.2019.00022","url":null,"abstract":"Sonargraph is a static analyzer with a focus on software architecture and metrics. The motivation to create Sonargraph came from the assumption that architectural debt (aka structural debt) is the most toxic form of technical debt. Repairing a broken architecture requires global and high-risk changes, while fixing other forms of technical debt mostly involves low-risk local changes. Therefore, the tool enables architects and developers to formally describe their architectural blueprint using a custom DSL (domain specific language). Once defined architectural rules can be checked and enforced in an automated way in all stages of the development process. This guarantees that a software system will never end up as the notorious \"big ball of mud\". Sonargraph currently supports Java, C#, C/C++ and Python and is used by hundreds of organizations worldwide.","PeriodicalId":197657,"journal":{"name":"2019 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"21 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115064100","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
扫码关注我们
求助内容：
应助结果提醒方式：