Got Technical Debt? Surfacing Elusive Technical Debt in Issue Trackers
May 2016 • Conference Paper
Stephany Bellomo, Robert Nord, Ipek Ozkaya, Mary Popeck
This paper reports on a study of issues from issue trackers to identify technical debt and present an approach for reporting technical debt in issue trackers.
This paper was presented at Mining Software Repositories (MSR) 2016, co-located with ICSE 2016, in Austin, Texas, 14-15 May, 2016.
Concretely communicating technical debt and its consequences is of common interest to both researchers and software engineers. In the absence of validated tools and techniques to achieve this goal with repeatable results, developers resort to ad hoc practices. Most commonly they report using issue trackers or their existing backlog management practices to capture and track technical debt. In a manual examination of 1,246 issues from four issue trackers from open source industry and government projects, we identified 109 examples of technical debt. Our study reveals that technical debt and its related concepts have entered the vernacular of developers as they discuss development tasks through issue trackers. Even when issues are not explicitly tagged as technical debt, it is possible to identify technical debt items in these issue trackers using a categorization method we developed. We use our results and data to motivate an improved definition and an approach to explicitly report technical debt in issue trackers.
Technical Debt Search Results: This Excel document contains the list of tracked issues from the Connect and Chromium projects that we classified as technical debt.
Comparative Analysis: This Excel document compares the issues tagged as technical debt with those that were tagged as not technical debt for each of the four projects. The comparison is based on the number of days the issues remained open using mean plots and a median box chart.
Technical Debt Item Classification Guidance: This document provides detailed guidance for how to use our classification scheme to identify technical debt items and to screen out items that are not technical debt, such as new features, user stories, documentation, new requirements, and defects.