Technical Debt Research Articles

Crowdsmelling: A preliminary study on using collective knowledge in code smells detection

Code smells are seen as major source of technical debt and, as such, should be detected and removed. However, researchers argue that the subjectiveness of the code smells detection process is a major hindrance to mitigate the problem of smells-infected code. We proposed the crowdsmelling approach based on supervised machine learning techniques, where the wisdom of the crowd (of software developers) is used to collectively calibrate code smells detection algorithms, thereby lessening the subjectivity issue. This paper presents the results of a validation experiment for the crowdsmelling approach. In the context of three consecutive years of a Software Engineering course, a total "crowd" of around a hundred teams, with an average of three members each, classified the presence of 3 code smells (Long Method, God Class, and Feature Envy) in Java source code. These classifications were the basis of the oracles used for training six machine learning algorithms. Over one hundred models were generated and evaluated to determine which machine learning algorithms had the best performance in detecting each of the aforementioned code smells. Good performances were obtained for God Class detection (ROC=0.896 for Naive Bayes) and Long Method detection (ROC=0.870 for AdaBoostM1), but much lower for Feature Envy (ROC=0.570 for Random Forrest). Obtained results suggest that crowdsmelling is a feasible approach for the detection of code smells, but further validation experiments are required to cover more code smells and to increase external validity.

Exploring the relationship between refactoring and code debt indicators

AbstractRefactoring, 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.

Technical debt: What it is, how it limits you and what you can do to manage it

Within educational advancement services, technical debt (and data debt) can have positive or adverse impacts on the strategic initiatives of your organisation as well as your team’s ability to innovate or feel empowered. With the ever-growing need for data products, technical debt can be leveraged positively to provide timely insights into prospect engagement or donor segmentation. However, like its financial counterpart, it can adversely affect staff morale, impair a team’s velocity and impact overall productivity, if it is not managed. This paper identifies what technical debt is; differentiates the types of technical debt and their corresponding effects on your strategies and leadership; and proposes techniques to empower your staff in assessing, mitigating, and planning your technical debt.

Toward a Conceptual Framework for Technical Debt in Archives

ABSTRACT Early collections-based digital projects and their infrastructure, including website platforms and software, digital asset management systems, information systems, metadata, and preservation protocols, serve as the foundation for many library, archives, and museum (LAM) repositories' ongoing efforts to organize, describe, and make digital assets widely accessible online. Completed projects, despite well-intended planning and execution, can become time intensive to maintain and migrate forward as new projects that meet fresh programmatic goals and current professional standards, become today's focus. Assessment of past projects, with the goal of making better decisions in the future (i.e., “lessons learned”), can be framed through an understanding of the term “technical debt,” a metaphor used within the software development community. The authors define and explore the concept of technical debt, relating it specifically to the archival field, and suggest a preliminary conceptual framework of technical debt to inform decision-making.

Does it matter who pays back Technical Debt? An empirical study of self-fixed TD

Technical Debt (TD) can be paid back either by those that incurred it or by others. We call the former self-fixed TD, and it can be particularly effective, as developers are experts in their own code and are well-suited to fix the corresponding TD issues.

Writing Across the Spectrum

Writing Across the Spectrum

Integrating privacy debt and VSE's software developments

AbstractWith the advent of regulations protecting users such as the General Data Protection Regulation, security and privacy concerns are playing a new role in small settings such as in very small entities. Their relevance is increasing, and privacy is being considered a Troy horse in software developments. In fact, privacy is a part of software architectural decisions, and they must be considered as a technical debt. The contributions of this paper are the following: a privacy debt definition with a principal and an interest, privacy‐related activities to be considered within the ISO/IEC 29110 basic profile, and the use of the net present value within this context. All these contributions help us to integrate privacy debt and VSE's software developments.

Understanding Roxygen package documentation in R

R is a package-based programming ecosystem that provides an easy way to install third-party code, datasets, and examples. Thus, R developers rely heavily on the documentation of the packages they import to use them correctly and accurately. This documentation is often written using Roxygen, equivalent to Java’s well-known Javadoc. This two-part study provides the first analysis in this area. First, 379 systematically-selected, open-source R packages were mined and analysed to address the quality of their documentation in terms of presence, distribution, and completeness to identify potential sources of documentation debt of technical debt that describes problems in the documentation. Second, a survey addressed how R package developers perceive documentation and face its challenges (with a response rate of 10.04%). Results show that incomplete documentation is the most common smell, with several cases of incorrect use of the Roxygen utilities. Unlike in traditional API documentation, developers do not focus on how behaviour is implemented but on common use cases and parameter documentation. Respondents considered the examples section the most useful, and commonly perceived challenges were unexplained examples, ambiguity, incompleteness and fragmented information.

