Technical debt payment and prevention through the lenses of software architects

https://doi.org/10.1016/j.infsof.2021.106692Get rights and content

Abstract

Context:

Architectural decisions are considered one of the most common sources of technical debt (TD). Thus, it is necessary to understand how TD is perceived by software architects, particularly, the practices supporting the elimination of debt items from projects, and the practices used to reduce the chances of TD occurrence.

Objective:

This paper investigates the most commonly used practices to pay off TD and to prevent debt occurrence in software projects from the architect’s point of view.

Method:

We used the available data from InsighTD, which is a globally distributed family of industrial surveys on the causes, effects, and management of TD. We analyze responses from a corpus of 72 software architects from Brazil, Chile, Colombia, and the United States.

Results:

Results showed that refactoring (30.2%) was the main practice related to TD payment, followed by design improvements (14.0%). Refactoring, design improvements, and test improvements are the most cited payment practices among cases of code, design and test debt. Concerning the TD preventive practices, we find that having a well-defined architecture and design is the most cited practice (13.6%), followed by having a well-defined scope and requirements. This last practice is the most cited one for expert software architects. Finally, when comparing preventive practices among the three major roles derived from the survey (software architects, engineer roles, and management roles), we found that none of the roles shared the most cited practice, meaning that each role had its worries and focus on different strategies to reduce TD’s presence in the software.

Conclusion:

The lists of TD payment and prevention practices can guide software teams by having a catalog of practices to keep debt controlled or reduced.

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)

  • MartiniA. et al.

    Architecture technical debt: Understanding causes and a qualitative model

  • ErnstN.A. et al.

    Measure it? manage it? ignore it? software practitioners and technical debt

  • RiosN. et al.

    A study of factors that lead development teams to incur technical debt in software projects

  • FreireS. et al.

    Actions and impediments for technical debt prevention: Results from a global family of industrial surveys

  • B. Pérez, C. Castellanos, D. Correal, N. Rios, S. Freire, R. Spínola, C. Seaman, What are the practices used by...
  • RiosN. et al.

    The most common causes and effects of technical debt: first results from a global family of industrial surveys

  • Yli-HuumoJ. et al.

    The sources and approaches to management of technical debt: a case study of two product lines in a middle-size finnish software company

  • RiosN. et al.

    Causes and effects of the presence of technical debt in agile software projects

    (2019)
  • PérezB. et al.

    Familiarity, causes and reactions of software practitioners to the presence of technical debt: A replicated study in the chilean software industry

  • RiosN. et al.

    Hearing the voice of software practitioners on causes, effects, and practices to deal with documentation debt

  • PachecoA. et al.

    Technical debt in costa rica: An insightd survey replication

  • Cited by (11)

    • IT managers’ perspective on Technical Debt Management

      2023, Journal of Systems and Software
    • Software practitioners’ point of view on technical debt payment

      2023, Journal of Systems and Software
      Citation 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 Technology
      Citation 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 Quarterly
      Citation 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).

    View all citing articles on Scopus
    View full text