No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Identification and Management of Technical Debt: A Systematic Mapping Study
Abstract
Context
The technical debt metaphor describes the effect of immature artifacts on software maintenance that bring a short-term benefit to the project in terms of increased productivity and lower cost, but that may have to be paid off with interest later. Much research has been performed to propose mechanisms to identify debt and decide the most appropriate moment to pay it off. It is important to investigate the current state of the art in order to provide both researchers and practitioners with information that enables further research activities as well as technical debt management in practice.
Objective
This paper has the following goals: to characterize the types of technical debt, identify indicators that can be used to find technical debt, identify management strategies, understand the maturity level of each proposal, and identify what visualization techniques have been proposed to support technical debt identification and management activities.
Method
A systematic mapping study was performed based on a set of three research questions. In total, 100 studies, dated from 2010 to 2014, were evaluated.
Results
We proposed an initial taxonomy of technical debt types, created a list of indicators that have been proposed to identify technical debt, identified the existing management strategies, and analyzed the current state of art on technical debt, identifying topics where new research efforts can be invested.
Conclusion
The results of this mapping study can help to identify points that still require further investigation in technical debt research.
... Focus group participants introducing themselves. 2 See www.rethought.se. ...
... Identification and Management of Technical Debt: A Systematic Mapping Study [2] x P6 Managing Architectural Technical Debt: A Unified Model and Systematic Literature Review [11] x P7 A tertiary study on technical debt: Types, management strategies, research trends, and base information for practitioners [57] x P8 A systematic literature review on Technical Debt prioritization: Strategies, processes, factors, and tools [45] x P9 Investigate, identify and estimate the technical debt: a systematic mapping study [8] x that P7 has fewer categories since the study is on the specific topic of Architectural Technical Debt. ...
... System Requirements AM1. 2 "System Requirements are the requirements for the system as a whole. System Requirements [...] encompass user requirements, requirements of other stakeholders (such as regulatory authorities), and requirements without an identifiable human source." ...
... Although it was initially associated with code level issues, TD can impact any type of software artifact and activity (Alves et al. 2016, Rios et al. 2018. For example, outdated requirement documentation can lead to a code that does not meet user requirements. ...
... Despite the growing number of studies on TD, there is a clear concentration of studies investigating it from the source code and its related artifacts perspective (Zazworka et al. 2014, Alves et al. 2016, Rios et al. 2018. Focusing solely on coding is risky business, because TD can affect many other software activities. ...
... TD can be incurred at any time and in several artifacts throughout the software development process. As such, it has different characteristics depending on the time it was incurred and the activities it is related to, such as testing, code, build, documentation, and so on (Alves et al. 2016). Although TD is a rising research topic, many studies focus solely on its relationship to source code. ...
Context: The presence of technical debt (TD) brings risks to software projects. Managers must continuously find a cost-benefit balance between the benefits of incurring in TD and the costs of its presence in a software project. Much attention has been given to TD related to coding issues, but other types of debt can also have impactful consequences on projects. Aims: This paper seeks to elaborate on the growing need to expand TD research to other areas of software development, by analyzing six elements related to TD management, namely: causes, effects, preventive practices, reasons for non-prevention, repayment practices, and reasons for non-repayment of TD. Method: We survey and analyze, quantitatively and qualitatively, the answers of 653 software industry practitioners on TD to investigate how the previously mentioned elements are related to coding and non-coding issues of the software development process. Results: Coding issues are commonly related to the investigated elements but, indeed, they are only part of the TD Management stage. Issues related to the project planning and management, human factors, knowledge, quality, process, requirements, verification, validation, and test, design, architecture, and the organization are also common sources of TD. We organize the results in a hump diagram and specialize it considering the point of view of practitioners that have used agile, hybrid, and traditional process models in their projects. Conclusion: The hump diagram, in combination with the detailed results, provides guidance on what to expect from the presence of TD and how to react to it considering several issues of software development. The results shed light on TD management of software elements, beyond source code related artifacts.
... Similarly, a systematic review was conducted in Ampatzoglou et al. [3], where the goal was to analyze research efforts on TD by considering the financial aspects. Then, Mendonça et al. [2] reported a systematic study investigating the TD types and TDM strategies. ...
... The study protocol was iteratively prepared, and researchers selected a sub-set of selected papers explored in the pilot study as input to conduct the "study protocol". Moreover, we adapted protocols of published secondary studies in the TD and Intelligent Techniques research areas to be more aligned with the literature [2,7,16,17]. We refined the protocol items for each iteration based on the initial results. ...
... To provide adequate support to answer our RQs, we first provided an overview of the extracted data, as illustrated in Table 1), row ID's Pr1-Pr7. Furthermore, we used other classifications that have been successfully used in other studies [2,7,16]. For Pr8 and Pr9, we used the classification presented by Perkusich et al. [17]. ...
Technical Debt (TD) is a consequence of decision-making in the development process that can negatively impact Software Quality Attributes (SQA) in the long term. Technical Debt Management (TDM) is a complex task to minimize TD that relies on a decision process based on multiple and heterogeneous data that are not straightforward to synthesize. Recent studies show that Intelligent Techniques can be a promising opportunity to support TDM activities since they explore data for knowledge discovery, reasoning, learning, or supporting decision-making. Although these techniques can improve TDM activities, there is a need to identify and analyze solutions based on Intelligent Techniques to support TDM activities and their impact on SQA. For doing so, a Systematic Mapping Study was performed, covering publications between 2010 and 2020. From 2276 extracted studies, we selected 111 unique studies. We found a positive trend in applying Intelligent Techniques to support TDM activities being Machine Learning and Reasoning Under Uncertainty the most recurrent ones. Design and Code were the most frequently investigated TD types. TDM activities supported by intelligent techniques impact different characteristics of SQA, mainly Maintainability, Reliability, and Security. Although the research area is up-and-coming, it is still in its infancy, and this study provides a baseline for future research.
... Several types of TD have been studied and presented in the literature [2]. In the systematic mapping carried out by Alves et al. [2] studies were identified reporting different types of TD, such as documentation, testing, requirements, infrastructure, people, usability, among others. ...
... Several types of TD have been studied and presented in the literature [2]. In the systematic mapping carried out by Alves et al. [2] studies were identified reporting different types of TD, such as documentation, testing, requirements, infrastructure, people, usability, among others. In this scenario, techniques and methods are proposed to support the identification and/or management of TD of specific types. ...
... Usability Technical Debt (UTD) is the result of decisions related to the usability of the software that is considered inappropriate and that will need to be adjusted later [8]. Examples of this debt are the lack of usability standards and inconsistency between the navigation aspects of the [2] software. ...
... Managing Technical Debt (TD) is vital in modern software development [15,25,26]. Indeed, identifying, documenting, and paying TD items can result in improved software quality and faster time to market [1]. However, technical debt-in the vast majority of software projects-is not managed at all, or at most, is managed using ad-hoc and informal activities and artifacts [9]. ...
... As we can observe, the story includes a meaningful title (flag #1, in the figure), a not too long description (flag #2), and an indication of TD, with the technical debt label (flag #3). 1 In practice, during TD Discovery the team should create a TD Backlog, which is essential to increase awareness and to plan the payment of the debts. In fact, previous frameworks also include the idea of such lists [12,24]. ...
The Technical Debt (TD) metaphor refers to the unavoidable maintenance and evolution costs of the not- quite-right decisions commonly taken by software developers. Due to its clear importance, developers usually document and manage TD by adopting ad-hoc and informal artifacts and activities. Thus, in this paper, we first propose a lightweight framework to support agile teams to manage and increase the awareness on TD. This framework, called LTD: Less Technical Debt Framework, has four key activities—TD Consensus, TD Discovery, TD Planning, and TD Payment—that can be easily plugged into current agile methodologies, such as Scrum. To assess the applicability of LTD in a real context, we also conduct a case study with two Scrum teams from a large public company. As a result, we achieved promising outcomes after adopting the framework. For example, the teams could reduce TD by creating a backlog of issues to pay during sprints.
... According to Alves, there are so many different types of technical debts [4]. ...
... The research summarized by Alvis [4] answers our first research question (RQ1). Although there are a few more types of technical debts, we mentioned only relevant types for this study. ...
Technical debt is a well-known challenge in software development, and its negative impact on software quality, maintainability, and performance is widely recognized. In recent years, artificial intelligence (AI) has proven to be a promising approach to assist in managing technical debt. This paper presents a comprehensive literature review of existing research on the use of AI powered tools for technical debt avoidance in software development. In this literature review we analyzed 15 related research papers which covers various AI-powered techniques, such as code analysis and review, automated testing, code refactoring, predictive maintenance, code generation, and code documentation, and explores their effectiveness in addressing technical debt. The review also discusses the benefits and challenges of using AI for technical debt management, provides insights into the current state of research, and highlights gaps and opportunities for future research. The findings of this review suggest that AI has the potential to significantly improve technical debt management in software development, and that existing research provides valuable insights into how AI can be leveraged to address technical debt effectively and efficiently. However, the review also highlights several challenges and limitations of current approaches, such as the need for high-quality data and ethical considerations and underscores the importance of further research to address these issues. The paper provides a comprehensive overview of the current state of research on AI for technical debt avoidance and offers practical guidance for software development teams seeking to leverage AI in their development processes to mitigate technical debt effectively
... Motivation. Since there exist different types of technical debt [38,39], we wish to have a deeper understanding of the types of suboptimal solutions that developers implement and acknowledge. Since blockchain is relatively novel and immature compared to other technologies (e.g., cloud computing), we wonder whether there are SATDs that are inherently associated with Ethereum characteristics (e.g., the gas system). ...
... To create our taxonomy, we perform card sorting on our extracted codes. Initially, the first author extracts a reference list of technical debt types and definitions from prior studies conducted in other domains [38,39,45,46]. Then, the first two authors run a hybrid card-sorting meeting during which they organize and abstract codes into major groups and eventually SATD types. ...
Programmable blockchain platforms such as Ethereum offer unique benefits to application development, including a decentralized infrastructure, tamper-proof transactions, and auditability. These benefits enable new types of applications that can bring competitive advantage to several business segments. Nonetheless, the pressure of time-to-market combined with relatively immature development technologies (e.g., the Solidity programming language), lack of high-quality training resources, and an unclear roadmap for Ethereum creates a context that favors the introduction of technical debt (e.g., code hacks, workarounds, and suboptimal implementations) into application code. In this paper, we study self-admitted technical debt (SATD) in smart contracts. SATD refers to technical debt that is explicitly acknowledged in the source code by developers via code comments. We extract 726k real-world contracts from Ethereum and apply both quantitative and qualitative methods in order to (i) determine SATD prevalence, (ii) understand the relationship between code cloning and SATD prevalence, and (iii) uncover the different categories of SATD. Our findings reveal that, while SATD is not a widespread phenomenon (1.5% of real-world contracts contain SATD), SATD does occur in extremely relevant contracts (e.g., multi-million contracts). We also observed a strong connection between SATD prevalence and code cloning activities, leading us to conclude that the former cannot be reliably studied without taking the latter into consideration. Finally, we produced a taxonomy for SATD that consists of 6 major and 26 minor categories. We note that several minor categories are bound to the domain of blockchain and smart contracts, including gas-inefficient implementations and Solidity-induced workarounds. Based on our results, we derive a set of practical recommendations for contract developers and introduce open research questions to guide future research on the topic.
... In the literature, objectoriented (OO) metrics, code smells, issues extracted from ASA tools, and software quality metrics extracted from quality assessment tools have been widely used as indicators able to monitor and quantify TD and the quality of software maintainability in general. 5,30,32 Most of the proposed TD indicators are related to software metrics 30,32 that allow the assessment of attributes, features, or characteristics of software artifacts. More specifically, in the context of OO programming, various sets of metrics, such as the metric suit proposed by Chidamber and Kemerer (C&K), 28 make it possible to characterize the size, complexity, coupling, and cohesion of the code among others. ...
... To this end, C&K metrics have been intensively studied and used for their ability to predict maintainability and maintenance effort, 33 which is the quality attribute that is most closely related to TD. Besides OO metrics, code smells are also a well-known indicator of the presence of code TD. 32,34 Code smells are warning signs indicating possible deeper problems in the design or code of software, often resulting from the violation of at least one programming principle. 35 These problems may impede the software maintenance process and impose the need for code refactoring. ...
Monitoring Technical Debt (TD) is considered highly important for software companies , as it provides valuable information on the effort required to repay TD and in turn maintain the system. When it comes to TD repayment however, developers are often overwhelmed with a large volume of TD liabilities that they need to fix, rendering the procedure effort demanding. Hence, prioritizing TD liabilities is of utmost importance for effective TD repayment. Existing approaches rely on the current TD state of the system; however, prioritization would be more efficient by also considering its future evolution. To this end, the present work proposes a practical approach for prioritization of TD liabilities by incorporating information retrieved from TD forecasting techniques, emphasizing on the class-level granularity to provide highly actionable results. Specifically, the proposed approach considers the change prone-ness and forecasted TD evolution of software artefacts and combines it with proper visualization techniques, to enable the early identification of classes that are more likely to become unmaintainable. To demonstrate and evaluate the approach, an empirical study is conducted on six real-world applications. The proposed approach is expected to facilitate developers better plan refactoring activities, in order to manage TD promptly and avoid unforeseen situations long-term.
... TD is a metaphor first introduced by Ward Cunningham to reflect the added software system cost or effort accrued from taking early software project shortcuts (Kruchten et al. 2012;Cunningham 1992). The metaphor embodies that debt accumulates interest: the later it is paid, the more it costs Kruchten et al. 2012;Alves et al. 2016). Taking on TD can yield short-term benefits at a consequence of a sub-optimal design or system changes that are difficult to maintain long term (Kruchten et al. 2012;Lenarduzzi et al. 2019;Rios et al. 2020;Cunningham 1992;Suryanarayana et al. 2014). ...
... The software engineering community has gone to great lengths to understand the current status of TD and TDM (Li et al. 2015;Ampatzoglou et al. 2015;Fernández-Sánchez et al. 2017;Alves et al. 2016;Rios et al. 2018). Fortunately, reviewing the software engineering literature revealed that Stack Exchange Q&A websites can provide valuable, real world perspectives on a number of software engineering topics (Silva et al. 2021; Barua et al. 2014). ...
Technical debt (TD) is a term coined by agile software pioneer Ward Cunningham to account for the added software system effort or cost resulting from taking early software project shortcuts. Previous research on TD has extensively outlined and discussed the various consequences derived from accumulating TD and the difficulty in managing it. A review of the software engineering literature revealed that Stack Exchange question-and-answer (Q&A) websites can provide valuable, real world perspectives on a number of software engineering topics. Therefore, this study aims to observe how the TD term is utilized on Stack Exchange Q&A websites. Specifically, this study utilizes a dataset derived from three Stack Exchange Q&A websites, which are Stack Overflow (SO), Software Engineering (SE), and Project Management (PM), to retrieve and analyze 578 TD-related questions. The results unveiled that TD-related questions can be categorized into 14 different categories, a total of 636 unique tags are utilized in the acquired set of TD-related questions, and a few TD-related categories both lack accepted answers and have a longer median time to receive an accepted answer than other categories. This study’s findings highlight the TD-related challenges that are addressed by Stack Exchange Q&A website users, which may prove beneficial in steering future TD-related efforts.
... There are effective tools, such as CAST 3 , and SonarQube 4 , which are mostly used due to their features and functionality, to measure and track TD in source code [4]. But these tools are no longer sufficient because they only allow you to identify the debt once it has been introduced, and sometimes it may be too late to remedy it. ...
... Numerous research has been undertaken and published in the literature on the methodology that might support developers and project managers in estimating and measuring TD [3,18,9,8,15]. The authors of the study [11] made a comparison based on the functionality and popularity of all existing tools capable of identifying TD. ...
Technical Debt describes a deficit in terms of functions, architecture, or integration, which must subsequently be filled to allow a homogeneous functioning of the product itself or its dependencies. It is predominantly caused by pursuing rapid development versus a correct development procedure. Technical Debt is therefore the result of a non-optimal software development process, which if not managed promptly can compromise the quality of the software. This study presents a technical debt trend forecasting approach based on the use of a temporal convolutional network and a broad set of product and process metrics, collected commit by commit. The model was tested on the entire evolutionary history of two open-source Java software systems available on Github: Commons-codec and Commons-net. The results are excellent and demonstrate the effectiveness of the model, which could be a pioneer in developing a TD reimbursement strategy recommendation tool that can predict when a software product might become too difficult to maintain.KeywordsTechnical debtSonarQubeSoftware quality metricsProcess metricsFeature selectionTemporal convolutional network
... They define several attributes of TD, such as technical bankruptcy, but do not provide a full ontology and their definitions do not necessarily extend beyond the field of software engineering. Alves, et al. extended their earlier work to provide a taxonomy of TD types [18]. Several other authors have proposed taxonomies related to TD [13], [19], [20], but the taxonomies focus on classifying TD and do not provide consistent definitions that can be uses across industries [21]. ...
The technical debt metaphor is used to describe the long-term consequences of engineering decisions made to achieve a short-term benefit. The metaphor originated in the field of software engineering and has begun to migrate to other fields, including systems engineering. The usage of the metaphor, its associated terminology, and basic definitions vary both within the software field and within the greater engineering community. The lack of consistent definitions inhibits the ability of system developers to understand and control technical debt within their system developments. This paper presents an ontology for technical debt, focusing on the field of systems engineering. By providing a set of concise and consolidated definitions, this ontology enables precise discussion of technical debt and associated techniques for mitigating its impact within systems engineering.
... If left unmanaged, TD can lead, among other consequences, to lower development speed, raise of a high number of bugs, or even completely crystallized architectures [32]. TD has been widely covered in academic literature [3,25,33] and is increasing in research popularity. Similarly, albeit the adoption of microservice architectural style could be considered as a relatively new phenomenon, its widespread adoption recently drew a considerable academic interest [12,16,30]. ...
Background: Albeit the growing academic and industrial interest in microservice architectures and technical debt, to date no study aimed to investigate the evolution characteristics of technical debt in software-intensive systems based on such architecture.
Aims: The goal of this study is to understand how technical debt evolves in microservice-based software-intensive systems, in terms of (i) evolution trends, and (ii) relation between technical debt and number of microservices.
Method: We adopt a case study based on an application comprising 13 microservices, 977 commits, and 38k lines of code. The research method is based on repository mining and automated source code analysis complemented via manual code inspection.
Results: While long periods of development without TD increase are observed, TD overall increases in time. TD variations can happen regardless of the number of microservices and development activity considered in a commit. TD and number of microservices are strongly correlated, albeit not always. Adding (or removing) a microservice has a similar impact on TD regardless of the number of microservices already present in a software-intensive system.
Conclusions: Adherence to microservice architecture principles might keep technical debt compartmentalized within microservices and hence more manageable. Developers should pay keen attention to the technical debt they may introduce, regardless of the number of microservice they touch with a commit and the development activity they carry out. Keeping technical debt constant during the evolution of a microservice-based architecture is possible, but the growth of technical debt while a software-intensive systems becomes bigger and more complex might be inevitable.
... Technical Debt (TD) is a metaphor used to describe suboptimal artifacts created as a result of design and implementation choices that, while they may achieve short-term objectives, may cause issues during the maintenance and evolution phases of a software project [10]. TD can be incurred during any phase of the software development lifecycle but primarily impacts software maintenance [11]. Inadequate TD management can result in higher costs, poor product quality, and a slowdown in the long-term success of software development [12]. ...
Background: Software security is crucial to ensure that the users are protected from undesirable consequences such as malware attacks which can result in loss of data and, subsequently, financial loss. Technical Debt (TD) is a metaphor incurred by suboptimal decisions resulting in long-term consequences such as increased defects and vulnerabilities if not managed. Although previous studies have studied the relationship between security and TD, examining their intersection in developers' discussion on Stack Overflow (SO) is still unexplored. Aims: This study investigates the characteristics of security-related TD questions on SO. More specifically, we explore the prevalence of TD in security-related queries, identify the security tags most prone to TD, and investigate which user groups are more aware of TD. Method: We mined 117,233 security-related questions on SO and used a deep-learning approach to identify 45,078 security-related TD questions. Subsequently, we conducted quantitative and qualitative analyses of the collected security-related TD questions, including sentiment analysis. Results: Our analysis revealed that 38% of the security questions on SO are security-related TD questions. The most recurrent tags among the security-related TD questions emerged as "security" and "encryption." The latter typically have a neutral sentiment, are lengthier, and are posed by users with higher reputation scores. Conclusions: Our findings reveal that developers implicitly discuss TD, suggesting developers have a potential knowledge gap regarding the TD metaphor in the security domain. Moreover, we identified the most common security topics mentioned in TD-related posts, providing valuable insights for developers and researchers to assist developers in prioritizing security concerns in order to minimize TD and enhance software security.
... Technical Debt (TD) is a metaphor used to describe suboptimal artifacts created as a result of design and implementation choices that, while they may achieve short-term objectives, may cause issues during the maintenance and evolution phases of a software project [10]. TD can be incurred during any phase of the software development lifecycle but primarily impacts software maintenance [11]. Inadequate TD management can result in higher costs, poor product quality, and a slowdown in the long-term success of software development [12]. ...
Background: Software security is crucial to ensure that the users are protected from undesirable consequences such as malware attacks which can result in loss of data and, subsequently, financial loss. Technical Debt (TD) is a metaphor incurred by suboptimal decisions resulting in long-term consequences such as increased defects and vulnerabilities if not managed. Although previous studies have studied the relationship between security and TD, examining their intersection in developers' discussion on Stack Overflow (SO) is still unexplored. Aims: This study investigates the characteristics of security-related TD questions on SO. More specifically, we explore the prevalence of TD in security-related queries, identify the security tags most prone to TD, and investigate which user groups are more aware of TD. Method: We mined 117,233 security-related questions on SO and used a deep-learning approach to identify 45,078 security-related TD questions. Subsequently, we conducted quantitative and qualitative analyses of the collected security-related TD questions, including sentiment analysis. Results: Our analysis revealed that 38% of the security questions on SO are security-related TD questions. The most recurrent tags among the security-related TD questions emerged as "security" and "encryption." The latter typically have a neutral sentiment, are lengthier, and are posed by users with higher reputation scores. Conclusions: Our findings reveal that developers implicitly discuss TD, suggesting developers have a potential knowledge gap regarding the TD metaphor in the security domain. Moreover, we identified the most common security topics mentioned in TD-related posts, providing valuable insights for developers and researchers to assist developers in prioritizing security concerns in order to minimize TD and enhance software security.
... The increased vulnerabilities connected to coping strategies can be seen as a type of debt that has to be paid at a later pointe.g., coping debt. The idea of coping debt is conceptually connected to the understanding of technology debt, which stands on the principles of quick fixes that bear a cost organizations or development teams have to pay at later point (Alves et al., 2016;Seaman and Guo, 2011). Moreover, extant IS literature implies heuristics can be seen as source of technical debt (Tom et al., 2012), and therefore, can be understood as the mechanism leading to coping debt if enacted in a crisis situation. ...
This study focuses on digital operational resilience (DOR) to ensure the stability of increasingly integrated digital services, which is currently receiving heightened attention due to ongoing
environmental crisis situations. Researchers often relate DOR to planning and preparation activities, such as business continuity or disaster recovery planning. However, some types of organisations – such as scale-ups – tend to lack elaborate plans for crisis situations, mainly driven by their rapid growth and resource constraints. Such firms seem to regularly engage in non-routine responses to overcome sudden disruptions, namely heuristics (i.e., swift decisions) and improvisation (i.e., swift actions). We present preliminary results of an in-depth case study demonstrating how a FinTech scale-up applied heuristics
and improvisation for its crisis response. We show how the consequences of such non-routine responses go beyond immediate crisis resolution, incurring either negative effects that need to be managed (coping debt) or opportunities to be leveraged (new/revised business processes).
... Simultaneously, our finding calls for future research to gain more evidence to understand the role of these gaps for achieving DOR. Albeit incident management has been addressed by various academic circles, and has been connected to both firm's absorptive capacity [60,61], as well as to technical debt [62,63], the distinction between major and minor incidents (G6) does not appear to be broadly addressed in the IS literature on resilience. This is intriguing as existing IT governance frameworks (i.e., ITIL and COBIT) do distinguish among different incident types [5] indicating relevance for DOR of firms. ...
Regulatory bodies, driven by enhanced speed of digital transformations, seek to strengthen the resilience of information and communication technologies (ICT) to ensure their operational integrity. As a result, The Digital Operational Resilience Act (DORA) was recently proposed to unify and enhance ICT risk management of financial institutions by recommending stricter rules. ICT risk management has to date been mainly governed by ISO 27001:2013 standard in the context of information security governance. Based on qualitative content analysis, we firstly mapped ISO 27001:2013 to DORA and identified nine gaps in ISO 27001:2013 in relation to six general DORA requirements. While we find sufficient support in academic literature for six of the nine extensions suggested by DORA, three areas seem less supported: Threat-led penetration testing, major incident management, and ICT third-party risk management. We argue that these topics should serve academic interest to further our understanding of digital operational resilience in theory and practice.KeywordsDigital Operational ResilienceDORAISO 27001:2013Mapping analysisIT risk management
... TD has been established to be closely related to the maintainability quality attribute in [70], [71], [72], [73], especially in distributed software applications. These applications are one of the most important applications currently deployed. ...
Software security is one of the most critical concerns in modern software development, especially in safety-critical systems whose failure can lead to environmental damage, substantial property, or loss of human lives. In addition, flawed applications have been shown to exhibit unpredictable behavior while software products with numerous vulnerabilities present attack vectors that can be exploited by attackers. To address some of these problems, vulnerability prediction has been deployed for early detection of security risks in the software development lifecycle (SDLC). This can potentially facilitate decision making during the SDLC, resulting in the production of more secure software. Prioritizing security during SDLC permits developers and stakeholders to identify and resolve possible security concerns early on in the process. The aim of this paper is therefore to offer some in-depth review of software systems security issues. In addition, the various measures that have been put in place to mitigate security issues during SDLC are discussed.
... As previously stated, TD represents the effects of immature artifacts in the software evolution that bring short-term benefits but have to be adjusted later. The concept, whose scope was initially limited to source code and related artifacts, was expanded to consider different software development stages and work products (Alves et al., 2016). Rios, Mendonça, and Spínola (2018) provide a taxonomy with 15 types of TD, as described below: ...
Efficient Technical Debt Management (TDM) requires specialized guidance so that decisions taken are oriented to add value to the business. Because it is a complex problem that involves several variables, TDM requires a systemic look that considers professionals' experiences from different specialties. Guilds have been a means technology companies have united specialized professionals around a common interest, especially those using the Spotify methodology. This paper presents the experience of implementing a guild to support TDM's activities in a software development organization using the action research method. The project lasted three years, and approximately 120 developers were involved in updating about 63,300 source-code files, 2,314 test cases, 2,097 automated test scripts, and the build pipeline. The actions resulting from the TDM guild's efforts impacted the company's culture by introducing new software development practices and standards. Besides, they positively influenced the quality of the artifacts delivered by the developers. This study shows that, as the company acquires maturity in TDM, it increases the need for professionals dedicated to TDM's activities.
... Adicionalmente, la interpretación subjetiva de los principios ágiles puede llevar a malas prácticas para entregar prematuramente el sistema, resultando en una acumulación progresiva de deuda técnica que degrada el beneficio a corto o mediano plazo, pero que debe pagarse en un tiempo determinado cumpliendo con los intereses que genera (Rios et al., 2020a;Hazzan y Dubinsky, 2014). En el contexto de la Ingeniería de Software, la deuda se relaciona con aquellas tareas o responsabilidades que no fueron realizadas durante el ciclo de vida o que fueron deficientes, generando intereses como: dilatación de las entregas, disminución de la productividad, baja calidad o insatisfacción del cliente y que deben pagarse a través de reprocesos, sobrecostos, sobrecarga de trabajo (Rios et al., 2020a), por ejemplo, el uso de malas prácticas de codificación puede llevar a futuras refactorizaciones y solución frecuente de incidentes que podrían ser evitados desde el principio mediante el uso de buenas prácticas de codificación, principios y patrones de diseño documentados correctamente (Li et al., 2015;Alves et al., 2016). ...
En el desarrollo de software, la documentación es un proceso continuo en el cual se especifica qué hace el sistema, cómo lo hace y para quién lo hace, describiendo todas sus características desde diferentes perspectivas para facilitar la comprensión de todos los interesados. Sin embargo, esto no siempre se logra, debido a malas prácticas de documentación, lo cual lleva a un tipo de deuda técnica conocida como deuda de la documentación, relacionada con documentación faltante, inconsistente o incompleta que degrada la comprensión del sistema, afectando gravemente su desarrollo, mantenimiento y evolución. Este fenómeno parece agravarse en los enfoques ágiles, ya sea por una mala interpretación de los valores y principios ágiles, enfocándose en la entrega continua de software funcional más que en la documentación exhaustiva, o por desconocimiento de buenas prácticas de documentación. Si bien existen iniciativas que describen de forma general las causas, efectos y buenas prácticas para mitigar la deuda de documentación, aún hace falta comprender el impacto de este tipo de deuda para la industria de software y profundizar en una definición más completa en el desarrollo ágil de software. En ese sentido, se presentan los resultados de un mapeo sistemático que brinda una base sólida de conocimiento sobre la deuda de la documentación en el desarrollo ágil de software y permite identificar brechas u oportunidades de investigación en este tema.
... In the literature, we have identified two systematic mapping studies related to TD identification-i.e., the process of understanding which artifacts suffer from TD. First, Alves et al. [8] collected and investigated approximately 100 studies. They highlight several TD indicators that can be used to identify the amount of TD of a system. ...
Quality improvement can be performed at the: (a) micro-management level: interventions applied at a fine-grained level (e.g., at a class or method level, by applying a refactoring); or (b) macro-management level: interventions applied at a large-scale (e.g., at project level, by using a new framework or imposing a quality gate). By considering that the outcome of any activity can be characterized as the product of
impact
and
scale
, in this paper we aim at exploring the impact of Technical Debt (TD) Macro-Management, whose scale is by definition larger than TD Micro-Management. By considering that TD artifacts reside at the micro-level, the problem calls for a nested model solution; i.e., modeling the structure of the problem: artifacts have some inherent characteristics (e.g., size and complexity), but obey the same project management rules (e.g., quality gates, CI/CD features, etc.). In this paper, we use the Under-Bagging based Generalized Linear Mixed Models approach, to unveil project management activities that are associated with the existence of HIGH_TD artifacts, through an empirical study on 100 open-source projects. The results of the study confirm that micro-management parameters are associated with the probability of a class to be classified as HIGH_TD, but the results can be further improved by controlling some project-level parameters. Based on the findings of our nested analysis, we can advise practitioners on macro-technical debt management approaches (such as “
control the number of commits per day
”, “
adopt quality control practices
”, and “
separate testing and development teams
”) that can significantly reduce the probability of all software artifacts to concentrate HIGH_TD. Although some of these findings are intuitive, this is the first work that delivers empirical quantitative evidence on the relation between TD values and project- or process-level metrics.
... On the one hand, in the short term, the costs of maintaining product functionality or production costs are reduced for the time being, on the other hand, despite present benefits, there will be cost implications in the future. The analysis of these dependencies is an important decisionmaking issue affecting the functioning of the whole company (Alves et al., 2016). The concept of technical debt was introduced into IT management practice in the 1990s by W. Cunningham and is gradually gaining increasing attention not only in this sector (Codabux et al., 2017). ...
... TD can be classified into several types from the perspective of different stages of the software development lifecycle, such as architecture TD and design TD (Tom et al., 2013;Li et al., 2015). Due to its significant impact on software quality, TD has been a hot topic attracting great attention from both academia and industry in the last decade (Li et al., 2015;Alves et al., 2016;Tufano et al., 2017;Kruchten et al., 2019;Ciolkowski et al., 2021;de Toledo et al., 2021;Ernst et al., 2021;Vidoni et al., 2022) , and many open source software (OSS) projects were used to explore various aspects of TD (Tsoukalas et al., 2020;Li et al., 2020b;Xiao et al., 2021;Tan et al., 2021;Yu et al., 2022). ...
Technical debt (TD) refers to delayed tasks and immature artifacts that may bring short-term benefits but incur extra costs of change during maintenance and evolution in the long term. TD has been extensively studied in the past decade, and numerous open source software (OSS) projects were used to explore specific aspects of TD and validate various approaches for TD management (TDM). However, there still lacks a comprehensive understanding on the practice of TDM in OSS development, which penetrates the OSS community's perception of the TD concept and how TD is managed in OSS development. To this end, we conducted an empirical study on the whole GitHub to explore the adoption and execution of TDM based on issues in OSS projects. We collected 35,278 issues labeled as TD (TD issues) distributed over 3,598 repositories in total from the issue tracking system of GitHub between 2009 and 2020. The findings are that: (1) the OSS community is embracing the TD concept; (2) the analysis of TD instances shows that TD may affect both internal and external quality of software systems; (3) only one TD issue was identified in 31.1% of the repositories and all TD issues were identified by only one developer in 69.0% of the repositories; (4) TDM was ignored in 27.3% of the repositories after TD issues were identified; and (5) among the repositories with TD labels, 32.9% have abandoned TDM while only 8.2% adopt TDM as a consistent practice. These findings provide valuable insights for practitioners in TDM and promising research directions for further investigation.
... Both are based on a framework proposed by Alves et al. [2]. Additionally, Alves et al. in [25] conducted systematic mapping in around 100 studies, dated from 2010 to 2014. In our study, we followed the same taxonomy and definitions, at least for the five types of SATD that we used. ...
Recent studies show that it is possible to detect technical dept automatically from source code comments intentionally created by developers, a phenomenon known as self-admitted technical debt. This study proposes a system by which a comment or commit is classified as one of five dept types, namely, requirement , design, defect, test, and documentation. In addition to the traditional term frequency-inverse document frequency (TF-IDF), several word embed-dings methods produced by different pre-trained language models were used for feature extraction, such as Word2Vec, GolVe, bidirectional encoder representations from transformers (BERT), and FastText. The generated features were used to train a set of classifiers including naive Bayes (NB), random forest (RF), support vector machines (SVM), and two configurations of convolutional neu-ral network (CNN). Two datasets were used to train and test the proposed systems. Our collected dataset (A-dataset) includes a total of 1,513 comments and commits manually labeled. Additionally, a dataset, consisting of 4,071 labeled comments, used in previous studies (M-dataset) was also used in this study. The RF classifier achieved an accuracy of 0.822 with A-dataset and 0.820 with the M-dataset. CNN with A-dataset achieved an accuracy of 0.838 using BERT features. With M-dataset, the CNN achieves an accuracy of 0.809 and 0.812 with BERT and Word2Vec, respectively. This is an open access article under the CC BY-SA license.
... Just like senescence which operates under the principles of antagonistic pleiotropy, developing software systems that do not incorporate easy options of maintenance and removability from the beginning on gradually lead to technical debt (Alves et al. 2016). ...
In the last decades it became clear that, more often than not, software engineers were focused on delivering new features and in the process generated highly complex interacting layers and modules of software. Over long periods of times, very old legacy code interacts in complex ways with new code. Various studies imply that software aging is a phenomenon whereupon continuous execution of programs leads to a gradual build-up of errors and overall degradation of performance. Strange and unclear behaviour emerges from interactions of new and old modules, which in the worst case manifest itself in crashes, errors and other unwanted responses. This has especially drastic consequences for critical infrastructure networks like power grids or medical software, where conventional practices for error detection like controlled shutdowns and reboots are seldomly an option. Invaluable for early detection of such issues are non-invasive methods which would serve as detectors to assess when, for example, a software module begins to show first symptoms of developing aging related problems. Bio-inspired approaches are now a major player in software engineering, as processes like Darwinian evolution, mutation and learning are employed in more and more software systems. While first technology assessment methodologies concerning software aging have been developed none drew inspiration from the natural sciences, where, especially in the last few decades, biogerontology-the science of processes of aging and its consequences-has begun to pick up serious steam. By abstracting similar processes in biology and computer science the fundamental problems and their solutions can be analyzed and then transferred from one discipline to another. Recent discoveries showed that chronological age is not always an accurate variable to define a cell's or an organism's biological age, as different organisms and even different cell types within those organisms age at different rates. Similarly, it is important to not use chronological age as the only parameter to determine if and when code ages. Very old code that continuously gets maintained and cautiously ported to new platforms might exhibit less
... Visualizations help humans acquire more information through vision than through the other senses. However, little has been investigated on TD visualization [9,10], and less about TD visualization with a holistic perspective that integrates Kruchten's \inside-out" (technical and code-facing aspects of TD) and \outside-in" (business and customer-facing aspects of TD) elements [3]. In this paper, we are interested in TD decision-making events that involve stakeholders from di®erent functional areas of the organization. ...
Context: Technical debt (TD) is a challenge for companies who develop software on which their critical operations depend. To properly manage TD, it is necessary to make it visible to the different stakeholders involved to support informed decisions. Objective: To validate a TD visualization approach based on hybrid Sankey diagrams that makes the TD visible by showing (a) technical and business aspects, and (b) the flow of value and TD impacts. This approach regards visualizations as boundary objects. Method: We performed a multi-case study in a large multi-industry state-owned company. The objective was to validate the effectiveness of such visualizations and to explore their possible uses in TD management. We first used a retrospective case study on a TD decision-making scenario and, later, visualization usage scenarios using focus groups to evaluate its usefulness. Results: The results suggest that the proposed approach: (a) provides a structured process for systematic TD visualization to help the decision-making process; (b) enables the communication at knowledge boundaries between stakeholders to make informed decisions; (c) uses flow representations that are important for assessing the impact in multiple functional areas; and (d) enables documentation and reuse. Conclusion: The study results suggest that TD decision-making events can benefit from using our TD visualizations based on hybrid Sankey diagrams as boundary objects to portray the impact of TD in business, services, and technical aspects.
... An example of a code smell that this study and future work aims to address is the God Class, as well as several other smells. Alves et al. mention that God Classes can be up to 13 times more likely to contain faults embedded within the smell itself [2]. For this reason, it is imperative to dive deeper within large classes and methods and examine their occurrences since these smells are detrimental. ...
Although code smells are not categorized as a bug, the results can be long-lasting and decrease both maintainability and scalability of software projects. This paper presents findings from both former and current industry individuals, aiming to gauge their familiarity with such violations. Based on the feedback from these individuals, a collection of smells were extracted from a sample size of 100 Java repositories in order to validate some of the smells that are typically encountered. After analyzing these repositories, the smells typically encountered are Long Statement, Magic Number, and Unutilized Abstraction. The results of this study are applicable for developers and researchers who require insight on the frequencies of code smells within a typical repository.
Software development projects often fail because of insufficient code quality. It is now well documented that the task of testing software, for example, is perceived as uninteresting and rather boring, leading to poor software quality and major challenges to software development companies. One promising approach to increase the motivation for considering software quality is the use of gamification. Initial research works already investigated the effects of gamification on software developers and come to promising. Nevertheless, a lack of results from field experiments exists, which motivates the chapter at hand. By conducting a gamification experiment with five student software projects and by interviewing the project members, the chapter provides insights into the changing programming behavior of information systems students when confronted with a leaderboard. The results reveal a motivational effect as well as a reduction of code smells.
Working solutions to problems are not definitive end points. As a result, code that is technically correct can still be treated as needing revising – a practice in computer programming known as refactoring. We document how late elementary to middle school students and their undergraduate instructors weigh the possibility of refactoring working code in an informal summer computer science workshop. We examined a 20-min stretch of classroom activity in which multiple coding approaches were explicitly evaluated as alternative routes to the same code output. Our theoretical framework draws on the stance triangle, amplifying and attenuating inequity, and an extension of sociomathematical norms. Using the method of interaction analysis, we transcribed and analyzed stretches of talk, gesture, and action during whole class dicourse and small group interactions involving 4–6 students. We investigated how instructors and students introduced, characterized, applied, and contested sociocomputational norms through stancetaking in classroom discourse, which shaped whose voices contributed to the discussion and whose ideas were treated as impactful and praiseworthy in the classroom. Because it is within these discourse spaces that instructors and students interpret and reinterpret sociocomputational norms about what is valued in programming approaches, educational researchers and teachers might attend to these conversation dynamics as one route to fostering more supportive and inclusive learning spaces.
Technical debt is a concept used to describe the lack of good practices during software development, leading to several problems and costs. Identification and management strategies can help reduce these difficulties. In a previous study, Alves et al. (2016) analyzed the research landscape of such strategies from 2010 to 2014. This paper replicates and updates their study to explore the evolution of technical debt identification and management research landscape over a decade, including literature from 2010 until 2022. We analyzed 117 papers from the ACM Digital Library, IEEE Xplore, Science Direct, and Springer Link. Newly suggested strategies include automatically identifying admitted debt in comments, commits, and source code. Between 2015 and 2022, more empirical evaluations have been performed, and the general research focus has changed to a more holistic approach. Therefore, the research area evolved and reached a new level of maturity compared to previous results from Alves et al. (2016). Not only are code aspects considered for technical debt, but other aspects have also been investigated (e.g., models for the development process).
Enterprise software requires constant updates to keep it usable. These updates originate in correcting errors and mainly in new organizational demands. Over time, these demands generate a significant workload that becomes increasingly complex than the first requirements. For this reason, the organization providing the software may choose to continue updating the old product or make it obsolete and replace it with a new one. Identifying the ideal moment to carry out this migration involves, in addition to the costs of keeping the product obsolete for a while, the effort to develop a new one. This work addresses a case study that comprises fifteen years with two migrations of the software project. Due to the availability of the collection of activities performed by the development and support team, performed sequentially over time, the applicability of time series was possible. Furthermore, the historical base of the activities performed made it possible to use the time series decomposition to obtain its trend, seasonality and noise. Time series decomposition indicated many random events in the first migration, while in the second, the team self-regulated, but there were tension points. This study identified a preliminary model whose purpose is to determine when to develop a new software version.
Given the changing workloads from the tenants, it is not uncommon for a service composition running in the multi-tenant SaaS cloud to encounter under-utilization and over-utilization on the component services. Both cases are undesirable and it is therefore nature to mitigate them by recomposing the services to a newly optimized composition plan once they have been detected. However, this ignores the fact that under-/over-utilization can be merely caused by temporary effects, and thus the advantages may be short-term, which hinders the long-term benefits that could have been created by the original composition plan, while generating unnecessary overhead and disturbance via recomposition. In this paper, we propose
DebtCom
, a framework that determines whether to trigger recomposition based on the technical debt metaphor and time-series prediction of workload. In particular, we propose a service debt model, which has been explicitly designed for the context of service composition, to quantify the debt. Our core idea is that recomposition can be unnecessary if the under-/over-utilization only cause temporarily negative effects, and the current composition plan, although carries debt, can generate greater benefit in the long-term. We evaluate
DebtCom
on a large scale service system with up to 10 abstract services, each of which has 100 component services, under real-world dataset and workload traces. The results confirm that, in contrast to the state-of-the-art,
DebtCom
achieves better utility while having lower cost and number of recompositions, rendering each composition plan more sustainable.
The metaphor of Technical Debt (TD) has generated a conceptual framework on factors that weaken the quality of software and accumulate a repair cost. However, user-related aspects like user experience (UX) receive little consideration among TD types, for reasons like the substantial focus on code TD, some dynamics inherent to agile processes, and an apparent lack of cumulative cost over time. This article has two main goals: first, to present evidence of the existence of UXDebt as a type of TD, with a cumulative cost for the development team as well as stakeholders; second, to propose a definition and characterization of UXDebt that may serve as a frame for further research on methods and tools for continuous management within agile processes. For the first goal, we have compiled evidence on the current state of UXDebt from three sources: a literature review, a survey among software engineering professionals in agile teams, and the analysis of UX issues in GitHub. All sources have evidenced some form of UXDebt; surveyed practitioners have recognized its poor management with a cost for the entire team that accumulates over time. Moreover, issue-tracking systems allow to visualize and measure a technical form of UXDebt. For the second goal, we have defined a conceptual model that characterizes UXDebt in terms of both technical and non-technical aspects. On the technical side, we propose the notion of UX smells which allows us to discuss concrete management activities.
Background. Companies frequently try to improve the quality of their software by resolving technical issues that are perceived to have an impact on software quality. Technical information is any information that may be gathered from the source code or the software development process, for instance: code or documentation guidelines, and the use of specific patterns. If these issues are not fixed they may generate technical debt. Goal. The goal of the Ph.D., which started on January 2022, is to understand which are the causes of Architectural Technical Debt in a real case study and to develop a Dashboard to notify developers as earlier as possible.Methods and expected contribution. We first plan to investigate the actual production code process and then, and then to work with teams to find the best practices and strategies to easily manage Architectural Technical Debt.KeywordsTechnical debtArchitectural debtSoftware quality
Within social networks, audio is a vehicle for violent, bullying or generally unwanted content. This research intends to propose an automatic tool for extracting text from an audio stream. Microsoft azure cognitive cloud services, and in particular, Speech SDK and bot SDK are used for extraction and recognition tasks. The extracted text can then be analyzed using techniques and algorithm known for analyzing critical situations such as violence or bullying but is applicable in any context.KeywordsAdagioAudio extractionSpeech recognitionMicrosoft AzureSpeech SDKBot SDK
This research proposal targets public sector ICT practices. The goal is to explore in-depth the causes of issues in public ICT. Furthermore, the goal is to fill research gaps in public agency and supplier interrelationships, EA practices, and intended public sector technological solutions. The proposed research binds these areas to establish a coherent framework for how ICT should be built and led in public agencies.KeywordsPublic procurementEnterprise architectureSustainable softwareInteroperability
Service-Oriented Architectures (SOA) have become a standard for developing software applications, including but not limited to cloud-based ones and enterprise systems. When using SOA, the software engineers organize the desired functionality into self-contained and independent services, that are invoked through end-points (API calls). At the maintenance phase, the tickets (bugs, functional updates, new features, etc.) usually correspond to specific services. Therefore, for maintenance-related estimates it makes sense to use as unit of analysis the service-per se, rather than the complete project (too coarse-grained analysis) or a specific class (too fine-grained analysis). Currently, some of the most emergent maintenance estimates are related to Technical Debt (TD), i.e., the additional maintenance cost incurred due to code or design inefficiencies. In the literature, there is no established way on how to quantify TD at the service level. To this end, in this paper, we present a novel methodology to measure the TD of each service considering the underlying code that sup-ports the corresponding endpoint. The proposed methodology relies on the method call graph, initiated by the service end-point, and traverses all methods that provide the service functionality. To evaluate the usefulness of this approach, we have conducted an industrial study, validating the methodology (and the accompanying tool) with respect to usefulness, obtained benefits, and usability.KeywordsTechnical debtService analysisEndpoint analysisQuality
Context
Technical debt (TD) payment refers to the activity of expending maintenance effort and resources to make up for the effects of previous technical compromises.
Aims
To investigate if software practitioners have paid debt items off in their projects, the practices that have been used for paying off debt items, and the issues that hamper the implementation of these practices.
Method
We analyze 653 responses collected by surveying practitioners from six countries about TD payment.
Results
Practitioners have not paid off TD items in most cases. We identified 27 reasons for not paying off those items and 32 payment-related practices. Practices are mainly related to internal quality issues, while reasons for not paying TD off are mostly associated with planning and management issues. Lastly, we identified relationships between practices and between reasons, indicating that both can appear in combination.
Conclusion
. We use different views to consolidate the set of information on TD payment, extending the conceptual model for TD and organizing the set of practices and reasons into a TD payment map. We believe that the model and the map can support practitioners in planning their TD payment strategy.
Technical Debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefits but might hurt the long-term health of a software system. With the increasing amount of data generated when performing software development activities, an emergent research field has gained attention: applying Intelligent Techniques to solve Software Engineering problems. Intelligent Techniques were used to explore data for knowledge discovery, reasoning, learning, planning, perception, or supporting decision-making. Although these techniques can be promising, there is no structured understanding related to their application to support Technical Debt Management (TDM) activities. Within this context, this study aims to investigate to what extent the literature has proposed and evaluated solutions based on Intelligent Techniques to support TDM activities. To this end, we performed a Systematic Mapping Study (SMS) to investigate to what extent the literature has proposed and evaluated solutions based on Intelligent Techniques to support TDM activities. In total, 150 primary studies were identified and analyzed, dated from 2012 to 2021. The results indicated a growing interest in applying Intelligent Techniques to support TDM activities, the most used: Machine Learning and Reasoning under uncertainty. Intelligent Techniques aimed to assist mainly TDM activities related to identification, measurement, and monitoring. Design TD, Code TD, and Architectural TD are the TD types in the spotlight. Most studies were categorized at automation levels 1 and 2, meaning that existing approaches still require substantial human intervention. Symbolists and Analogizers are levels of explanation presented by most Intelligent Techniques, implying that these solutions conclude a general truth after considering a sufficient number of particular cases. Moreover, we also cataloged the empirical research types, contributions, and validation strategies described in primary studies. Based on our findings, we argue that there is still room to improve the use of Intelligent Techniques to support TDM activities. The open issues that emerged from this study can represent future opportunities for practitioners and researchers.
The objective of this report is to propose comprehensive guidelines for systematic literature reviews appropriate for software engineering researchers, including PhD students. A systematic literature review is a means of evaluating and interpreting all available research relevant to a particular research question, topic area, or phenomenon of interest.
Systematic reviews aim to present a fair evaluation of a research topic by using a trustworthy, rigorous, and auditable methodology. The guidelines presented in this report were derived from three existing guidelines used by medical researchers, two books produced by researchers with social science backgrounds and discussions with researchers from other disciplines who are involved
in evidence-based practice. The guidelines have been adapted to reflect the specific problems of software engineering research.
The guidelines cover three phases of a systematic literature review: planning the review, conducting the review and reporting the review. They provide a relatively high level description. They do not consider the impact of the research questions on the review procedures, nor do they specify in detail the mechanisms needed to perform meta-analysis.
Technical debt is a term that has been used to describe the increased cost of changing or maintaining a system due to shortcuts taken during its development. As technical debt is a recent research area, its different types and their indicators are not organized yet. Therefore, this paper proposes an ontology of terms on technical debt in order to organize a common vocabulary for the area. The organized concepts derived from the results of a systematic literature mapping. The proposed ontology was evaluated in two steps. In the first one, some ontology design quality criteria were used. For the second one, a specialist in the area performed an initial evaluation. This work contributes to evolve the Technical Debt Landscape through the organization of the different types of technical debt and their indicators. We consider this an important contribution for both researchers and practitioners because this information was spread out in the literature hindering their use in research and development activities.
Fixing bugs is an important phase in software development and maintenance. In practice, the process of bug fixing may conflict with the release schedule. Such confliction leads to a trade-off between software quality and release schedule, which is known as the technical debt metaphor. In this article, we propose the concept of debt-prone bugs to model the technical debt in software maintenance. We identify three types of debt-prone bugs, namely tag bugs, reopened bugs, and duplicate bugs. A case study on Mozilla is conducted to examine the impact of debt-prone bugs in software products. We investigate the correlation between debt-prone bugs and the product quality. For a product under development, we build prediction models based on historical products to predict the time cost of fixing bugs. The result shows that identifying debt-prone bugs can assist in monitoring and improving software quality.
Understanding the impact of technical debt is critical to understanding a team's velocity. For organizations with multiple teams and products, the impact of technical debt combines non-linearly to impact the organization's velocity. We can think of the capacity of a team as a portfolio. Not all of that capacity can be invested in new features or defect fixing, without incurring negative consequences. A portion of the team's capacity needs to be invested in the ongoing management and reduction of technical debt. This paper describes a simple technique for visualizing, quantifying and tracking a team's technical debt as a portion of their overall capacity investment. The knowledge and insights gained through this technique help with better capacity planning, improved forecasting, and helps to justify the business case for investing in managing and reducing technical debt.
Often we find it difficult to incorporate any changes in a software project during later
phases of its development, or during post-delivery maintenance. Primary reason for this is
inflexibility in design and code which makes it difficult for changes to be incorporated. This
inflexibility substantially increases the cost of making changes and this metaphor has been
termed as Technical Debt [1]. While Technical Debt cannot be eliminated completely, its
burden needs to be reduced. Many practitioners, especially from agile community
Context: Technical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. Objective: This work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. Method: A systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. Results: Ninety-four studies were finally selected. TD was classified into ten types, eight TDM activities were identified, and twenty-nine tools for TDM were collected. Conclusions: The term “debt” has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
The main goal of this work is to evaluate the feasibility to calculate the technical debt (a traditional software quality approach) in a model-driven context through the same tools used by software deve-lopers at work. The SonarQube tool was used, so that the quality check was performed directly on projects created with Eclipse Modeling Frame-work (EMF) instead of traditionals source code projects. In this work, XML was used as the model specification language to verify in Sonar-Qube due to the creation of EMF metamodels in XMI (XML Metadata Interchange) and that SonarQube offers a plugin to assess the XML lan-guage. After this, our work focused on the definition of model rules as an XSD schema (XML Schema Definition) and the integration between EMF-SonarQube in order that these metrics were directly validated by SonarQube; and subsequently, this tool determined the technical debt that the analyzed EMF models could contain.
Sample size and power determination is the first step in the experimental design of a successful study. Sample size and power calculation is required for applications for National Institutes of Health (NIH) funding. Sample size and power calculation is well established for traditional biological studies such as mouse model, genome wide association study (GWAS), and microarray studies. Recent developments in high-throughput sequencing technology have allowed RNAseq to replace microarray as the technology of choice for high-throughput gene expression profiling. However, the sample size and power analysis of RNAseq technology is an underdeveloped area. Here, we present RNAseqPS, an advanced online RNAseq power and sample size calculation tool based on the Poisson and negative binomial distributions. RNAseqPS was built using the Shiny package in R. It provides an interactive graphical user interface that allows the users to easily conduct sample size and power analysis for RNAseq experimental design. RNAseqPS can be accessed directly at http://cqs.mc.vanderbilt.edu/shiny/RNAseqPS/.
Technical debt has recently become a major concern in the software industry. While it has been shown that technical debt has an adverse effect on the quality of a software system, there has been little work to explore this relationship. Further, with the growing number of approaches to estimate the technical debt principal of a software system, there is a dearth of work to empirically validate the relationship between technical debt scores produced by practical tools against established theoretical quality models. We conducted a case study across 10 releases of 10 open source systems in order to evaluate three proposed methods of technical debt principal estimation. The evaluation compares each technique against an external quality model. We found that only one estimation technique had a strong correlation to the quality attributes reusability and understand ability. In a multiple linear regression analysis we also found that a different estimation technique had a significant relationship to the quality attributes effectiveness and functionality. These results indicate that it is important that industry practitioners, ensure that the technical debt estimate they employ accurately depicts the effects of technical debt as viewed from their quality model.
NB You can find the journal version of this article published as "investigating technical debt accumulation and refactoring over time: a multiple case study" also available in this website from the same authors.
Abstract
A known problem in large software companies is to balance the prioritization of short-term with long-term responsiveness. Specifically, architecture violations (Architecture Technical Debt) taken to deliver fast might hinder future feature development, which would hinder agility. We conducted a multiple-case embedded case study in 7 sites at 5 large companies in order to shed light on the current causes for the accumulation of Architectural Technical Debt that causes effort. We provide a taxonomy of the factors and their influence in the accumulation of debt, and we provide a qualitative model of how the debt is accumulated and recovered over time.
We develop an evolutionary model and theory of software technical debt accumulation to facilitate a rigorous and balanced analysis of its benefits and costs in the context of a large commercial enterprise software package. Our theory focuses on the optimization problem involved in managing technical debt, and illustrates the different tradeoff patterns between software quality and customer satisfaction under early and late adopter scenarios at different lifecycle stages of the software package. We empirically verify our theory utilizing a ten year longitudinal dataset drawn from 69 customer installations of the software package. We then utilize the empirical results to develop actionable policies for managing technical debt in enterprise software product adoption.
Architectural technical debt (ATD) is incurred by design decisions that consciously or unconsciously compromise system-wide quality attributes, particularly maintainability and evolvability. ATD needs to be identified and measured, so that it can be monitored and eventually repaid, when appropriate. In practice, ATD is difficult to identify and measure, since ATD does not yield observable behaviors to end users. One indicator of ATD, is the average number of modified components per commit (ANMCC): a higher ANMCC indicates more ATD in a software system. However, it is difficult and sometimes impossible to calculate ANMCC, because the data (i.e., the log of commits) are not always available. In this work, we propose to use software modularity metrics, which can be directly calculated based on source code, as a substitute of ANMCC to indicate ATD. We validate the correlation between ANMCC and modularity metrics through a holistic multiple case study on thirteen open source software projects. The results of this study suggest that two modularity metrics, namely Index of Package Changing Impact (IPCI) and Index of Package Goal Focus (IPGF), have significant correlation with ANMCC, and therefore can be used as alternative ATD indicators.
This study summarizes results of a study of Technical Debt across 745 business applications comprising 365 million lines of code collected from 160 companies in 10 industry segments. These applications were submitted to a static analysis that evaluates quality within and across application layers that may be coded in different languages. The analysis consists of evaluating the application against a repository of over 1200 rules of good architectural and coding practice. A formula for estimating Technical Debt with adjustable parameters is presented. Results are presented for Technical Debt across the entire sample as well as for different programming languages and quality factors.
The management of technical debt ultimately requires decision making - about incurring, paying off, or deferring technical debt instances. This position paper discusses several existing approaches to complex decision making, and suggests that exploring their applicability to technical debt decision making would be a worthwhile subject for further research.
To date, several methods and tools for detecting source code and design anomalies have been developed. While each method focuses on identifying certain classes of source code anomalies that potentially relate to technical debt (TD), the overlaps and gaps among these classes and TD have not been rigorously demonstrated. We propose to construct a seminal technical debt landscape as a way to visualize and organize research on the subject.
Measurements are subject to random and systematic errors, yet almost no study in software engineering makes significant efforts in reporting these errors. Whilst established statistical techniques are well suited for the analysis of random error, such techniques are not valid in the presence of systematic errors. We propose a departure from de- facto methods of reporting results of technical debt measurements for more rigorous techniques drawn from established methods in the physical sciences. This line of inquiry focuses on technical debt calculations; however it can be generalized to quantitative software engineering studies. We pose research questions and seek answers to the identification of systematic errors in metric-based tools, as well as the reporting of such errors when subjected to propagation. Exploratory investigations reveal that the techniques suggested allow for the comparison of uncertainties that come from differing sources. We suggest the study of error propagation of technical debt is a worthwhile subject for further research and techniques seeded from the physical sciences present viable options that can be used in software engineering reporting.
We identified and organized a number of statements about technical debt (TD Folklore list) expressed by practitioners in online websites, blogs and published papers. We chose 14 statements and we evaluated them through two surveys (37 practitioners answered the questionnaires), ranking them by agreement and consensus. The statements most agreed with show that TD is an important factor in software project management and not simply another term for “bad code”. This study will help the research community in identifying folklore that can be translated into research questions to be investigated, thus targeting attempts to provide a scientific basis for TD management.
In cloud marketplace, cloud-based system architectures can be composed of web services, which are leased or bought off the cloud. These architectures can add value to its composition by switching and substituting its constituent services. The value-added can relate to improved Quality of Service (QoS), new revenue streams by enabling new business models, reduced operational cost and so forth. The selection and substitution decisions may introduce a technical debt, however. We specifically look at the debt of substitution decisions in support for scaling up scenarios. This debt may need to be managed, cleared and transformed to value-added. We take an option-based approach to inform the selection of candidate web services with varying debt. For every selection, we quantify the extent to which it can clear the debt and provide future options.
Technical debt is the consequence of trade-offs made during software development to ensure speedy releases. The research community lacks rigorously evaluated guidelines to help practitioners characterize, manage and prioritize debt. This paper describes a study conducted with an industrial partner during their implementation of Agile development practices for a large software development division within the company. The report contains our initial findings based on ethnographic observations and semi-structured interviews. The goal is to identify the best practices regarding managing technical debt so that the researchers and the practitioners can further evaluate these practices to extend their knowledge of the technical debt metaphor. We determined that the developers considered their own taxonomy of technical debt based on the type of work they were assigned and their personal understanding of the term. Despite management's high-level categories, the developers mostly considered design debt, testing debt and defect debt. In addition to developers having their own taxonomy, assigning dedicated teams for technical debt reduction and allowing other teams about 20% of time per sprint for debt reduction are good initiatives towards lowering technical debt. While technical debt has become a well-regarded concept in the Agile community, further empirical evaluation is needed to assess how to properly apply the concept for various development organizations.
Short release duration -- the time from starting development until it delivers measurable value (i.e., paying customers adopt an upgrade) -- is an implied goal of agile methods. Release duration incorporates the expensive parts of the value chain: build, test, deploy and sell (but not exploratory design, for example). Release duration correlates with technical debt. Attempting to reduce release duration may help drive agile behavior through a company. Finance departments often collect release duration, helping a company assess its agility. Citrix Online illustrates how process methodology, development group size and release duration relate. Its adoption of Scrum and Enterprise Scrum drove release duration down from a peak of 41 months to less than 4, shorter than it had as a small startup. Its market share rose during the same period. Data from another company, Patient Keeper, also seems to indicate that short release durations correlate with more profitable outcomes.
[Context and motivation] Eliciting compliance requirements often results in requirements, which might not be satisfied due to uncertainty and unavailability of resources. The lack of anticipation of these factors may increase the cost of achieving compliance. [Question/problem] Managing compliance is an investment activity that requires making decisions about selecting the right compliance goals under uncertainty, handling the obstacles to those goals and minimising risks. [Principal ideas/results] (1) We define the concept of technical debt for managing compliance and we explore its link with obstacles to compliance goals. (2) We propose goal-oriented method and obstacles handling with a portfolio-based thinking for systematically managing obstacles and refining compliance goals. [Contribution]We use an exemplar to illustrate and evaluate the approach. The results show that our approach can provides analysts and compliance managers with an objective tool to assess and rethink their investment decisions when elaborating compliance requirements.
Shortening release duration is essential in creating competitive products in iterative software development. However, short-term expedients (e.g., code compromises, delayed change requests, etc.) can have long term effects on the maintenance of the software. There are multifaceted factors that influenced the effective management of technical debt in organizations. In this position paper, we propose a formulation of technical debt in the context of (software) product releases, specifically when-to-release decisions. The potential competitive advantage through faster delivery needs to be balanced against the delivery of the overall business values and the potentially incurred technical debt. Pro-active analysis of the estimated impact of various release scenarios is expected to provide insights and essential inputs for actual decision-making process. This paper also evaluates a real-world case study.
Evaluating technical debt related to code structure at a fine-grained level of detail is feasible using static code metrics to identify troublesome areas of a software code base. However, estimating the interest payments at a similar level of detail is a manual process relying on developers to submit their estimates as they encounter instances of technical debt. We propose a framework that continuously estimates interest payments using code comprehension metrics produced by a tool that monitors developer activities in the Integrated Development Environment. We describe the framework and demonstrate how it is used to evaluate the presence of technical debt and interest payments accumulated for code in an industrial software product.
As the semiconductor market begins to recover and customers begin to order new products in higher volumes, product competitiveness, and time-to-market will be absolutely critical. This is a good time to take stock of your development readiness and to understanding how well legacy software assets will support the product roadmap.
Technical debt is a metaphor for delayed software maintenance tasks. Incurring technical debt may bring short-term benefits to a project, but such benefits are often achieved at the cost of extra work in future, analogous to paying interest on the debt. Currently technical debt is managed implicitly, if at all. However, on large systems, it is too easy to lose track of delayed tasks or to misunderstand their impact. Therefore, we have proposed a new approach to managing technical debt, which we believe to be helpful for software managers to make informed decisions. In this study we explored the costs of the new approach by tracking the technical debt management activities in an on-going software project. The results from the study provided insights into the impact of technical debt management on software projects. In particular, we found that there is a significant start-up cost when beginning to track and monitor technical debt, but the cost of ongoing management soon declines to very reasonable levels.
The metaphor of technical debt (TD) has been used to characterize and quantify issues arising from software evolution and maintenance actions taken to modify the functionality or behaviour of a system while compromising on certain "under the hood" quality attributes in order to save cost and effort. The majority of research in this area has concentrated on software program code and architecture. Fewer research considers TD in the context of database applications, particularly TD related to database schemas, which is the focus of this paper. Managing TD in database schemas provides considerable and unique challenges, in particular for applications of safety and security critical nature. We discuss these challenges, point out potential solutions and present an industrial case study in this area.
A major reason for the popularity of agile and lean software methods is their capability to function in resource scarce and requirement erratic environments. Both of these characteristics cause accumulation of technical debt, something that is the end result of either intentional or unintentional decisions. The ability of these methods to function with technical debt indicates that they contain components with inherent technical debt management capabilities. This study conducts a survey on industry practitioners to discover what is their level of technical debt knowledge, how does technical debt manifest in their projects and which of the applied components of agile software development -- both processes and practices -- are sensitive to technical debt. This paper contributes to the technical debt discussion by showing differences in assumed and indicated technical debt knowledge. Furthermore, components closest to implementation and its maintenance are perceived to have the most positive effects on technical debt management. Finally, the most encountered instances of technical debt are caused by architectural inadequacies, they are internal legacy, and increase in size as a result of continued implementation.
Technical debt has become a popular term in the software engineering community in recent years for labelling issues and development risks incurred either intentionally or unintentionally throughout the entire software development process. There are some approaches for calculating and/or managing the costs related with different kinds of technical debt. Current research lacks a clear classification of these existing approaches. We therefore, in a first step, developed a classification scheme including respective categories and dimensions for this purpose and derived in a second step the need for a new approach that is able to (1) consider several levels of required target quality a project shall reach, and (2) base on a calculation mechanism that allows to regard experiences with known reference projects. In an experiment with two open source projects we find that the results of our model are in-line with an external quality judgment of these projects. It also shows how the resulting remediation costs depend on the actual quality level of the projects and the target quality level. We conclude this paper with future work regarding improvements of our calculation model and planned enhancements to cover design and documentation aspects.
Modern, fast-phased, iterative and incremental software development constantly struggles with limited resources and a plethora of frequently changing requirements. This environment often requires the development projects to intentionally - for example through implementing quick-and-dirty - or unintentionally - for example through misinterpretation of requirements - deviate from the optimal product state. While most of the deviation is caught through practices like customer reviews, the remainder stays hidden in the product. The undocumented remainder is difficult to remove, it expands uncontrollably and it negatively affects development as deviations are unexpectedly encountered and overcome. The term technical debt describes this process of accumulating hidden work. Management of technical debt can be expected to be a major factor in software development efficiency and sustainability and as such it should be an integral part of the software implementation's knowledge management. In addition to being difficult to capture, the continuous evolution of the implementation makes maintenance of gained information a challenge. This paper discusses applying technical debt management for software implementations including the entry points for knowledge discovery, network analysis for overcoming the maintenance challenges as well as the pursued outcomes.
Shortcuts that save money and time today can cost you down the road.
Technical debt is the trading of long-term software quality in favor of short-term expediency. While the concept has traditionally been applied to tradeoffs at the code and architecture phases, it also manifests itself in the system requirements analysis phase. Little attention has been paid to requirements over time in software: requirements are often badly out of synch with the implementation, or not used at all. However, requirements are the ultimate validation of project success, since they are the manifestation of the stakeholder's desires for the system. In this position paper, we define technical debt in requirements as the distance between the implementation and the actual state of the world. We highlight how a requirements modeling tool, RE-KOMBINE, makes requirements, domain constraints and implementation first-class concerns. RE-KOMBINE represents technical debt using the notion of optimal solutions to a requirements problem. We show how this interpretation of technical debt may be useful in deciding how much requirements analysis is sufficient.
Often we find it difficult to adapt to any changes during later phases of a software development project. Primary reason for this is rigidity in design and code which do not allow major changes to be incorporated. This inflexibility substantially increases the cost of post-delivery enhancement and maintenance and is termed as Technical Debt. As Technical Debt cannot be eliminated completely, we need to reduce its burden. Many practitioners, especially from agile community, have suggested some practices to avoid or overcome the Technical Debt. This paper explores the methods for relief from Technical Debt and proposes thirteen steps that a developer should follow to minimize technical debt. These steps have proved to be effective when implemented in projects as discussed in this paper.
Rising industry trends in acceptance for Agile approaches in software development provides opportunities as well as challenges in the ever-changing environment of software development. On the one hand, fast feedback of working code combined with close customer collaboration enables increased software development productivity by providing greater accuracy of where to target the development effort. On the other hand, the growing interdependence of the product software components within complex systems gradually evolves considerable challenge in terms of assessing system performance and planning for future system expansion. In addition, and equally important, establishing and maintaining performance modeling becomes more and more costly due to the increasing volatility of requirements. We should also consider the growing complexity of systems being built, integration with third party subsystems, and at the same time the fact that engineering teams face tight project budgets as businesses are looking to reduce capital expenditures. To address these concerns, an adaptive performance modeling approach supported by automated performance analysis is proposed. This approach combines predictive engineering techniques, experimental feedback obtained through testing, and continuous data acquisition including knowledge-based assessments provided by the engineers.
This paper describes our experiences in using the Scrum concept of Definition of Done to drive quality improvements and reduce technical debt. We also describe how the Definition of Done can be a vehicle to implement standards, use checklists, and introduce compliance measures in the Agile development process.