Identifying and Prioritizing Architectural Debt Through Architectural Smells: A Case Study in a Large Software Company

Martini, Antonio; Fontana, Francesca Arcelli; Biaggi, Andrea; Roveda, Riccardo

doi:10.1007/978-3-030-00761-4_21

Cited by 49 publications

(36 citation statements)

References 19 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This is the smell for which we have quite strong evidence (F1) supporting hypotheses from literature (Martini et al 2018b;Al-Mutawa et al 2014). We can see how, for valence, the software practitioners reported extra-pleasure in the presence of code that is refactored (ScD-L), while at the same time, we register strong evidence that such code is much better liked than the one with the smell (ScD-H).…”

Section: Case D: Cyclic Dependenciessupporting

confidence: 80%

See 1 more Smart Citation

Measuring affective states from technical debt

et al. 2021

Self Cite

View full text Add to dashboard Cite

Context Software engineering is a human activity. Despite this, human aspects are under-represented in technical debt research, perhaps because they are challenging to evaluate. Objective This study’s objective was to investigate the relationship between technical debt and affective states (feelings, emotions, and moods) from software practitioners. Method Forty participants (N = 40) from twelve companies took part in a mixed-methods approach, consisting of a repeated-measures (r = 5) experiment (n = 200), a survey, and semi-structured interviews. From the qualitative data, it is clear that technical debt activates a substantial portion of the emotional spectrum and is psychologically taxing. Further, the practitioners’ reactions to technical debt appear to fall in different levels of maturity. Results The statistical analysis shows that different design smells (strong indicators of technical debt) negatively or positively impact affective states. Conclusions We argue that human aspects in technical debt are important factors to consider, as they may result in, e.g., procrastination, apprehension, and burnout.

show abstract

Section: Case D: Cyclic Dependenciessupporting

confidence: 80%

“…Also, the example that we propose here consists of just one dependency. In contrast, dependencies, especially if involving several entities, can become less noticeable and not so visible if they are not explicitly investigated, as shown in other publications, see Martini et al (2018b) and Al-Mutawa et al (2014).…”

Section: Case D: Cyclic Dependenciesmentioning

confidence: 80%

Measuring affective states from technical debt

et al. 2021

Self Cite

View full text Add to dashboard Cite

show abstract

“…Numerous software analysis approaches have been proposed to detect ATD in software-intensive systems. Among the most prominent and current ones, the approach of Arcelli Fontana et al [Arcelli Fontana et al, 2016, Martini et al, 2018a, [Roveda et al, 2018] focuses on the identification of ATD by analyzing dependency architectural smells, which could lead to the emergence of an additional ATDD dimension, namely "Dependency". Similarly, Kazman et al [Kazman et al, 2015, Xiao et al, 2016 [Cai and Kazman, 2017], analyzed ATD by inspecting antipatterns of semantically related architectural components, e.g., via the analysis of bug-prone components.…”

Section: Related Workmentioning

confidence: 99%

ATDx: Building an Architectural Technical Debt Index

Verdecchia

Lago

Malavolta

et al. 2020

Proceedings of the 15th International Conference on Evaluation of Novel Approaches to Software Engineering

View full text Add to dashboard Cite

Architectural technical debt (ATD) in software-intensive systems refers to the architecture design decisions which work as expedient in the short term, but later negatively impact system evolvability and maintainability. Over the years numerous approaches have been proposed to detect particular types of ATD at a refined level of granularity via source code analysis. Nevertheless, how to gain an encompassing overview of the ATD present in a software-intensive system is still an open question. In this study, we present a multi-step approach designed to build an ATD index (ATDx), which provides insights into a set of ATD dimensions building upon existing architectural rules by leveraging statistical analysis. The ATDx approach can be adopted by researchers and practitioners alike in order to gain a better understanding of the nature of the ATD present in software-intensive systems, and provides a systematic framework to implement concrete instances of ATDx according to specific project and organizational needs.

show abstract

“…Another work from Martini et al [17] was conducted in a large software company. ADT was automatically identified through architectural smells.…”

Section: Related Workmentioning

confidence: 99%

Architectural Technical Debt in Microservices: A Case Study in a Large Company

Toledo

Martini

Przybyszewska

et al. 2019

2019 IEEE/ACM International Conference on Technical Debt (TechDebt)

Self Cite

View full text Add to dashboard Cite

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 obstructs 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 data 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 may affect the payment of the debt, as lack of funding and inadequate prioritization. Conclusion: We found issues, solutions and 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.

show abstract

Identifying and Prioritizing Architectural Debt Through Architectural Smells: A Case Study in a Large Software Company

Cited by 49 publications

References 19 publications

Measuring affective states from technical debt

Measuring affective states from technical debt

ATDx: Building an Architectural Technical Debt Index

Architectural Technical Debt in Microservices: A Case Study in a Large Company

Contact Info

Product

Resources

About