Do practitioners intentionally repay their own Technical Debt and why?

The impact of Technical Debt (TD) on software maintenance and evolution is of great concern, but recent evidence shows that a considerable amount of TD is fixed by the same developers who introduced it; this is termed self-fixed TD. This characteristic of TD management can potentially impact team dynamics and practices in managing TD. However, the initial evidence is based on low-level source code analysis; this casts some doubt whether practitioners repay their own debt intentionally and under what circumstances. To address this gap, we conducted an online survey on 17 well-known Java and Python open-source software communities to investigate practitioners’ intent and rationale for self-fixing technical debt. We also investigate the relationship between human-related factors (e.g., experience) and self-fixing. The results, derived from the responses of 181 participants, show that a majority addresses their own debt consciously and often. Moreover, those with a higher level of involvement (e.g., more experience in the project and number of contributions) tend to be more concerned about self-fixing TD. We also learned that the sense of responsibility is a common self-fixing driver and that decisions to fix TD are not superficial but consider balancing costs and benefits, among other factors. The findings in this paper can lead to improving TD prevention and management strategies

Qualitative analysis of the relationship between design smells and software engineering challenges

Software design debt aims to elucidate the rectification attempts of the present design flaws and studies the influence of those to the cost and time of the software. Design smells are a key cause of incurring design debt. Although the impact of design smells on design debt have been predominantly considered in current literature, how design smells are caused due to not following software engineering best practices require more exploration. This research provides a tool which is used for design smell detection in Java software by analyzing large volume of source codes. More specifically, 409,539 Lines of Code (LoC) and 17,760 class files of open source Java software are analyzed here. Obtained results show desirable precision values ranging from 81.01\% to 93.43\%. Based on the output of the tool, a study is conducted to relate the cause of the detected design smells to two software engineering challenges namely "irregular team meetings" and "scope creep". As a result, the gained information will provide insight to the software engineers to take necessary steps of design remediation actions.Comment: arXiv admin note: substantial text overlap with arXiv:1910.0542

Architectural technical debt identification:The research landscape

Architectural Technical Debt (ATD) regards sub-optimal design decisions that bring short-term benefits to the cost of long-term gradual deterioration of the quality of the architecture of a software system. The identification of ATD strongly influences the technical and economic sustainability of software systems and is attracting growing interest in the scientific community. During the years several approaches for ATD identification have been conceived, each of them addressing ATD from different perspectives and with heterogeneous characteristics. In this paper we apply the systematic mapping study methodology for identifying, classifying, and evaluating the state of the art on ATD identification from the following three perspectives: publication trends, characteristics, and potential for industrial adoption. Specifically, starting from a set of 509 potentially relevant studies, we systematically selected 47 primary studies and analyzed them according to a rigorously-defined classification framework. The analysis of the obtained results supports both researchers and practitioners by providing (i) an assessment of current research trends and gaps in ATD identification, (ii) a solid foundation for understanding existing (and future) research on ATD identification, and (iii) a rigorous evaluation of its potential for industrial adoption

Assessing Smart Contracts Security Technical Debts

Smart contracts are self-enforcing agreements that are employed to exchange assets without the approval of trusted third parties. This feature has encouraged various sectors to make use of smart contracts when transacting. Experience shows that many deployed contracts are vulnerable to exploitation due to their poor design, which allows attackers to steal valuable assets from the involved parties. Therefore, an assessment approach that allows developers to recognise the consequences of deploying vulnerable contracts is needed. In this paper, we propose a debt-aware approach for assessing security design vulnerabilities in smart contracts. Our assessment approach involves two main steps: (i) identification of design vulnerabilities using security analysis techniques and (ii) an estimation of the ramifications of the identified vulnerabilities leveraging the technical debt metaphor, its principal and interest. We use examples of vulnerable contracts to demonstrate the applicability of our approach. The results show that our assessment approach increases the visibility of security design issues. It also allows developers to concentrate on resolving smart contract vulnerabilities through technical debt impact analysis and prioritisation. Developers can use our approach to inform the design of more secure contracts and for reducing unintentional debts caused by a lack of awareness of security issues

The lifecycle of Technical Debt that manifests in both source code and issue trackers

Context: Although Technical Debt (TD) has increasingly gained attention in recent years, most studies exploring TD are based on a single source (e.g., source code, code comments or issue trackers). Objective: Investigating information combined from different sources may yield insight that is more than the sum of its parts. In particular, we argue that exploring how TD items are managed in both issue trackers and software repositories (including source code and commit messages) can shed some light on what happens between the commits that incur TD and those that pay it back. Method: To this end, we randomly selected 3,000 issues from the trackers of five projects, manually analyzed 300 issues that contained TD information, and identified and investigated the lifecycle of 312 TD items. Results: The results indicate that most of the TD items marked as resolved in issue trackers are also paid back in source code, although many are not discussed after being identified in the issue tracker. Test Debt items are the least likely to be paid back in source code. We also learned that although TD items may be resolved a few days after being identified, it often takes a long time to be identified (around one year). In general, time is reduced if the same developer is involved in consecutive moments (i.e., introduction, identification, repayment decision-making and remediation), but whether the developer who paid back the item is involved in discussing the TD item does not seem to affect how quickly it is resolved. Conclusions: Investigating how developers manage TD across both source code repositories and issue trackers can lead to a more comprehensive oversight of this activity and support efforts to shorten the lifecycle of undesirable debt.</p

Towards Automatically Addressing Self-Admitted Technical Debt: How Far Are We?

Upon evolving their software, organizations and individual developers have to spend a substantial effort to pay back technical debt, i.e., the fact that software is released in a shape not as good as it should be, e.g., in terms of functionality, reliability, or maintainability. This paper empirically investigates the extent to which technical debt can be automatically paid back by neural-based generative models, and in particular models exploiting different strategies for pre-training and fine-tuning. We start by extracting a dateset of 5,039 Self-Admitted Technical Debt (SATD) removals from 595 open-source projects. SATD refers to technical debt instances documented (e.g., via code comments) by developers. We use this dataset to experiment with seven different generative deep learning (DL) model configurations. Specifically, we compare transformers pre-trained and fine-tuned with different combinations of training objectives, including the fixing of generic code changes, SATD removals, and SATD-comment prompt tuning. Also, we investigate the applicability in this context of a recently-available Large Language Model (LLM)-based chat bot. Results of our study indicate that the automated repayment of SATD is a challenging task, with the best model we experimented with able to automatically fix ~2% to 8% of test instances, depending on the number of attempts it is allowed to make. Given the limited size of the fine-tuning dataset (~5k instances), the model's pre-training plays a fundamental role in boosting performance. Also, the ability to remove SATD steadily drops if the comment documenting the SATD is not provided as input to the model. Finally, we found general-purpose LLMs to not be a competitive approach for addressing SATD