Empirical evaluation of an architectural technical debt index in the context of the Apache and ONAP ecosystems.

BackgroundArchitectural Technical Debt (ATD) in a software-intensive system denotes architectural design choices which, while being suitable or even optimal when adopted, lower the maintainability and evolvability of the system in the long term, hindering future development activities. Despite the growing research interest in ATD, how to gain an informative and encompassing viewpoint of the ATD present in a software-intensive system is still an open problem.ObjectiveIn this study, we evaluate ATDx, a data-driven approach providing an overview of the ATD present in a software-intensive system. The approach, based on the analysis of a software portfolio, calculates severity levels of architectural rule violations via a clustering algorithm, and aggregates results into different ATD dimensions.MethodTo evaluate ATDx, we implement an instance of the approach based on SonarQube, and run the analysis on the Apache and ONAP ecosystems. The analysis results are then shared with the portfolio contributors, who are invited to participate in an online survey designed to evaluate the representativeness and actionability of the approach.ResultsThe survey results confirm the representativeness of the ATDx, in terms of both the ATDx analysis results and the used architectural technical debt dimensions. Results also showed the actionability of the approach, although to a lower extent when compared to the ATDx representativeness, with usage scenarios including refactoring, code review, communication, and ATD evolution analysis.ConclusionsWith ATDx, we strive for the establishment of a sound, comprehensive, and intuitive architectural view of the ATD identifiable via source code analysis. The collected results are promising, and display both the representativeness and actionability of the approach. As future work, we plan to consolidate the approach via further empirical experimentation, by considering other development contexts (e.g., proprietary portfolios and other source code analysis tools), and enhancing the ATDx report capabilities.

The use of incentives to promote technical debt management

When developing software, it is vitally important to keep the level of technical debt down since, based on several studies, it has been well established that technical debt can lower the development productivity, decrease the developers' morale and compromise the overall quality of the software, among others. However, even if researchers and practitioners working in today's software development industry are quite familiar with the concept of technical debt and its related negative consequences, there has been no empirical research focusing specifically on how software managers actively communicate and manage the need to keep the level of technical debt as low as possible.

An empirical study on self-admitted technical debt in Dockerfiles

In software development, ad hoc solutions that are intentionally implemented by developers are called self-admitted technical debt (SATD). Because the existence of SATD spreads poor implementations, it is necessary to remove it as soon as possible. Meanwhile, container virtualization has been attracting attention in recent years as a technology to support infrastructure such as servers. Currently, Docker is the de facto standard for container virtualization. In Docker, a file describing how to build a container (Dockerfile) is a set of procedural instructions; thus, it can be considered as a kind of source code. Moreover, because Docker is a relatively new technology, there are few developers who have accumulated good or bad practices for building Docker container. Hence, it is likely that Dockerfiles contain many SATDs, as is the case with general programming language source code analyzed in previous SATD studies. The goal of this paper is to categorize SATDs in Dockerfiles and to share knowledge with developers and researchers. To achieve this goal, we conducted a manual classification for SATDs in Dockerfile. We found that about 3.0% of the comments in Dockerfile are SATD. In addition, we have classified SATDs into five classes and eleven subclasses. Among them, there are some SATDs specific to Docker, such as SATDs for version fixing and for integrity check. The three most common classes of SATD were related to lowering maintainability, testing, and defects.

Guiding legacy systems for evolution. PmatE: a case study of maintenance and engineering

Even though software change is inevitable, accurate maintenance can extend software lifespan in a subtle way when both budget and time constraints get in the way of software replacement. In the University of Aveiro, the project PmatE – a quiz web platform created to encourage students to like Math – emerged in the early 1990’s and stacked several applications over the decades without major planning, cleaning or upgrade. This resulted in a huge-sized framework that was crucial to be always available and online and had high operational cost, leading to an increasing amount of technical debt. After 3 decades, the project was studied, refactored and refurbished, leading to a stable consistent framework ready for evolution and software spinouts. This work shows how to manage and engineer solutions to maintain a legacy system and evolve it even when tied up to heavy constraints.

Toward prioritization of self-admitted technical debt: an approach to support decision to payment

Toward prioritization of self-admitted technical debt: an approach to support decision to payment

