Refactoring, Bug Fixing, and New Development Effect on Technical Debt: An Industrial Case Study

Zabardast, Ehsan; González-Huerta, Javier; Šmite, Darja

doi:10.1109/seaa51224.2020.00068

Cited by 15 publications

(20 citation statements)

References 23 publications

(41 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…By synthesizing the results of RQ2.1 and RQ2.2 we can claim that new code is associated with the risk of generating interest: the more new code is inserted along evolution the lower the risk, and if this new code is "clean" the impact of the Technical Debt Interest Risk is further reduced. This result, complies with the literature, suggesting that clean new code reduces the amount of Technical Debt Principal along evolution (Digkas et al 2017, Zabardast et al 2020. Additionally, we emphasize that the amount of new code appears to be a more important factor for reducing the risk of producing Technical Debt Interest, compared to the quality of the code.…”

Section: Relation Of Igri and New Codesupporting

confidence: 90%

“…In this section, we use the IGRI metric, so as to explore the relation between new code and the risk of generating TD Interest. New code has been discussed in the literature as an alternative to refactoring, for reducing the amount of technical debt (Digkas et al 2017, Zabardast et al 2020. To this end, we explore: (a) if the average percentage of new code that is accumulated in a package along evolution, is associated with a decrease or increase of IGRI-RQ2.1; and (b) if there is a relation between IGRI and the quality of the new code-RQ2.2.…”

Section: Relation Of Igri and New Codementioning

confidence: 99%

See 1 more Smart Citation

Reducing Technical Debt Density: Refactoring vs. Writing Clean New Code

Digkas

View full text Add to dashboard Cite

Technical Debt (TD) is a powerful metaphor that represents shortcuts taken in a software development project, usually to meet business goals such as limited time or budget. Technical Debt concerns mostly invisible parts of the system (i.e. no visible features or defects) and has a detrimental effect on the maintainability and evolvability of software. Technical Debt manifests in both design and implementation constructs such as sub-optimal design decisions, design and code smells, use of impertinent technologies, lack of documentation etc.Technical Debt cannot realistically be eliminated but it does need to be proactively managed in order to be kept at a sustainable level. Managing Technical Debt is comprised of a number of activities. In this thesis, we focus on two of these activities, which are reported in the literature as the most important: repayment and prevention. As its name suggests, repayment refers to the remediation of Technical Debt by reworking the aforementioned design and implementation constructs; consider for example refactoring the source code, optimizing a design decision or documenting architecture knowledge that has remained tacit. Similarly, prevention of Technical Debt refers to ensuring the underlying issues will not occur in the first place; consider for example, checking for source code violations, supporting design decision making to avoid future maintenance overhead or simply allocating enough resources to follow the right approach instead of the 'quick and dirty' one. In this thesis, we investigate to what extent repayment (through refactoring) and prevention (through writing clean new code) are effective in managing Technical Debt.In order to address the stated problem, we first need to understand better the evolution of technical debt in practice. Specifically we need to investigate whether technical debt grows or remains stable over time, both at the macroscopic level, and at the level of individual issues and their types. Through a large-scale case study, we learned that in the majority of the systems that we studied, there is a significant increase trend on the size, number of issues, and on the complexity metrics of the project. On the other hand, the amount of technical v

show abstract

Section: Relation Of Igri and New Codesupporting

confidence: 90%

Section: Relation Of Igri and New Codementioning

confidence: 99%

Reducing Technical Debt Density: Refactoring vs. Writing Clean New Code

Digkas

View full text Add to dashboard Cite

show abstract

“…Digkas et al 16 analyzed TD repayment by focusing on a broader set of TDIs, but with a coarse granularity (weekly snapshots) while we analyze the effect at commit level. In our previous work, 27 we analyzed the impact of different activities on TD, that is, whether each activity contributed to the accumulation or repayment of TD, while in this paper, we focus on TDIs. We present a statistical model on the survivability of code TDIs.…”

Section: Related Workmentioning

confidence: 99%

“…While there are alternative tools to detect the TDIs in the codebase of a system such as Codacy # and PMD source code analyzer k , we decided to use SonarQube ** because it is widely used in both industrial and open-source systems 29 and has been used in other research studies, for example, Zabardast et al, 27 Digkas et al" 16 and Guaman et al 30 SonarQube, similar to other static analysis tools, parses the code base, and builds a model for each commit being analyzed.…”

Section: Using Sonarqube For Code Technical Debt Items Detectionmentioning

confidence: 99%

Further investigation of the survivability of code technical debt items

Zabardast

Bennin

González-Huerta

2022

J Software Evolu Process

Self Cite

View full text Add to dashboard Cite

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.

show abstract

“…Others have studied the effects and efficiency of refactoring operations embedded in feature development (e.g. [44,92]).…”

Section: A2 Encapsulation Separation Of Concernsmentioning

confidence: 99%

Towards an Anatomy of Software Craftsmanship

SundelinAnders

González-Huerta

WnukKrzysztof

et al. 2021

ACM Trans. Softw. Eng. Methodol.

Self Cite

View full text Add to dashboard Cite

Context: The concept of software craftsmanship has early roots in computing, and in 2009, the Manifesto for Software Craftsmanship was formulated as a reaction to how the Agile methods were practiced and taught. But software craftsmanship has seldom been studied from a software engineering perspective. Objective: The objective of this article is to systematize an anatomy of software craftsmanship through literature studies and a longitudinal case study. Method: We performed a snowballing literature review based on an initial set of nine papers, resulting in 18 papers and 11 books. We also performed a case study following seven years of software development of a product for the financial market, eliciting qualitative, and quantitative results. We used thematic coding to synthesize the results into categories. Results: The resulting anatomy is centered around four themes, containing 17 principles and 47 hierarchical practices connected to the principles. We present the identified practices based on the experiences gathered from the case study, triangulating with the literature results. Conclusion: We provide our systematically derived anatomy of software craftsmanship with the goal of inspiring more research into the principles and practices of software craftsmanship and how these relate to other principles within software engineering in general.

show abstract

Refactoring, Bug Fixing, and New Development Effect on Technical Debt: An Industrial Case Study

Cited by 15 publications

References 23 publications

Reducing Technical Debt Density: Refactoring vs. Writing Clean New Code

Reducing Technical Debt Density: Refactoring vs. Writing Clean New Code

Further investigation of the survivability of code technical debt items

Towards an Anatomy of Software Craftsmanship

Contact Info

Product

Resources

About