Technical debt payment and prevention through the lenses of software architects
Introduction
Tight schedules and deadlines are common conditions faced by software companies when delivery of software in faster cycles is required. These conditions increase the pressure for the development teams to deliver working features to their customers [1]. Additionally, the onset of continuous integration approaches as well as DevOps has contributed to this problem [2]. Technical debt (TD) is a metaphor used by the software community to describe technical decisions that can give companies a benefit in the short term [3] but possibly hurt the overall quality of the software and the productivity of the development team in the long term [4]. Intentional TD injection during software development is a common practice for software teams because it can help to achieve the project’s goals sooner or more cheaply. However, this TD could pose risks to projects if it becomes difficult to manage [5], such as financial and technical problems linked to software maintenance and evolution costs [6].
According to Ernst et al. [7], architectural decisions are the most important source of TD. Therefore, it becomes crucial to understand how TD is managed by those who make architectural decisions, i.e., software architects: the practices used to pay off the debt introduced in software projects, and the practices performed by them to avoid or reduce TD occurrence in software projects. Investigating payment and preventive practices solely from the perspective of software architects is a compelling argument because they are responsible for critical decisions that affect the longevity of software products. These two practices (payment and prevention) are important because they are related to each other: debt prevention can be better and cheaper for the development team than incurring debt and paying it off later [8]. In other words, TD prevention also supports other TD management activities by reducing not only payment activities but also monitoring or identification activities [1]. Prevention supports the implementation of the optimal solution right from the beginning without potential interest payments. Also, catching TD early by architects facilitates implementation phases for practitioners. TD preventive actions can support the development team to minimize the occurrence of debt [9]. Therefore, TD prevention is worth additional consideration [8]. These two practices (payment and prevention) are of special interest to the software community because knowing the current practices adopted by practitioners can provide initial guidance for software teams on how to prevent or pay off debt items.
Despite the attention surrounding TD by both industry and academia, there is a lack of empirical evidence about both the payment-related and preventive practices used by software architects in real-life software projects [10], [11]. There are, however, two studies close to ours: a study focused on TD payment practices [12], and a study focused on TD preventive practices [9]. The former [12] discusses an analysis of the most cited TD payment practices considering the size and age of systems, followed by an analysis of how TD causes can be associated with TD practices. The analysis includes 432 professionals from Brazil, Chile, Colombia, and the United States. The latter [9] discusses an analysis of the preventive actions that can be used to avoid the occurrence of TD and the impediments that hamper the application of these actions. This analysis includes 207 professionals from Brazil and the United States. Both studies focused on the point of view of all software practitioners’ roles including developers, testers, project managers, software architects, among others. Our study focused only on the perspective of software architects. Also, differences between populations lead to varying results among these studies.
The goal of this study is to investigate the practices performed on TD payment and on TD prevention from the point of view of software architects in real-life software systems projects. It is important to note that TD payment/preventive practices were reported without knowing how much debt was paid off nor the level of success of the practice, therefore, this study does not make any assumptions on how optimal a practice is. This study focused on payment-related practices of the debt that practitioners were aware of, and not on whether the debt was intentionally introduced. This study uses data from Brazil, Chile, Colombia, and the United States, collected by the InsighTD Project, which is a globally distributed family of industrial surveys on the causes and effects of TD [13]. A total of 72 software architects from the countries mentioned responded to the survey. This study analyzes this data through qualitative and quantitative strategies: first, we characterize the study participants, and then, qualitatively analyze the payment and preventive practices cited by them.
Results show that refactoring and improve design (19 citations altogether) are the most cited TD payment practices used by software teams, as reported by software architects. These practices were expected to be at the top of the list [1], [10], [14], [15], considering that both practices are intertwined. Lists of payment practices among design, code, and test debt tend to be more similar as more practices are included. We find that 6 out of 7 payment practices are shared between code and design debt, and only three practices are shared among all three TD types: refactoring, improve design, and improve testing. Finally, software architects reported the most common causes of TD occurrence, and when they were mapped against the payment practices we found that refactoring is the most used practice for TD payment in 5 out of 9 most cited TD causes.
Related to the TD preventive practices, we found that well-defined architecture/design and well-defined scope/requirements were the most performed practices. Software architects understand the relationship between architectural design and TD. Also, we found that well-defined scope/requirements was the most performed preventive practice for expert group, code evaluation/standardization for proficient group and, well-defined architecture/design for both competent and beginner groups. Finally, when comparing the preventive practices among software architects, engineer roles, and management roles, we found that all three roles share more than 50% of the performed preventive practices. This is expected considering how close they are to the development process. However, all three roles are different in their first 5 most cited practices.
Software practitioners can benefit from the results of this study by using the list of practices related to TD payment used in industry to support initial efforts to understand their debt (by considering the most cited TD causes) and to pay it off in their software projects. Also, software practitioners could review the list of TD preventive practices (commensurate with their level or expertise) and use it as a guide to improve their software development process. The global family of surveys allows practitioners to evaluate their own TD situation against overall industrial trends. For researchers, our results support future research by providing insights into software architects’ perspectives on practices related to TD payment and TD prevention.
The contributions of this work are two-fold. First, an analysis of the most used TD payment-related practices (refactoring being the most cited) is presented. In addition, a comparison of the similarity of the payment practices according to the three major TD types cases found in our study is presented, together with a heatmap of the most cited practices related to TD payment against the most cited TD causes reported by software architects. Second, an analysis of the most performed TD preventive practices is presented, together with an analysis of these practices according to the experience of the architects, and in comparison with management roles and engineering roles.
The rest of the paper is structured as follows: Section 2 presents a description of the InsighTD project history altogether with a review of TD concept. Section 3 presents the survey design. In Section 4, we present the results of our analysis. Discussion of our results are presented in Section 5. Section 6 presents a review of studies similar to this one. And finally, in Section 7, we present threats to validity, and conclude the paper in Section 8.
Section snippets
InsighTD project
InsighTD is a globally distributed family of industrial surveys initiated in 2017 and focused on organizing an open and generalizable set of empirical data on the state of practice and industry trends in the TD area. The InsighTD’s survey includes questions covering (i) the characterization of the participants and their respective organizations, (ii) the understanding of the TD concept, (iii) the identification of possible causes and their possible effects on software projects, and (iv) how
Research method
This section presents the research questions posed in this work, and discusses its data collection (survey research method) and data analysis procedures.
Results
This section presents the practices used to pay off TD, as reported by software architects, and the practices performed by software architects to prevent TD injection into software projects.
Discussion
This section discusses the results and presents their implications for both practitioners and researchers.
Related work
There are studies related to payment practices described by software practitioners. In [1], Yli-Huumo et al. conducted an exploratory case study method to collect and analyze empirical data by performing semi-structured interviews to 25 software practitioners (11 software architects) from eight (8) software development teams in one large software company. Related to TD prevention, the vast majority of development teams used coding standards to prevent TD, along with code reviews, and the
Threats to validity
There are threats to validity in this study that we attempt to mitigate and remove when possible. The main threats regarding this study are [43]: external validity, internal validity, construct validity, and reliability.
External validity. Respondents are well distributed based on their experience, software project participation, company size, and country. Thus, by achieving a diversity of participants who answered the survey we look to reduced this threat. These results cannot be generalized,
Conclusions
This study focused on understanding how TD is perceive form the point of view of a software architect. This perception was studied by analyzing what TD payment practices were used by software teams as reported by the architects, and the TD preventive practices performed by them to avoid or reduce debt presence in software projects.
The contributions of this work are two-fold. First, an analysis of the most used TD payment-related practices is presented. Based on the 16 TD payment-related
CRediT authorship contribution statement
Boris Pérez: Conceptualization, Formal analysis, Investigation, Writing – original draft. Camilo Castellanos: Formal analysis. Darío Correal: Writing – review & editing. Nicolli Rios: Methodology, Resources. Sávio Freire: Methodology, Resources. Rodrigo Spínola: Methodology, Resources, Writing – review & editing. Carolyn Seaman: Methodology, Resources. Clemente Izurieta: Conceptualization, Resources, Writing – review & editing.
Declaration of Competing Interest
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.
References (43)
- et al.
How do software development teams manage technical debt? – an empirical study
J. Syst. Softw.
(2016) - et al.
Measuring and monitoring technical debt
- et al.
A systematic mapping study on technical debt and its management
J. Syst. Softw.
(2015) - et al.
A tertiary study on technical debt: Types, management strategies, research trends, and base information for practitioners
Inf. Softw. Technol.
(2018) - et al.
Identification and management of technical debt: A systematic mapping study
Inf. Softw. Technol.
(2016) - et al.
Managing architectural technical debt: A unified model and systematic literature review
J. Syst. Softw.
(2018) - et al.
Investigating architectural technical debt accumulation and refactoring over time
Inf. Softw. Technol.
(2015) - et al.
A survey of devops concepts and challenges
ACM Comput. Surv.
(2019) - et al.
Technical debt: From metaphor to theory and practice
Ieee Softw.
(2012) - et al.
The practitioners’ point of view on the concept of technical debt and its causes and consequences: a design for a global family of industrial surveys and its first results from brazil
Empir. Softw. Eng.
(2020)
Architecture technical debt: Understanding causes and a qualitative model
Measure it? manage it? ignore it? software practitioners and technical debt
A study of factors that lead development teams to incur technical debt in software projects
Actions and impediments for technical debt prevention: Results from a global family of industrial surveys
The most common causes and effects of technical debt: first results from a global family of industrial surveys
The sources and approaches to management of technical debt: a case study of two product lines in a middle-size finnish software company
Causes and effects of the presence of technical debt in agile software projects
Familiarity, causes and reactions of software practitioners to the presence of technical debt: A replicated study in the chilean software industry
Hearing the voice of software practitioners on causes, effects, and practices to deal with documentation debt
Technical debt in costa rica: An insightd survey replication
Cited by (11)
IT managers’ perspective on Technical Debt Management
2023, Journal of Systems and SoftwareSoftware practitioners’ point of view on technical debt payment
2023, Journal of Systems and SoftwareCitation Excerpt :Then, we describe a number of studies that looked at the following central topics approached in our work: TD payment practices and reasons for not paying off TD. Lastly, we briefly describe our own previous work (Freire et al., 2020a; Pérez et al., 2020, 2021; Freire et al., 2021c). Technical debt management (TDM) is decisive for increasing the success of software projects (Seaman and Guo, 2011).
Preventing technical debt with the TAP framework for Technical Debt Aware Management
2022, Information and Software TechnologyCitation Excerpt :Various papers of this study uncovered TD causes and prevention strategies used by practitioners. The most commonly found prevention strategies are “well-defined scope/requirements”, “code evaluation/standardization”, “following well-defined project processes”, “well-defined architecture/design”, “TD awareness/management”, “adoption of good practices”, “improving tests/coverage”, “good communication”, and “reviews” [4,9,14,28]. All these research results are valid aspects of TD prevention.
Stakeholder influence on technical debt management in the public sector: An embedded case study
2022, Government Information QuarterlyCitation Excerpt :Rios et al. (2018) map 15 types of TD and provide definitions and examples of these TD types. Previous TD research has identified TD types based on coding, surveys, and interviews with IT professionals (Freire et al., 2020; Pérez et al., 2021; Ramač et al., 2022; Rios et al., 2020). Furthermore, they map TD types with TD causes and TD effects (Ramač et al., 2022; Rios et al., 2020) and preventive and payment actions (Freire et al., 2020; Pérez et al., 2021).
Familiarity, Common Causes and Effects of Technical Debt: A Replicated Study in the Saudi Software Industry
2024, Arabian Journal for Science and Engineering