Investigating the Point of View of Project Management Practitioners on Technical Debt - A Preliminary Study on Stack Exchange

Investigating the Point of View of Project Management Practitioners on Technical Debt - A Preliminary Study on Stack Exchange

Predictive Software Engineering: Transform Custom Software Development into Effective Business Solutions

The paper examines the principles of the Predictive Software Engineering (PSE) framework. The authors examine how PSE enables custom software development companies to offer transparent services and products while staying within the intended budget and a guaranteed budget. The paper will cover all 7 principles of PSE: (1) Meaningful Customer Care, (2) Transparent End-to-End Control, (3) Proven Productivity, (4) Efficient Distributed Teams, (5) Disciplined Agile Delivery Process, (6) Measurable Quality Management and Technical Debt Reduction, and (7) Sound Human Development.

Further investigation of the survivability of code technical debt items

AbstractContext: 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.

Insight: leadership

Abstract Jon G. Hall CITP FBCS writes about the human cost to the mountains of accumulated technical debt — and what, if anything, can be done about it.

Exploiting gated graph neural network for detecting and explaining self-admitted technical debts

Self-admitted technical debt (SATD) refers to a specific type of technical debt that is introduced intentionally in the software development and maintenance processes. SATD enables practitioners to take some temporary solutions instead of making comprehensive decisions, which will lead to the high complexity of the software. However, most existing studies relied on manual methods for detecting SATDs. A recent study proposed a method HATD that used a hybrid attention-based method to automatically detect SATDs and it achieved the state-of-the-art performance. However, HATD mainly focused on the locality of the comment instances and lacked of the relationship between long-distance and discontinuous comment instances. To address such an issue, in this work, we propose a novel approach named GGSATD. Specifically, GGSATD first builds the graph for comment instances and then employs the gated graph neural network to iteratively update node representation. The global representation can be obtained by the soft attention mechanism and pooling operation. Experiments on 10 projects show that our GGSATD method obtains promising performance against five baseline methods in both within-project and cross-project scenarios. Extended experiments on seven real-world projects illustrate the effectiveness of our GGSATD method.

Managing Software Testing Technical Debt Using Evolutionary Algorithms

Technical debt (TD) happens when project teams carry out technical decisions in favor of a short-term goal(s) in their projects, whether deliberately or unknowingly. TD must be properly managed to guarantee that its negative implications do not outweigh its advantages. A lot of research has been conducted to show that TD has evolved into a common problem with considerable financial burden. Test technical debt is the technical debt aspect of testing (or test debt). Test debt is a relatively new concept that has piqued the curiosity of the software industry in recent years. In this article, we assume that the organization selects the testing artifacts at the start of every sprint. Implementing the latest features in consideration of expected business value and repaying technical debt are among candidate tasks in terms of the testing process (test cases increments). To gain the maximum benefit for the organization in terms of software testing optimization, there is a need to select the artifacts (i.e., test cases) with maximum feature coverage within the available resources. The management of testing optimization for large projects is complicated and can also be treated as a multi-objective problem that entails a trade-off between the agile software’s short-term and long-term value. In this article, we implement a multi-objective indicator-based evolutionary algorithm (IBEA) for fixing such optimization issues. The capability of the algorithm is evidenced by adding it to a real case study of a university registration process.

SATDBailiff-mining and tracking self-admitted technical debt

Self-Admitted Technical Debt (SATD) is a metaphorical concept to describe the self-documented addition of technical debt to a software project in the form of source code comments. SATD can linger in projects and degrade source-code quality, but it can also be more visible than unintentionally added or undocumented technical debt. Understanding the implications of adding SATD to a software project is important because developers can benefit from a better understanding of the quality trade-offs they are making. However, empirical studies, analyzing the survivability and removal of SATD comments, are challenged by potential code changes or SATD comment updates that may interfere with properly tracking their appearance, existence, and removal. In this paper, we propose SATDBailiff, a tool that uses an existing state-of-the-art SATD detection tool, to identify SATD in method comments, then properly track their lifespan. SATDBailiff is given as input links to open source projects, and its output is a list of all identified SATDs, and for each detected SATD, SATDBailiff reports all its associated changes, including any updates to its text, all the way to reporting its removal. The goal of SATDBailiff is to aid researchers and practitioners in better tracking SATDs instances, and providing them with a reliable tool that can be easily extended. SATDBailiff was validated using a dataset of previously detected and manually validated SATD instances. SATDBailiff is publicly available as an open source, along with the manual analysis of SATD instances associated with its validation, on the project website.1