2 research outputs found
Does it matter who pays back Technical Debt? An empirical study of self-fixed TD
Context: 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. Objective: The goal of our study is to
investigate self-fixed technical debt, especially the extent in which TD is
self-fixed, which types of TD are more likely to be self-fixed, whether the
remediation time of self-fixed TD is shorter than non-self-fixed TD and how
development behaviors are related to self-fixed TD. Method: We report on an
empirical study that analyzes the self-fixed issues of five types of TD (i.e.,
Code, Defect, Design, Documentation and Test), captured via static analysis, in
more than 44,000 commits obtained from 20 Python and 16 Java projects of the
Apache Software Foundation. Results: The results show that about half of the
fixed issues are self-fixed and that the likelihood of contained TD issues
being self-fixed is negatively correlated with project size, the number of
developers and total issues. Moreover, there is no significant difference of
the survival time between self-fixed and non-self-fixed issues. Furthermore,
developers are more keen to pay back their own TD when it is related to lower
code level issues, e.g., Defect Debt and Code Debt. Finally, developers who are
more dedicated to or knowledgeable about the project contribute to a higher
chance of self-fixing TD. Conclusions: These results can benefit both
researchers and practitioners by aiding the prioritization of TD remediation
activities and refining strategies within development teams, and by informing
the development of TD management tools
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