Article
To read the full-text of this research, you can request a copy directly from the authors.

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.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the authors.

... Instead, we decided to narrow down the number of features by focusing only on those that act as the most prominent TD indicators. TD indicators are indicators usually related to software metrics [1,40] that allow researchers and practitioners to point out TD-related quality issues residing in various attributes, features, or characteristics of a software artefact. Recent literature has identified a variety of software metrics that can act as potential TD indicators, while there is also a multitude of assessment tools [63] that support TD estimation based on these metrics. ...
... In addition, code issues that can negatively affect the quality of a software, such as code violations or bugs, have also been studied for their impact on TD [31,65,69]. Finally, code smells, i.e., sub-optimal design solutions that violate at least one programming principle [21] are considered in the literature as one of the first indications of the presence of TD [1,46]. Code smells represent serious threats to the software maintenance process and impose the need for code refactoring [19] In Table 2, we present the SonarQube metrics that were finally selected based on their ability to act as TD indicators. ...
... Within the context of cross-project TD forecasting, training was performed on the entire dataset of the project that was chosen each time, while testing was performed also on the entire dataset of each project acting as testing dataset. This means that forecasts were generated at every sample of the table can be found in Table 27 Commonsbeanutils (2) Commons-vfs (3) Batik (5) 49%** 1%*** 2%*** 1%*** Felix (0) 42%** 3%*** 5%*** 3%*** Zookeeper (0) 0.6%*** 13%*** 1%*** Httpcomponents-client (0) 28%** 12%*** 2%*** Commons-configuration (0) 57%* 3%*** 5%*** 1%*** Santuario (1) 70%* 6%*** 6%*** 3%*** Commons-beanutils (2) 33%** 1%*** 1%*** Commons-validator (3) 84% 3%*** 9%*** 3%*** Commons-vfs (3) 39%** 2%*** 6%*** Commons-io (2) 75%* 4%*** 7%*** 2%*** Mina-sshd (0) 32%** 1%*** 14%*** 2%*** Aurora (1) 65%* 3%*** 7%*** 1%*** Beam (1) 8%*** 4%*** 16%*** 5%*** Commons-collections (0) 16%*** 2%*** 2%*** 1%*** Httpcomponents-core (0) 42%** 2%*** 11%*** 2%*** Commons-bcel (2) 37%** 1%*** 4%*** 1%*** Commons-cli (4) 157% 18%*** 23%** 16%*** Commons-daemon (4) 336% 12%*** 45%** 9%*** Commons-dbcp (3) 31%** 7%*** 3%*** 2%*** Commons-digester (3) 201% 48%** 34%** 8%*** Commons-exec (4) 309% 9%*** 34%** 7%*** Commons-fileupload (4) 278% 11%*** 39%** 10%*** Commons-jexl (3) 107% 10%*** 12%*** 7%*** Commons-jxpath (3) 9%*** 3%*** 5%*** 1%*** Commons-net (3) 16%*** 2%*** 12%*** 2%*** Commons-ognl (3) 13%*** 2%*** 7%*** 1%*** Atlas (5) 128% 59%* 64%* 57%* (commit) of the testing dataset, throughout its whole evolution. In addition, since we aim at generating predictions for five and ten steps (commits) ahead by following the direct approach described in "Sliding Window Method", predictions are generated first for one step ahead, then for two steps ahead, and so on. ...
Article
Full-text available
Technical debt (TD) describes quality compromises that can yield short-term benefits but may negatively affect the quality of software products in the long run. A wide range of tools and techniques have been introduced over the years in order for the developers to be able to determine and manage TD. However, being able to also predict its future evolution is of equal importance to avoid its accumulation, and, in turn, the unlikely event of making the project unmaintainable. Although recent research endeavors have showcased the feasibility of building accurate project-specific TD forecasting models, there is a gap in the field regarding cross-project TD forecasting. Cross-project TD forecasting is of practical importance, since it would enable the application of pre-existing forecasting models on previously unknown software projects, especially new projects that do not exhibit sufficient commit history to enable the construction of project-specific models. To this end, in the present paper, we focus on cross-project TD forecasting, and we examine whether the consideration of similarities between software projects could be the key for more accurate forecasting. More specifically, we propose an approach based on data clustering. In fact, a relatively large repository of software projects is divided into clusters of similar projects with respect to their TD aspects, and specific TD forecasting models are built for each cluster, using regression algorithms. According to our approach, previously unknown software projects are assigned to one of the defined clusters and the cluster-specific TD forecasting model is applied to predict future TD values. The approach was evaluated through several experiments based on real-world applications. The results of the analysis suggest that the proposed approach comprises a promising solution for accurate cross-project TD forecasting.
... This phenomenon led to the concept of technical debt, i.e., implementation trade-offs made by developers during rushed development tasks. Since Cunningham first described technical debt almost 30 years ago [11], many researchers have studied its impact on software development [3,4,23,38]. In general, researchers agree that it leads to low quality (in particular maintainability), and makes further changes more expensive in the long run [24,51]. ...
... While these studies recognize the importance of technical debt in data-intensive systems, the problem has not received much attention. Although several researchers have investigated the detection, persistence and impact of technical debt in traditional software systems (e.g., [23,4,38,3,26,24,51]), data-intensive systems remained out of focus. In particular, we still do not know much about the prevalence and persistence of technical debt in data-intensive systems. ...
... Alves et al. performed a systematic mapping study by evaluating 100 studies dating from 2010 to 2014 [4]. They also proposed a taxonomy of technical debt types and created a list of indicators to identify technical debt. ...
Preprint
Developers sometimes choose design and implementation shortcuts due to the pressure from tight release schedules. However, shortcuts introduce technical debt that increases as the software evolves. The debt needs to be repaid as fast as possible to minimize its impact on software development and software quality. Sometimes, technical debt is admitted by developers in comments and commit messages. Such debt is known as self-admitted technical debt (SATD). In data-intensive systems, where data manipulation is a critical functionality, the presence of SATD in the data access logic could seriously harm performance and maintainability. Understanding the composition and distribution of the SATDs across software systems and their evolution could provide insights into managing technical debt efficiently. We present a large-scale empirical study on the prevalence, composition, and evolution of SATD in data-intensive systems. We analyzed 83 open-source systems relying on relational databases as well as 19 systems relying on NoSQL databases. We detected SATD in source code comments obtained from different snapshots of the subject systems. To understand the evolution dynamics of SATDs, we conducted a survival analysis. Next, we performed a manual analysis of 361 sample data-access SATDs, investigating the composition of data-access SATDs and the reasons behind their introduction and removal. We identified 15 new SATD categories, out of which 11 are specific to database access operations. We found that most of the data-access SATDs are introduced in the later stages of change history rather than at the beginning. We also observed that bug fixing and refactoring are the main reasons behind the introduction of data-access SATDs.
... This concept was first used by Cunningham (1992), who related the characterization of Technical Debts to problems in the code and the need for refactoring to pay the debts acquired. Other studies have addressed Technical Debts in other activities of the software development process (e.g., tests, requirements, usability) and provided solutions to manage them in software projects Alves et al. (2016) Li et al. (2015). ...
... Although there are a significant number of works that deal with this type of debt Alves et al. (2016) Li et al. (2015), most of them deal only with code-related debts by using, for example, tools for analysis of test code coverage and unit tests. Therefore, a more in-depth investigation of debts that cannot be managed by code analysis alone is necessary. ...
... Thus, our work intends to fill the following gaps identified in the systematic mappings of Alves et al. (2016) and Li et al. (2015) and the literature review that is also done in this work: (i) lack of studies dealing with other types of Technical Debts (e.g., Test Debts); (ii) need for identifying non-code-related Technical Debts; (iii) few studies with more global approaches that cover more causes of Test Debts; and (iv) need for validated solutions in industry projects. ...
Article
Full-text available
When deadlines and resources of software projects become scarce, testing is usually in the first row to have its activities aborted or reduced; however, if defects cannot be found, product quality can be affected. In the software development process, aborted or reduced activities that can bring short-term benefits, but can be harmful to the project in the long run, are considered Technical Debt (TD) and, when the TDs impact testing activities, they are called Test Debt. Although there are several studies dealing with Test Debt, current solutions often deal with specific types of tests (e.g., exploratory and automated tests) and do not address the whole software testing process. Aiming to fill these gaps, this work then proposes a Test Debt Catalog, called TestDCat, with subtypes of Test Debts and Technical Debt management activities. This catalog is built based on the results of an empirical study, a literature review and semi-structured interviews conducted with practitioners who perform testing activities on five projects from industry. For the TestDCat evaluation, a case study is conducted in real projects in order to identify if the catalog is user-friendly and if its use helps the Test Debt management during the execution of test activities in these software development projects.
... This phenomenon led to the concept of technical debt, i.e., implementation trade-offs made by developers during rushed development tasks. Since Cunningham first described technical debt almost 30 years ago (Cunningham 1992), many researchers have studied its impact on software development (Alfayez et al. 2020;Alves et al. 2016;Li et al. 2015;Rios et al. 2018). In general, researchers agree that it leads to low quality (in particular maintainability), and makes further changes more expensive in the long run (Lim et al. 2012;Wehaibi et al. 2016). ...
... While these studies recognize the importance of technical debt in data-intensive systems, the problem has not received much attention. Although several researchers have investigated the detection, persistence and impact of technical debt in traditional software systems (e.g., Li et al. 2015;Alves et al. 2016;Rios et al. 2018;Alfayez et al. 2020;Liu et al. 2018;Lim et al. 2012;Wehaibi et al. 2016), data-intensive systems remained out of focus. In particular, we still do not know much about the prevalence and persistence of technical debt in dataintensive systems. ...
... Alves et al. performed a systematic mapping study by evaluating 100 studies dating from 2010 to 2014 (Alves et al. 2016). They also proposed a taxonomy of technical debt types and created a list of indicators to identify technical debt. ...
Article
Full-text available
Developers sometimes choose design and implementation shortcuts due to the pressure from tight release schedules. However, shortcuts introduce technical debt that increases as the software evolves. The debt needs to be repaid as fast as possible to minimize its impact on software development and software quality. Sometimes, technical debt is admitted by developers in comments and commit messages. Such debt is known as self-admitted technical debt (SATD). In data-intensive systems, where data manipulation is a critical functionality, the presence of SATD in the data access logic could seriously harm performance and maintainability. Understanding the composition and distribution of the SATDs across software systems and their evolution could provide insights into managing technical debt efficiently. We present a large-scale empirical study on the prevalence, composition, and evolution of SATD in data-intensive systems. We analyzed 83 open-source systems relying on relational databases as well as 19 systems relying on NoSQL databases. We detected SATD in source code comments obtained from different snapshots of the subject systems. To understand the evolution dynamics of SATDs, we conducted a survival analysis. Next, we performed a manual analysis of 361 sample data-access SATDs, investigating the composition of data-access SATDs and the reasons behind their introduction and removal. We identified 15 new SATD categories, out of which 11 are specific to database access operations. We found that most of the data-access SATDs are introduced in the later stages of change history rather than at the beginning. We also observed that bug fixing and refactoring are the main reasons behind the introduction of data-access SATDs.
... Identification and measurement are the first two steps in the management process (Li et al., 2014). They are essential activities to know what type of TD exists, where it is located, and how to estimate its impact on the software (Alves et al., 2016). However, they are considered the phases in which there is greater difficulty in achieving (Besker et al., 2018). ...
... The work of Alves et al. (2016) was aimed at conducting an Systematic Mapping Study (SMS) to analyze which strategies proposed to help manage TD in software projects and analyze their main types. The search process executed automatically, recovering searches in the period 2010 to 2014, and at the end, 100 studies were considered. ...
... Although, they did not address specific contents on the causes for their emergence and metrics for measurement. The works of Alves et al. (2016) and BenIdris (2020) focused on TD in general, gathering evidence to help in its management. Finally, the paper of Lenarduzzi et al. (2021) analyzed a specific step (prioritization) of the TD management process but differed by not addressing evidence focused on its identification and measurement. ...
Preprint
Full-text available
Context: Technical Debt requirements are related to the distance between the ideal value of the specification and the system's actual implementation, which are consequences of strategic decisions for immediate gains, or unintended changes in context. To ensure the evolution of the software, it is necessary to keep it managed. Identification and measurement are the first two stages of the management process; however, they are little explored in academic research in requirements engineering. Objective: We aimed at investigating which evidence helps to strengthen the process of TD requirements management, including identification and measurement. Method: We conducted a Systematic Literature Review through manual and automatic searches considering 7499 studies from 2010 to 2020, and including 61 primary studies. Results: We identified some causes related to Technical Debt requirements, existing strategies to help in the identification and measurement, and metrics to support the measurement stage. Conclusion: Studies on TD requirements are still preliminary, especially on management tools. Yet, not enough attention is given to interpersonal issues, which are difficulties encountered when performing such activities, and therefore also require research. Finally, the provision of metrics to help measure TD is part of this work's contribution, providing insights into the application in the requirements context.
... Results show that refactoring and improve design (19 citations altogether) are the most cited TD payment practices used by software teams, as reported by software architects. These practices were expected to be at the top of the list [1,10,14,15], considering that both practices are intertwined. Lists of payment practices among design, code, and test debt tend to be more similar as more practices are included. ...
... In the systematic mapping study by Li et al. in [10], they classified TD in 10 different types as follow: design, architecture, code, documentation, test, defect, requirement, infrastructure, build, and versioning debt. In [15], Alves et al. identified four more TD types: people, process, service, and usability debt. Kruchten et al. in [3] stated that architecture, documentation and testing can add significantly to the debt and thus are part of the TD landscape. ...
... This classification is required in order to answer our RQ1.1 (Is it possible to find similarities of the TD payment practices according to the TD type associated with them?). Each of the example cases given by the respondents followed a mapping process between the overall description and TD indicators from Alves et al. [15]. For example, ''Update pending documentation'' was an answer for Q13, and it has a direct mapping with the TD indicator outdated documentation. ...
Article
Context Architectural decisions are considered one of the most common sources of technical debt (TD). Thus, it is necessary to understand how TD is perceived by software architects, particularly, the practices supporting the elimination of debt items from projects, and the practices used to reduce the chances of TD occurrence. Objective This paper investigates the most commonly used practices to pay off TD and to prevent debt occurrence in software projects from the architect’s point of view. Method We used the available data from InsighTD, which is a globally distributed family of industrial surveys on the causes, effects, and management of TD. We analyze responses from a corpus of 72 software architects from Brazil, Chile, Colombia, and the United States. Results Results showed that refactoring (30.2%) was the main practice related to TD payment, followed by design improvements (14.0%). Refactoring, design improvements, and test improvements are the most cited payment practices among cases of code, design and test debt. Concerning the TD preventive practices, we find that having a well-defined architecture and design is the most cited practice (13.6%), followed by having a well-defined scope and requirements. This last practice is the most cited one for expert software architects. Finally, when comparing preventive practices among the three major roles derived from the survey (software architects, engineer roles, and management roles), we found that none of the roles shared the most cited practice, meaning that each role had its worries and focus on different strategies to reduce TD’s presence in the software. Conclusion The lists of TD payment and prevention practices can guide software teams by having a catalog of practices to keep debt controlled or reduced.
... Technical Debt (TD) refers to the consequences of taking shortcuts and making poor design choices during the development or maintenance of a software system, negatively impacting its future evolution (Nielsen et al., 2020). Prior work has uncovered multiple types of TD which can be identified using multiple indicators, but sharing mostly similar management strategies (Alves et al., 2016). TD Management (TDM) is described as ''the actions of identification, assessment, and remediation of technical debt in a software system'' (Griffith et al., 2014). ...
... Therefore, TDM is crucial because it enables an organisation to have a more optimal use of its resources; when the right TDM techniques are applied, the development team can identify technical debt and repay it in a timely fashion (Alves et al., 2016). Moreover, the importance of managing TD embedded in software products has been highlighted by recent studies Ramasubbu and Kemerer, 2019). ...
... The system itself is related to the players because it reflects the ''play history'' (namely, the sequence of actions and plays done by the players). Though there are means to trace the actions (e.g., version control systems, bug issues, planning tools) (Rubasinghe et al., 2018), including those specific to TDM (Alves et al., 2016;Zazworka et al., 2013), it remains unfeasible to communicate every detail as detection tools are continuously being improved, and particularly, more established for some TD types than others (Ramasubbu and Kemerer, 2018). ...
Article
Code ridden with Technical Debt (TD) has motivated software engineers to keep the quality of systems under control to ease future maintenance tasks. In the last decade, there have been significant advances regarding TD management (TDM). However, research about incorporating TDM into the software development lifecycle remains scarce, and existing approaches aim to control TD through different processes. This proposal leverages the concept of infinite games from game theory to posit a different perspective. We argue that TD cannot be entirely removed and that its effects or consequences cannot be considered “managed” even when an occurrence (i.e., a smell) is repaid. Rather than using a mathematical approach, we present TDM in terms of the four components of infinite games (players, rules, goals, and time), its tradeoffs and relationships, to discuss its potential impact on TDM activities. As this is an incipient area, our goal is to motivate a change of mindset regarding TDM, stimulating reflective thinking and thus, posing a new line of research. We conclude with a series of potential research questions organised into three key areas.
... The authors also emphasized that the application of strategies lacks consistency (e.g., the same procedure is differently applied in many studies), and in some cases, lacks a clear mapping between financial and software engineering concepts. Finally, Mendonça et al. [2] reported a systematic study investigating the TD types and TDM strategies. The authors identify various indicators of TD, which support the identification of specific types of TD. ...
... The first iteration started with a preliminary protocol elaboration for the sake of consistency and best practices. Moreover, we adapted protocols of published secondary studies in the TD and Intelligent Techniques research areas to be more aligned with the literature [2,6,22,26]. We refined the protocol items for each iteration based on the initial results. ...
... To address 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,6,22]. For Pr8 and Pr9, we used the classification presented by Perkusich et al. [26]. ...
Conference Paper
Full-text available
Technical Debt (TD) refers to the consequences of taking shortcuts when developing software. Technical Debt Management (TDM) becomes complex since it relies on a decision process based on multiple and heterogeneous data, which are not straightforward to be synthesized. In this context, there is a promising opportunity to use Intelligent Techniques to support TDM activities since these techniques explore data for knowledge discovery, reasoning, learning , or supporting decision-making. Although these techniques can be used for improving TDM activities, there is no empirical study exploring this research area. This study aims to identify and analyze solutions based on Intelligent Techniques employed to support TDM activities. 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, Reasoning Under Uncertainty, and Natural Language Processing the most recurrent ones. Identification, measurement, and monitoring were the more recurrent TDM activities , whereas Design, Code, and Architectural were the most frequently investigated TD types. Although the research area is up-and-coming, it is still in its infancy, and this study provides a baseline for future research. CCS CONCEPTS • General and reference → Empirical studies.
... The principal cost of a TDI represents the investment required, in monetary or temporal terms, to eliminate the item. The interest amount instead represents the penalty incurred if a TDI is not solved in the present [4]. This second definition of TD cost entails the growing cost associated to an unmodified TDI during the evolution of a software-intensive system. ...
... As will be further discussed in the following section, from an inspection of the related literature, not all activities of the TD research result to be studied with the same intensity. In particular, several gaps of research can be identified by considering the secondary studies concentrating on TD [10,11,9,4,5,12]. From such studies several TD related activities result to be lacking the required depth and in some cases remain 5 ...
... Each of this TD types has its own level of abstraction and artifact(s) as input. Several coarse-grained types of TD can be identified in the literature, as reported in the second studies available on TD [11,9,4]. Some among the most prominent TD types that can be found in the literature are reported in Table 1.1. ...
Thesis
Full-text available
Architectural technical debt (ATD) in a software-intensive system is the sum of all design choices that may have been suitable or even optimal at the time they were made, but which today are significantly impending progress: structure, framework, technology, languages, etc. Unlike code-level technical debt which can be readily detected by static analysers, and can often be refactored with minimal or only incremental efforts, architectural debt is hard to detect, and its remediation rather wide-ranging, daunting, and often avoided. The objective of this thesis is to develop a better understanding of architectural technical debt, and determine what strategies can be used to identify and manage it. In order to do so, we adopt a wide range of research techniques, including literature reviews, case studies, interviews with practitioners, and grounded theory. The result of our investigation, deeply grounded in empirical data, advances the field not only by providing novel insights into ATD related phenomena, but also by presenting approaches to pro-actively identify ATD instances, leading to its eventual management and resolution.
... The concept of technical debt (TD) describes a phenomenon that impacts software projects and makes them difficult to manage [4]. For example, lack of coding standards can result with bad code, i.e. code debt and code smells [5,4,6]. It seems that TD issues are prevalent in organizations and teams of all sizes. ...
... In past years, a significant effort was made by researchers to better understand and identify technical debt from the analysis of source code, i.e. code debt and code smells [5,4,6]. However, this is just one perspective. ...
... At the time of writing this article, 34 researchers organized in national teams from 12 countries joined the initiative 5 . The main responsibility of the replication teams is to execute the InsighTD tasks in their own 5 Project statistics on 28.Nov.2020 countries but also to facilitate the work of the core team, or to contribute members to the core team. ...
Article
Full-text available
Context The technical debt (TD) metaphor describes actions made during various stages of software development that lead to a more costly future regarding system maintenance and evolution. According to recent studies, on average 25% of development effort is spent, i.e. wasted, on TD caused issues in software development organizations. However, further research is needed to investigate the relations between various software development activities and TD. Objective The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in the IT industry. Second, to contribute towards precise conceptualization of the TD concept through analysis of causes and effects. Method In order to address the research objective a family of surveys was designed as a part of an international initiative that congregates researchers from 12 countries—InsighTD. At country level, national teams ran survey replications with industry practitioners from the respective countries. Results In total 653 valid responses were collected from 6 countries. Regarding the prevalence of the TD concept 22% of practitioners have only theoretical knowledge about it, and 47% have some practical experiences with TD identification or management. Further analysis indicated that senior practitioners who work in larger organizations, larger teams, and on larger systems are more likely to be experienced with TD management. Time pressure or deadlinewas the single most cited cause of TD. Regarding the effects of TD: delivery delay, low maintainability, and rework were the most cited. Conclusion InsighTD is the first family of surveys on technical debt in software engineering. It provided a methodological framework that allowed multiple replication teams to conduct research activities and to contribute to a single dataset. Future work will focus on more specific aspects of TD management.
... The concept of technical debt (TD) describes a phenomenon that impacts software projects and makes them difficult to manage [4]. For example, lack of coding standards can result with bad code, i.e. code debt and code smells [5,4,6]. It seems that TD issues are prevalent in organizations and teams of all sizes. ...
... In past years, a significant effort was made by researchers to better understand and identify technical debt from the analysis of source code, i.e. code debt and code smells [5,4,6]. However, this is just one perspective. ...
... At the time of writing this article, 34 researchers organized in national teams from 12 countries joined the initiative 5 . The main responsibility of the replication teams is to execute the InsighTD tasks in their own 5 Project statistics on 28.Nov.2020 countries but also to facilitate the work of the core team, or to contribute members to the core team. ...
Preprint
Full-text available
The technical debt (TD) metaphor describes actions made during various stages of software development that lead to a more costly future regarding system maintenance and evolution. According to recent studies, on average 25% of development effort is spent, i.e. wasted, on TD caused issues in software development organizations. However, further research is needed to investigate the relations between various software development activities and TD. The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in the IT industry. Second, to contribute towards precise conceptualization of the TD concept through analysis of causes and effects. In order to address the research objective a family of surveys was designed as a part of an international initiative that congregates researchers from 12 countries -- InsighTD. At country level, national teams ran survey replications with industry practitioners from the respective countries. In total 653 valid responses were collected from 6 countries. Regarding the prevalence of the TD concept 22% of practitioners have only theoretical knowledge about it, and 47% have some practical experiences with TD identification or management. Further analysis indicated that senior practitioners who work in larger organizations, larger teams, and on larger systems are more likely to be experienced with TD management. Time pressure or deadline was the single most cited cause of TD. Regarding the effects of TD: delivery delay, low maintainability, and rework were the most cited. InsighTD is the first family of surveys on technical debt in software engineering. It provided a methodological framework that allowed multiple replication teams to conduct research activities and to contribute to a single dataset. Future work will focus on more specific aspects of TD management.
... Technical debt (TD) conceptualizes technical compromises that can bring short-term benefits (e.g., higher productivity and lower costs) but may negatively impact the long-term health of software projects [1]. Although initially TD was associated only with code level issues, it can also impact other artifacts of the software development process, such as documentation and requirement engineering [2]. If not managed, accumulated debt yields risks associated with, among others, unexpected delays in system evolution and difficulty in achieving quality criteria defined for the project [3]. ...
... Despite the growing number of studies on TD, there is a clear concentration of studies investigating TD from the source code and its related artifacts perspective, suggesting tools to support its management [2,9] and identification [2,13]. But, if debt items are present in requirements specifications or test cases, then how can they be identified? ...
... Despite the growing number of studies on TD, there is a clear concentration of studies investigating TD from the source code and its related artifacts perspective, suggesting tools to support its management [2,9] and identification [2,13]. But, if debt items are present in requirements specifications or test cases, then how can they be identified? ...
Conference Paper
Full-text available
Context: It is common for a software project to incur technical debt (TD) during its development. It can impact several artifacts produced throughout the software development process. Therefore, it is necessary to carry out management actions to find a balance between the benefits of incurring it and the effects of its presence. However, so far, much of the attention has been given only to discussions relating TD to coding issues. This is a worrying scenario because other types of debt can also have impactful, or even worse, consequences on projects. Aims: This study elaborates on the need to consider other issues of the development process and not just the source-code when investigating the TD phenomenon. Method: We analyze responses from 653 practitioners concerning TD causes, effects, prevention, reasons for non-prevention, repayment, and reasons for non-repayment and investigate whether these TD management elements are related to coding or to other software development issues. Results: Coding issues are commonly related to the investigated elements but, indeed, they are only part of the big picture we draw. Issues related to the project planning and management, human factors, knowledge, quality, process, requirements, verification, validation, and test, design, architecture, TD management, and the organization are also common. Lastly, we present a hump diagram that, 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. Conclusion: The results shed light on other concerns beyond code that the research community and practitioners need to be aware of.
... Some prevalent code smells as mentioned in three papers [14,26,3] that software developers encounter and researchers discuss are the following: ...
... • Duplicated Code [14,38] • Large Class [14] • Long Method [14,38] • God Class [26,3,59,38,25] • Data Class [26] • Brain Method [26,25] • Shotgun Surgery [26] • Dispersed Coupling [26] • Message Chains [26] This is a non-exhaustive list of some of the types of code smells that contribute to technical debt, hindering the maintainability of software. The authors in each of the papers [14,26,3,59] provide a detailed analysis as well as definitions of each type of smell, including statistics on how frequently they appear. ...
... • Duplicated Code [14,38] • Large Class [14] • Long Method [14,38] • God Class [26,3,59,38,25] • Data Class [26] • Brain Method [26,25] • Shotgun Surgery [26] • Dispersed Coupling [26] • Message Chains [26] This is a non-exhaustive list of some of the types of code smells that contribute to technical debt, hindering the maintainability of software. The authors in each of the papers [14,26,3,59] provide a detailed analysis as well as definitions of each type of smell, including statistics on how frequently they appear. ...
Article
Full-text available
Poor design choices, bad coding practices, or the need to produce software quickly can stand behind technical debt. Unfortunately, manually identifying and managing technical debt gets more difficult as the software matures. Recent research offers various techniques to automate the process of detecting and managing technical debt to address these challenges. This manuscript presents a mapping study of the many aspects of technical debt that have been discovered in this field of study. This includes looking at the various forms of technical debt, as well as detection methods, the financial implications, and mitigation strategies. The findings and outcomes of this study are applicable to a wide range of software development life-cycle decisions.
... DD arises when a shortcut in the principles of good design is taken. CD refers to the code that is poorly written, such as code duplication [10,12]. ...
... Smells can be used as indicators of TD, they are bene¯cial in detecting code complexity and fault-proneness and decrease maintainability [19]. In this study, we have used the smells as an indicator of TD because smells are the most commonly used TD indicators [9,12]. Metrics and threshold rules can be utilized to detect bad smells. ...
Article
Full-text available
Do developers postpone fixing Technical Debt (TD) in software systems? TD is a metaphor that refers to short-term decisions in software development that may affect the cost of the software development life cycle. The bad smell is an imperfect solution in the software system that negatively impacts the internal software quality and maintainability. In this paper, we will study five open-source software projects (OSSPs) that have several releases and also estimate the numbers of architecture smells (ASs), design smells (DSs), and code smells (CSs) for every release. Designite will be used to detect smells. We describe a case study conducted to explore the following: (1) What is the average smells density for architecture, design, and code smells in an OSSP? (2) Does the density of each smell type increase over multiple releases? (3) What percentage of each smell-type density is eliminated by refactoring? We collected around 2 million LOC from five OSSPs that have multiple releases from the GitHub repository to statistically analyze the software concerning the smells as indicators of TD. We find 36% of Architecture Technical Debt (ATD) is Cyclic Dependency, while 33% of Design Debt (DD) is Cyclically-dependent Modularization. More than 70% of Code Debt (CD) is Magic Number. Even though the developers do refactoring between releases, the TD density in general increases. On average, by refactoring, developers remove around 48%, 16%, and 22% from the introduced ATD, DD, and CD from their next release, respectively.
... Várias estratégias e ferramentas para identificação de DT têm sido propostas na literatura [20]. Uma das principais estratégias consiste na utilização de indicadores com o objetivo de apoiar os profissionais na identificação de itens de DT [2]. Uma classificação de indicadores de baixo e alto nível extraídos a partir de discussões sobre DT no Stack Overflow (SO) e representada através de um diagrama conceitual é apresentada em [12]. ...
... Os indicadores permitem identificar itens de DT através da análise dos diferentes artefatos gerados durante o desenvolvimento de um projeto de software. Em [2] é apresentada uma lista de indicadores e seu relacionamento com cada tipo de dívida. Esse relacionamento é importante pois permite tomar decisões fundamentadas com base nos indicadores que podem ser usados no gerenciamento de um tipo de dívida específico. ...
... Moreover, Tom et al. 3 explored the TD metaphor and outlined the first framework to provide a consolidated understanding of the TD phenomenon and to discuss its positive and negative consequences. Although TD increases productivity and speed in the short term, its long-term impact on software artifacts at different stages of the life cycle, such as additional cost during maintenance, has been observed as more crucial 4,5,6 . Debt is quite inevitable in software development 7 and it is even deliberately incurred under some conditions 4,8 . ...
... Debt is quite inevitable in software development 7 and it is even deliberately incurred under some conditions 4,8 . It is usually incurred when the effort to build the software in the shortest possible time using the least amount of resources is preferred over the effort to maintain the quality attributes of the system 6 . In companies whose main goal is to deliver business value, there is a need to choose between activities such as adding new features and fixing defects, and repaying accumulated TD 7,9 . ...
Article
Full-text available
Refactoring, which aims to improve the internal structure of the software systems preserving their behavior, is the most common payment strategy for technical debt (TD) by removing the code smells. There exist many studies presenting code smell detection approaches/tools or investigating their impact on quality attributes. There are also studies that focus on refactoring techniques, their relation with quality attributes, tool supports, and opportunities for them. Although there are several studies addressing the gap between refactoring and TD indicators, the empirical evidence provided is still limited. In this study, we examine the distribution of 29 refactoring types among the different projects and their relation with code smells or faults. We explore the refactoring types that are most commonly performed together and other activities performed with refactorings. We conduct a large exploratory study with automatically detected 57,528 refactorings, 37,553 smells, 27,340 faults, and 134,812 commits of 33 Java projects. Results show that some refactoring types are more commonly applied by developers. Our analysis indicates that refactorings usually remove or do not affect the code smells, and this contradicts with the previous studies. Also, the commits in which refactoring(s) is performed are three times more fault inducing than those without refactoring. Refactoring, which aims to improve the internal structure of the software systems preserving their behavior, is the most common payment strategy for TD by removing code smells. In this study, we examine the distribution of 29 refactoring types among the different projects and their relation with codes smells or faults. Results show that some refactoring types are more commonly applied by developers, and refactorings usually remove or do not affect the code smells, and this contradicts the previous studies.
... Most of the existing studies used a single artifact (i.e. source code comments) to explore TD with a few recent exceptions [7], [13], [89]. ...
... Existing literature defines TD as an implementation construct that is profitable in short term but problematic for future work and changes [6], [10], [40], [72], [73]. Alves et al. devised a TD taxonomy with some new types i.e. people, process, service, usability debts [7]. Some other common types of TD discussed in various studies are social [70], data [22], database [4], infrastructure [26] debts. ...
Preprint
Full-text available
Technical debt (TD) is a metaphor for code-related problems that arise as a result of prioritizing speedy delivery over perfect code. Given that the reduction of TDs can have long-term positive impact in the software engineering life-cycle (SDLC), TDs are studied extensively in the literature. However, very few of the existing research focused on the technical debts of R programming language despite its popularity and usage. Recent research by Codabux et al. [21] finds that R packages can have 10 diverse TD types analyzing peer-review documentation. However, the findings are based on the manual analysis of a small sample of R package review comments. In this paper, we develop a suite of Machine Learning (ML) classifiers to detect the 10 TDs automatically. The best performing classifier is based on the deep ML model BERT, which achieves F1-scores of 0.71 - 0.91. We then apply the trained BERT models on all available peer-review issue comments from two platforms, rOpenSci and BioConductor (13.5K review comments coming from a total of 1297 R packages). We conduct an empirical study on the prevalence and evolution of 10 TDs in the two R platforms. We discovered documentation debt is the most prevalent among all types of TD, and it is also expanding rapidly. We also find that R packages of generic platform (i.e. rOpenSci) are more prone to TD compared to domain-specific platform (i.e. BioConductor). Our empirical study findings can guide future improvements opportunities in R package documentation. Our ML models can be used to automatically monitor the prevalence and evolution of TDs in R package documentation.
... 42 The research on TD is in its initial phase, with researchers focusing on a few types of debt. 8,43 Empirical evaluation of TD management activities, especially the evidence from the software industry, is essential to shedding light on technical debt prioritization activities. 42 The results and the analysis methods provided by our study can help the research and industrial communities to better understand what the lifespan of different types of code TDIs is, not only code smells, and invite researchers to further investigate TD prioritization and the activities related to it. ...
Article
Full-text available
Context: Technical debt (TD) discusses the negative impact of sub-optimal decisions to cope with the need-for-speed in software development. Code technical debt items (TDI) are atomic elements of TD that can be observed in code artifacts. Empirical results on open-source systems demonstrated how code-smells, which are just one type of TDIs, are introduced and “survive” during release cycles. However, little is known about whether the results on the survivability of code-smells hold for other types of code TDIs (i.e., bugs and vulnerabilities) and in industrial settings. Goal: Understanding the survivability of code TDIs by conducting an empirical study analyzing two industrial cases and 31 open-source systems from Apache Foundation. Method: We analyzed 133,670 code TDIs (35,703 from the industrial systems) detected by SonarQube (in 193,196 commits) to assess their survivability using survivability models. Results: In general, code TDIs tend to remain and linger for long periods in open-source systems, whereas they are removed faster in industrial systems. Code TDIs that survive over a certain threshold tend to remain much longer, which confirms previous results. Our results also suggest that bugs tend to be removed faster, while code smells and vulnerabilities tend to survive longer.
... Most TD identification approaches in literature use static source code analysis (Alves et al. 2016). While this works well for identifying coding rule violations, it also has limitations. ...
Article
Full-text available
Technical debt is a metaphor indicating sub-optimal solutions implemented for short-term benefits by sacrificing the long-term maintainability and evolvability of software. A special type of technical debt is explicitly admitted by software engineers (e.g. using a TODO comment); this is called Self-Admitted Technical Debt or SATD. Most work on automatically identifying SATD focuses on source code comments. In addition to source code comments, issue tracking systems have shown to be another rich source of SATD, but there are no approaches specifically for automatically identifying SATD in issues. In this paper, we first create a training dataset by collecting and manually analyzing 4,200 issues (that break down to 23,180 sections of issues) from seven open-source projects (i.e., Camel, Chromium, Gerrit, Hadoop, HBase, Impala, and Thrift) using two popular issue tracking systems (i.e., Jira and Google Monorail). We then propose and optimize an approach for automatically identifying SATD in issue tracking systems using machine learning. Our findings indicate that: 1) our approach outperforms baseline approaches by a wide margin with regard to the F1-score; 2) transferring knowledge from suitable datasets can improve the predictive performance of our approach; 3) extracted SATD keywords are intuitive and potentially indicating types and indicators of SATD; 4) projects using different issue tracking systems have less common SATD keywords compared to projects using the same issue tracking system; 5) a small amount of training data is needed to achieve good accuracy.
... All respondents responded to known security tools such as risk tolerance, better physical security, least privilege, redundancy, monitoring, and education and training. Security professionals mentioned the use of the PAM-based detection (protocol analysis module) that is developed by IBM X-Force IRIS systems, the use of an air-gapping system, an AI (artificial intelligence) to include pattern, knowledge, algorithmic, or self-learning, a website security blockers to provide security protection [74], technical debt within software projects [75], and to adopt the cyber kill chain model for the identification and prevention of cyber intrusion activity to identify the steps cybercriminals must complete to exploit the system. Conversations with cybersecurity professionals reiterated the constant challenges of cyber threats that many organizations face [76]. ...
Article
Full-text available
Organizations face the probability of being hacked because of weak and inadequate cybersecurity implementations. Hackers are still able to breach a system when security tools such as firewalls, SIEM, anti-virus software, encryption, and IDPS are readily in place within an organization. Digital criminals are responsible for increased network breaches using elusive security tools to penetrate secure environments with sophistication. Cyberattacks are continually increasing due to the sophistication and innovation of cyber attackers. Many vulnerable areas must be reinforced against cybercriminals, Insider threats, inadequate employee training, and negligence. Monetary investment in cybersecurity and management support plays a significant role in assuring the implementation of information security throughout any organizational processes. The implication for practice can provide organizations with approaches on how to mitigate cyber exploits and safeguard the confidentiality, integrity, and availability of information by bridging the gap between incident detection and response.
... The concept of "technical debt" has been used by practitioners and academics alike for some time to denote sub-optimal technical solutions expressed in code. The notion originated in software engineering in the early 1990s and therein referred to coding practices that introduced short-cuts or poor designs with the intent to speed up implementation while simultaneously increasing the life-cycle cost of the software [11,15,[18][19]. Ignorant coding and taking short-cuts were deemed equivalent to taking up financial debt that had to be repaid with interest later. ...
... Identification and Management of Technical Debt: A Systematic Mapping Study [1] x P6 Managing Architectural Technical Debt: A Unified Model and Systematic Literature Review [9] x P7 A tertiary study on technical debt: Types, management strategies, research trends, and base information for practitioners [55] x P8 Technical Debt Prioritisation: State of the Art. A Systematic Literature Review [44] x P9 Investigate, identify and estimate the technical debt: a systematic mapping study [6] x more specific categories. ...
Preprint
Full-text available
Context: Developing software-intensive products or services involves utilising many artefacts that are either part of the offering or part of enabling their development. These artefacts, if valuable and used more than once by the development organisation, can be seen as assets such as test cases, code, requirements, and documentation. As such, assets are often reused, updated, and become a base or even necessity for product development and evolution over time, constituting an investment. Assets are not well understood beyond code-based ones in the area of technical debt. Thus most asset types are often overlooked, and their state, which is subject to degradation over time, has not been much studied. Method: To address the problem, we conducted industrial focus groups with five companies and a literature review. The results were analysed qualitatively and summarised in a taxonomy. Results: We created a structured, extendable taxonomy of assets. The taxonomy contains 57 assets. Conclusions: The taxonomy serves as foundations for defining and identifying assets as a concept. It provides the foundation for studies into asset degradation and subsequent asset management. The taxonomy also includes code-based assets and thus can be helpful in further research into investigating degradation and debt concepts.
... By comparing their findings to our theory emerges again the current lack of awareness of research findings in industrial contexts, as in our theory prioritization emerged as a mere ''gut feeling'' (see Section 3.8). The literature further investigates other emerging categories, such as TD management strategies (Alves et al., 2016), and the impact of TD on morale (Ghanbari et al., 2017), but does not systematically focus on the architectural level as we do. ...
Article
Full-text available
Architectural technical debt in software-intensive systems is a metaphor used to describe the “big” design decisions (e.g., choices regarding structure, frameworks, technologies, languages, etc.) that, while being suitable or even optimal when made, significantly hinder progress in the future. While other types of debt, such as code-level technical debt, can be readily detected by static analysers, and often be refactored with minimal or only incremental efforts, architectural debt is hard to be identified, of wide-ranging remediation cost, daunting, and often avoided. In this study, we aim at developing a better understanding of how software development organisations conceptualize architectural debt, and how they deal with it. In order to do so, in this investigation we apply a mixed empirical method, constituted by a grounded theory study followed by focus groups. With the grounded theory method we construct a theory on architectural technical debt by eliciting qualitative data from software architects and senior technical staff from a wide range of heterogeneous software development organizations. We applied the focus group method to evaluate the emerging theory and refine it according to the new data collected. The result of the study, i.e., a theory emerging from the gathered data, constitutes an encompassing conceptual model of architectural technical debt, identifying and relating concepts such as its symptoms, causes, consequences, management strategies, and communication problems. From the conducted focus groups, we assessed that the theory adheres to the four evaluation criteria of classic grounded theory, i.e., the theory fits its underlying data, is able to work, has relevance, and is modifiable as new data appears. By grounding the findings in empirical evidence, the theory provides researchers and practitioners with novel knowledge on the crucial factors of architectural technical debt experienced in industrial contexts.
... For example, by using source code analysis tools, it is possible to identify refactoring opportunities, detect security vulnerabilities, highlight performance bottlenecks, and identify bad programming practices, such as code smells. Another potential explanation for emphasis of the tools in the source code is that the body of knowledge in technical debt is still consolidating on software development (Alves et al., 2016). Issues related to source code are more visible to developers as they are more focused on implementation artifacts. ...
Conference Paper
Full-text available
Context: The concept of technical debt is a metaphor that contextualizes problems faced during software evolution that reflect technical compromises in tasks that are not carried out adequately during their development-they can yield 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. Objective: This work investigates the current state of the art of technical debt tools by identifying which activities, functionalities and kind of technical debt are handled by existing tools that support the technical debt management in software projects. Method: A systematic mapping study is performed to identify and analyze available tools for managing technical debt based on a set of five research questions. Results: The work contributes with (i) a systematic mappping of current research on the field, (ii) a highlight of the most referenced tools, their main characteristics, their supported technical debt types and activities, and (iii) a discussion of emerging findings and implications for future research. Conclusions: Our study identified 50 TD tools where 42 of them are new tools, and 8 tools extend an existing one. Most of the tools address technical debt related to code, design, and/or architecture artifacts. Besides, the different TD management activities received different levels of attention. For example, TD identification is supported by 80% of the tools, whereas 30% of them handle the TD documentation activity. Tools that deal with TD identification and measurement activities are still predominant. However, we observed that recent tools focusing on TD prevention, replacement, and prioritization activities represent emergent research trends.
... Alves et al. [10] conducted a mapping study on the identification of strategies that have been proposed to identify and manage TD in software projects. The search process was performed between 2010 and 2014 on eight digital libraries (namely ACM, IEEE, ScienceDirect, Engineering Village, SpringerLink, Scopus, CITESEER, and DBLP), and retrieved 100 primary studies. ...
Conference Paper
Despite the attention that Technical Debt has attracted over the last years, the quantification of TD Interest still remains rather vague (and abstract). TD Interest quantification is hindered by various factors that introduce a lot of uncertainty, such as: identifying the parts of the system that will be maintained , quantifying the load of maintenance, as well as the size of the maintenance penalty, due to the existence of TD. In this study, we aim to shed light on the current approaches for quantifying TD Interest by exploring existing literature within the TD and Maintenance communities. To achieve this goal, we performed a systematic mapping study on Scopus and explored: (a) the existing approaches for quantifying TD Interest; (b) the existing approaches for estimating Maintenance Cost; and (c) the factors that must be taken into account for their quantification. The broad search process has returned more than 1,000 articles, out of which only 25 provide well-defined mathematical formulas / equations for the quantification of TD Interest or Maintenance Cost (only 6 of them are explicitly for TD Interest). The results suggest that despite their similarities, the quantification of TD Interest presents additional challenges compared to Maintenance Cost Estimation, constituting (at least for the time being) the accurate quantification of TD Interest an open and distant to solve research problem. Regarding the factors that need to be considered for such an endeavor, based on the literature: size, complexity, and business parameters are those that are more actively associated to TD Interest quantification.
... Data from several secondary studies reveal that few TD studies have investigated the relationship between TD and human aspects (Tom et al. 2013;Li et al. 2015;Ampatzoglou et al. 2015;Alves et al. 2016;Fernȧndez-Sȧnchez et al. 2017;Besker et al. 2018a). Rather, the predominant concerns have been technical and financial aspects, e.g., software quality or cost of future changes. ...
Article
Full-text available
Context Software engineering is a human activity. Despite this, human aspects are under-represented in technical debt research, perhaps because they are challenging to evaluate. Objective This study’s objective was to investigate the relationship between technical debt and affective states (feelings, emotions, and moods) from software practitioners. Method Forty participants ( N = 40) from twelve companies took part in a mixed-methods approach, consisting of a repeated-measures ( r = 5) experiment ( n = 200), a survey, and semi-structured interviews. From the qualitative data, it is clear that technical debt activates a substantial portion of the emotional spectrum and is psychologically taxing. Further, the practitioners’ reactions to technical debt appear to fall in different levels of maturity. Results The statistical analysis shows that different design smells (strong indicators of technical debt) negatively or positively impact affective states. Conclusions We argue that human aspects in technical debt are important factors to consider, as they may result in, e.g., procrastination, apprehension, and burnout.
... al.[2], Li et al.[10] and Alves et al.[20] outline directions for future research based on comprehensive reviews of the literature on TD. Tom et al. call out the need to qualify associations of different types of TD to different impacts, and to establish metrics to quantify those impacts. ...
Conference Paper
Full-text available
Technical Debt (TD) is a widely discussed metaphor in IT practice focused on increased short-term benefit in exchange for long-term ‘debt’. While it is primarily individuals or groups inside IT departments who make the decisions to take on TD, we find that the effects of TD stretch across the entire organisation. Decisions to take on TD should therefore concern a wider group. However, business leaders have traditionally lacked awareness of the effects of what they perceive to be ‘technology decisions’. To facilitate TD as group- based decision-making, we review existing literature to develop a typology of the wider impacts of TD. The goal is to help technologists, non-technologists, and academics have a broader and shared understanding of TD and to facilitate more participatory and transparent technology-related decision making. We extend the typology to include a wider ‘outside in’ perspective and conclude by suggesting areas for further research.
... As can be seen from Figure 2, to choose papers from a large set given by the selected databases, four filtering stages were applied. These stages have also been used in other literature studies [10], [15]. First, the related papers were identified in the selected databases (i.e., IEEE Xplore, ScienceDirect, ACM Digital Library, Scopus, SpringerLink). ...
... There has been learning that the enclosed analysis of a tool that approved for the identification and 2.2 Summary dividing of code deficiency or drawbacks. After evaluating almost 100 studies [15] and 38 articles they yielded a mapping study for the identification and management. Laitenburger guided an associate thoroughgoing audit of code scrutiny ways then bestowed his classification of code scrutiny technics [16], [17]. ...
Thesis
Full-text available
Over the decennial survey, the code review process is an effective review process for ensuring the long-term quality of the code base for both open sources and commercial software projects. Peer code review is comprehensively obtained in the development process. Modern peer code review locates ecumenical coding rules and logical errors in the prompt phases of the software development process. The code review quality is predominantly amalgamated with the completeness of the feedback. Until now, there is no original dataset for code review activity, and most datasets are not published yet. I have created my own dataset for code reviews from Gerrit, which is an internal tool for reviewing code. I am using the Decision Tree algorithm for classification because it is the most potent and popular tool for classification and prediction. My main goal is to scrutinize the aspects of the code reviews that make the developers identify different factors and technical difficulties for increasing code review effectiveness and the challenges they faced when performing the code review tasks and build a classification model that can classify review comments to distinguish between useful and not useful code review feedback. Also, provide a robust Decision Tree-based approach taking help from pre-correction code for review recommendations technique in specialized technologies to ameliorate the impractical of code reviews for practitioners in controlling the quality mechanism by diminishing the overall cost.
... Understanding and updating a system's architecture is crucial for software maintenance [14]. As parts of the maintenance activities, development teams review changes [9,38], and design structure after completing a certain milestone or release (or in the late-lifecycle) for various reasons such as paying technical debts, fixing flaws or correcting the design structure [2,15,22]. In this review process, requirements and associated design information extraction, semantic design recovery (concerned with the production of meaning, and how logic and language are used in designing a software [18]), design summary generation, untangling changes, etc. are essential tasks [11,34,38]. ...
Conference Paper
Full-text available
Software architectural changes are involved in the structure of more than one module or component and are complex to analyze compared to local code changes. Development teams aim to review architectural aspects (design) of a change commit considering many essential scenarios such as access rules and restrictions on usage of program entities across the modules. Moreover, design review is essential where proper architectural formulations are paramount for developing and deploying a system. Untangling architectural changes, recovering semantic design, and producing design notes are the crucial tasks of the design review process. To support these tasks, we construct a lightweight tool [4] that can detect and decompose semantic slices of a commit containing architectural instances. A semantic slice consists of a description of relational information of involved modules, their classes, methods and connected modules in a change instance, which is easy to understand to a reviewer. We extract various directory and naming structures (DANS) properties from the source code for developing our tool. Utilizing the DANS properties, our tool first detects architectural change instances based on our defined metric and then decomposes the slices (based on string processing). Our preliminary investigation with ten open-source projects (developed in Java and Kotlin) reveals that the DANS properties produce highly reliable precision and recall (93-100%) for detecting and generating architectural slices. Our proposed tool will serve as the preliminary approach for the semantic design recovery and design summary generation for the project releases.
... If this is neglected, the TD grows and may even cause interest rates, that is, ripple effects that amplify the negative impacts, and thus lead to software erosion. TD can be distinguished by the parts of a system that are affected, leading to different types of TD, such as for code, design, architecture, or tests [3], [52]. In this paper, we focus on and always refer to architectural technical debt. ...
... Most TD identification approaches in literature use static source code analysis (Alves et al., 2016). While this works well for identifying coding rule violations, it also has limitations. ...
Preprint
Full-text available
Technical debt is a metaphor indicating sub-optimal solutions implemented for short-term benefits by sacrificing the long-term maintainability and evolvability of software. A special type of technical debt is explicitly admitted by software engineers (e.g. using a TODO comment); this is called Self-Admitted Technical Debt or SATD. Most work on automatically identifying SATD focuses on source code comments. In addition to source code comments, issue tracking systems have shown to be another rich source of SATD, but there are no approaches specifically for automatically identifying SATD in issues. In this paper, we first create a training dataset by collecting and manually analyzing 4,200 issues (that break down to 23,180 sections of issues) from seven open-source projects (i.e., Camel, Chromium, Gerrit, Hadoop, HBase, Impala, and Thrift) using two popular issue tracking systems (i.e., Jira and Google Monorail). We then propose and optimize an approach for automatically identifying SATD in issue tracking systems using machine learning. Our findings indicate that: 1) our approach outperforms baseline approaches by a wide margin with regard to the F1-score; 2) transferring knowledge from suitable datasets can improve the predictive performance of our approach; 3) extracted SATD keywords are intuitive and potentially indicating types and indicators of SATD; 4) projects using different issue tracking systems have less common SATD keywords compared to projects using the same issue tracking system; 5) a small amount of training data is needed to achieve good accuracy.
... (Cunningham, 1992, p. 30) TD arises from shortcuts and workarounds taken on the code level, as well as decisions made in other stages of the software development lifecycle. Examples include using outdated components in an IT application's development environment that can hinder development activities, lack of automated testing, and using manual build processes that make the build task time-consuming (Alves et al., 2016;Rios et al., 2018). ...
Article
Full-text available
Technical debt (TD) is a technical compromise wherein the ability to maintain information technology (IT) applications over the long term is sacrificed for short-term goals. TD occurs when software development teams undergo constant pressure to release applications swiftly, on a tight schedule. The accumulation of TD, which often leads to a significant cost surplus, presents a ubiquitous challenge in technology-driven organisations. To keep TD levels under control, many organisations implement top-down mechanisms that impose enterprise-wide principles on software development teams. This clinical research presents a complementary but distinct approach to managing TD. A digital nudge was introduced at Credit Suisse, a global financial services company, to help raise awareness and understanding, and stimulate actions related to TD decision-making in software development teams. This paper reports on the nudge’s clinical design, implementation, impact, and evaluation. As the nudge was effective in reducing TD in IT applications after one year of use, we demonstrate that digital nudges are viable means for guiding collective decisions in complex decision environments like that of TD management. Our findings have several implications for research and practice.
... ,Technische Schulden' entstehen bspw. durch schlecht durchgeführte Programmierarbeiten und die Nichtbeachtung von Programmierstandards bei der Softwareentwicklung, nicht durchgeführtes Refactoring, Ignorieren wichtiger Updates, Implementierung neuer Funktionen am falschen Ort in der Anwendungslandschaft, Generierung von Redundanz bei Funktionen oder Daten, falsche Programmdesignentscheidungen oder ungeeignete Datenbankdesigns(Li et al. 2015;Alves et al. 2016). ...
Article
Full-text available
Zusammenfassung Der vorliegende Beitrag beschreibt den strukturellen Aufbau und Untersuchungsumfang einer eigenständigen Due Diligence der IT von Versicherungsunternehmen. Hierzu werden auf Basis einer umfassenden Aufarbeitung der akademischen als auch praxisorientierten Literatur die einzelnen Teilbereiche und Schwerpunktsetzungen bei der Untersuchung der Versicherungs-IT segmentiert sowie ein Ordnungsrahmen für den strukturellen Aufbau einer IT Due Diligence vorgestellt. Ebenfalls wird der idealtypische Ablauf des Analyseprozesses dargestellt und diskutiert, wie sich die Erkenntnisse einer Due Diligence der IT in der sich anschließenden Unternehmensbewertung und den Vertragsverhandlungen berücksichtigen lassen. Dabei zeigt sich, dass die Analyse der Versicherungs-IT im Rahmen einer Due Diligence-Prüfung organisatorische, technische und rechtliche Aspekte umfasst, welche in Form eigenständiger Analysefelder strukturiert werden. Die mit der Informationsverarbeitung des zu akquirierenden Unternehmens in Zusammenhang stehenden Chancen- und Risikoaspekte lassen sich entweder als IT-Integrationskosten und Synergien bei der Unternehmenswertermittlung berücksichtigen oder durch die Ausarbeitung umfangreicher Garantie- und Haftungsvereinbarungen absichern.
... In addition to the four main activities that make up TD Management, literature reviews synthesize and describe other seven activities to support TD Management: Documentation, Communication, Measurement, Prioritization, Analysis, Time-to-market and Preview (Alves et al., 2016;Rios et al., 2018). Identification, monitoring and measurement activities have a significant set of support tools (and approaches) developed. ...
Article
Full-text available
Technical Debt (TD) is a metaphor that describes the cost–benefit relationship between postponing technical development activities and the consequences of this long-term postponement. The lack of TD Management compromises the Software’s internal quality. It makes its maintenance complex and costly. TD instances are called Self-Admitted Technical Debt (SATD) when intentionally committed and documented through comments in the source code. Several studies explore the identification of SATD, but approaches to support the payment stage are lacking, particularly approaches to indicate which SATD priority for payment. This paper presents an approach to support the prioritization activity in SATD payment. The Prioritization Approach focuses on creating associations between SATD associations and problems found in the source code, identified by Automatic Static Analysis. The results demonstrate that using the issues found on source code and SATD description (found in comments) has greater precision to establish the priority among the SATD compared to the SATD description on comments. We applied the approach proposed to different software projects, and the results support developers’ prioritization.
... Code smells are considered one of the key indicators of TD [12]. Recently, a plethora of work related to code smell detection has been proposed in the literature [13], [14], [15], [16]. ...
Article
Technical Debt (TD) is a successful metaphor in conveying the consequences of software inefficiencies and their elimination to both technical and non-technical stakeholders, primarily due to its monetary nature. The identification and quantification of TD rely heavily on the use of a small handful of sophisticated tools that check for violations of certain predefined rules, usually through static analysis. Different tools result in divergent TD estimates calling into question the reliability of findings derived by a single tool. To alleviate this issue we use 18 metrics pertaining to source code, repository activity, issue tracking, refactorings, duplication and commenting rates of each class as features for statistical and Machine Learning models, so as to classify them as High-TD or not. As a benchmark we exploit 18,857 classes obtained from 25 Java projects, whose high levels of TD has been confirmed by three leading tools. The findings indicate that it is feasible to identify TD issues with sufficient accuracy and reasonable effort: a subset of superior classifiers achieved an F 2-measure score of approximately 0.79 with an associated Module Inspection ratio of approximately 0.10. Based on the results a tool prototype for automatically assessing the TD of Java projects has been implemented.
Chapter
Digital transformations facilitate the need for speed. However, how the required digital maturity to manage transformation is not well-understood. This Dutch research examines inhibitors for digital maturity and is focusing on the business as well as the information technology side. Using a literature review and survey research of managers from national and global firms based in the Netherlands; we present a research model and empirically test the hypothesized relationships. The results show the inhibitors for digital maturity including the capability limitations for both the Chief Information Officer and the business representatives. In the research also the balance between achieving the digital business and information technology maturity has been measured: number of months required to achieve digital maturity. There is support for the hypothesis that information technology and business digital maturity are balanced.
Conference Paper
Self-Admitted Technical Debt (SATD) is a sub-type of technical debt. It is introduced to represent such technical debts that are intentionally introduced by developers in the process of software development. While being able to gain short-term benefits, the introduction of SATDs often requires to be paid back later with a higher cost, e.g., introducing bugs to the software or increasing the complexity of the software. To cope with these issues, our community has proposed various machine learning-based approaches to detect SATDs. These approaches, however, are either not generic that usually require manual feature engineering efforts or do not provide promising means to explain the predicted outcomes. To that end, we propose to the community a novel approach, namely HATD (Hybrid Attention-based method for self-admitted Technical Debt detection), to detect and explain SATDs using attention-based neural networks. Through extensive experiments on 445,365 comments in 20 projects, we show that HATD is effective in detecting SATDs on both in-the-lab and in-the-wild datasets under both within-project and cross-project settings. HATD also outperforms the state-of-the-art approaches in detecting and explaining SATDs. CCS CONCEPTS • Software and its engineering → Software notations and tools; Software maintenance tools.
Article
Full-text available
Searching relevant papers is a fundamental task for the elaboration of secondary studies. This task is known to be tedious and time‐consuming when it is made manually, especially with the presence of several academic repositories. Recently, Semantic Scholar has emerged as a new artificial intelligence‐based search engine enabling a set of valuable features. The present study investigates the role of Semantic Scholar in retrieving relevant papers for performing secondary studies in software engineering. For this sake, an examination is performed to check the ability of Semantic Scholar to locate included papers in recent and well‐established secondary studies. Afterwards, a hybrid and automatic search strategy is introduced making use of Semantic Scholar as a sole search engine and it incorporates: automatic search, snowballing, and use of Computer Science Ontology (CSO) and Software Engineering Body of Knowledge (SWEBOK) for refining queries. The proposed strategy is validated by replicating the search of high‐quality secondary studies in the software engineering field. To guarantee objectivity, a systematic search is conducted of recent secondary studies published in the field since 2015. For the coverage test, Semantic Scholar is examined to locate primary papers of selected secondary studies and identify missing venues. The proposed search strategy is used to check the ability to retrieve primary papers of each secondary study. The systematic search yielded 20 high‐quality secondary studies with 1337 distinct primary papers. The coverage test revealed that Semantic Scholar covers 98.88% of the papers. The proposed search strategy enabled the full replication of 13 studies and more than 90% for the 7 remaining studies.
Chapter
This chapter introduces several local search methods and their R implementations, namely hill climbing (pure and steepest ascent and stochastic variants), simulated annealing, and tabu search. Then, the chapter demonstrates how local search methods can be compared. Finally, it shows how modern optimization methods (including local search ones) can be tuned in terms of their internal parameters by using an iterated racing.
Article
The goal of software development is to deliver software products with high quality and free from defects, but resource and time constraints often cause the developers to submit incomplete or temporary patches of codes and further bear the additional burden. Therefore, the investigations on identifying self‐admitted technical debt (SATD) to improve code quality have been conducted in recent years. However, missing syntactic structure information and the imbalance distribution bias shorten the SATD identification performance. Addressing to this issue, we present a graph neural network based SATD identification model (GNNSI) to improve the performance. Specifically, we obtain the structure information of the missing SATD in a compositional way to obtain different feature maps for different comments, and use focal loss to handle the imbalance between SATD and non‐SATD classes in the comments. Then extensive experiments on 10 open source projects are conducted, and the results show that GNNSI outperforms the baselines and can help developers to better predict SATDs.
Article
Paying-off the Architectural Technical Debt by refactoring the flawed code is important to control the debt and to keep it as low as possible. Project Managers tend to delay paying off this debt because they face difficulties in comparing the cost of the refactoring against the benefits gained. These managers need to estimate the cost and the efforts required to conduct these refactoring activities as well as to decide which flaws have higher priority to be refactored. Our research is based on a dataset used by other researchers that study the technical debt. It includes more than 18,000 refactoring operations performed on 33 apache java projects. We applied the COCOMO II:2000 model to calculate the refactoring cost in person-months units per release. Furthermore, we investigated the correlation between the refactoring efforts and two static code metrics of the refactored code. The research revealed a weak correlation between the refactoring efforts and the size of the project, and a moderate correlation with the code complexity. Finally, we applied the DesigniteJava tool to verify our research results. From the analysis we found a significant correlation between the ranking of the architecture smells and the ranking of refactoring efforts for each package. Using machine learning practices, we took the architecture smells level and the code metrics of each release as an input to predict the levels of the refactoring effort of the next release. We calculated the results using our model and found that we can predict the ‘High’ and ‘Very High’ levels, the most significant levels from managers’ perspective, with [Formula: see text] accuracy.
Article
Full-text available
Information systems development (ISD) is an integral part of organizational agility in today’s competitive business environment. High turnover, agile ways of working, and fluid work environments pose challenges for ISD. This paper explores the erosion of knowledge retention (KR) arising from ISD staff churn in a New Zealand-based financial organization in the aftermath of a major earthquake. In this exploratory study, the authors develop a causal model of KR in the ISD context, which articulates the challenges to and consequences of ineffective KR at the routine and exiting stages of KR. The model identifies four challenges—coordination complexity, insufficient resources for knowledge retention, insufficient attention to knowledge retention, and slow staff replacement and handover processes—that can affect the loss of ISD knowledge when routine and exiting KR fall into disarray. This study also reveals that role stress and reduced ISD agility reinforce the cycle of knowledge loss.
Article
Full-text available
Context While the digital economy requires a new generation of technology for scientists and practitioners, the software engineering (SE) field faces a gender crisis. SE research is a global enterprise that requires the participation of both genders for the advancement of science and evidence-based practice. However, women across the world tend to be significantly underrepresented in such research, receiving less funding and less participation, frequently, than men as authors in research publications. Data about this phenomenon is still sparse and incomplete; particularly in evidence-based software engineering (EBSE), there are no studies that analyze the participation of women in this research area. Objective The objective of this work is to present the results of a systematic mapping study (SM) conducted to collect and evaluate evidence on female researchers who have contributed to the area of EBSE. Method Our SM was performed by manually searching studies in the major conferences and journals of EBSE. We identified 981 studies and 183 were authored/co-authored by women and, therefore, included. Results Contributions from women in secondary studies have globally increased over the years, but it is still concentrated in European countries. Additionally, collaboration among research groups is still fragile, based on a few women as a bridge. Latin American researchers contribute a great deal to the field, despite they do not collaborate as much within their region. Conclusions The findings from this study are expected to be aggregated to the existing knowledge with respect to women’s contribution to the EBSE area. We expect that our results bring up a reflection on the gender issue and motivate actions and policies to attract female researchers to this area.
Article
Technical debt is a metaphor for seeking short-term gains at expense of long-term code quality. Previous studies have shown that self-admitted technical debt, which is introduced intentionally, has strong negative impacts on software development and incurs high maintenance overheads. To help developers identify self-admitted technical debt, researchers have proposed many state-of-the-art methods. However, there is still room for improvement about the effectiveness of the current methods, as self-admitted technical debt comments have the characteristics of length variability, low proportion and style diversity. Therefore, in this paper, we propose a novel approach based on the bidirectional long short-term memory (BiLSTM) networks with the attention mechanism to automatically detect self-admitted technical debt by leveraging source code comments. In BiLSTM, we utilize a balanced cross entropy loss function to overcome the class unbalance problem. We experimentally investigate the performance of our approach on a public dataset including 62, 566 code comments from ten open source projects. Experimental results show that our approach achieves 81.75% in terms of precision, 72.24% in terms of recall and 75.86% in terms of F1-score on average and outperforms the state-of-the-art text mining-based method by 8.14%, 5.49% and 6.64%, respectively.
Preprint
Full-text available
Architectural Technical Debt (ATD) is considered as the most significant type of TD in industrial practice. In this study, we interview 21 software engineers and architects to investigate a specific type of ATD, namely architectural smells (AS). Our goal is to understand the phenomenon of AS better and support practitioners to better manage it and researchers to offer relevant support. The findings of this study provide insights on how practitioners perceive AS and how they introduce them, the maintenance and evolution issues they experienced and associated to the presence of AS, and what practices and tools they adopt to manage AS.
Article
Technical debt (TD) entails the shortcuts and unsuitable choices made during the development or maintenance of an IT system, which can result in negative consequences such as inefficiency and instability of the IT system. Digitalizing the government has led to the development of numerous IT systems which must be maintained to prevent decay, standstill, additional costs, and a decline in software quality. Previous studies on TD have primarily focused on the private sector, while TD in the public sector has largely been ignored. Therefore, this case study investigated TD management in relation to two IT systems in a Danish agency. Through participant observations and in-situ interviews we studied actual TD behavior, while stakeholder theory combined with a categorization of TD types and activities served as our theoretical lens. Thus, our study (1) identifies the stakeholders influencing an agency's TD management, (2) maps stakeholders' actions, and (3) identifies stakeholders' influence on TD. We found that TD extends beyond the influence of software developers and is also influenced by the behavior of several non-technical stakeholders, e.g., the European Parliament. We offer practical recommendations for TD management based on these findings.
Preprint
Full-text available
This paper presents a tertiary review of software quality measurement research. To conduct this review, we examined an initial dataset of 7,811 articles and found 75 relevant and high-quality secondary analyses of software quality research. Synthesizing this body of work, we offer an overview of perspectives, measurement approaches, and trends. We identify five distinct perspectives that conceptualize quality as heuristic, as maintainability, as a holistic concept, as structural features of software, and as dependability. We also identify three key challenges. First, we find widespread evidence of validity questions with common measures. Second, we observe the application of machine learning methods without adequate evaluation. Third, we observe the use of aging datasets. Finally, from these observations, we sketch a path toward a theoretical framework that will allow software engineering researchers to systematically confront these weaknesses while remaining grounded in the experiences of developers and the real world in which code is ultimately deployed.
Article
Full-text available
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.
Article
Full-text available
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.
Article
Full-text available
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.
Preprint
Full-text available
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.
Conference Paper
Full-text available
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
Article
Full-text available
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.
Conference Paper
Full-text available
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.
Article
Full-text available
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/.
Conference Paper
Full-text available
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.
Conference Paper
Full-text available
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.
Article
Full-text available
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.
Conference Paper
Full-text available
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.
Conference Paper
Full-text available
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.
Conference Paper
Full-text available
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.
Conference Paper
Full-text available
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.
Conference Paper
Full-text available
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.
Conference Paper
Full-text available
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.
Conference Paper
Full-text available
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.
Conference Paper
Full-text available
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.
Conference Paper
Full-text available
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.
Conference Paper
[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.
Article
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.
Article
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.
Article
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.
Article
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.
Conference Paper
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.
Conference Paper
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 w