|
Technical debt is common for software projects. It is not problematic as long as the debt is repaid through refactoring, re-designing, re-documenting, re-testing, etc. But if a project takes on too much debt, the software becomes more complex, less understandable and more difficult to maintain, which are the costs of technical debt. These costs are most evident to software developers, who must deal with the immature code that was delivered. The purpose of this study is to understand how technical debt manifests itself in software projects and how to recognize and manage it, from the point of view of software developers. * We have successfully carried out the study. Results and findings are published at IEEE Software |
|
This study aims at addressing the cost-benefit relationships of incurring technical debt and the benefits of explicitly managing technical debt in comparison with implicit management. In the study we will simulate the decisions about release planning as they would have been made if the technical debt had been tracked. Through simulation we will gain insight into what the software project would have done differently. The benefits of explicitly managing technical debt can then be determined by comparing the actual decisions with the simulated decisions. The study will be based on in-depth analysis of historical effort, defect, testing, and change data over several recent releases of software projects. * Multiple studies using small scale projects from different organizations have either been carried out or planned. Results from one example study can be found at ICSM 2011 |
|
Retrospective Study of Software Projects |
|
Current Studies |
|
Interview Study of Software Developers |
|
Measuring and Monitoring Technical Debt |
|
* This work is supported by NSF grant #0916699. |
|
Currently decisions about when to fix a defect, i.e. whether to fix it when it is detected or to fix it in the future, is usually made by a Change Control Board for a product or system through impact analysis. Although cost is a factor considered in the course of the impact analysis, the decision is rarely driven by a rigorous cost-benefit analysis. Therefore we carry out this study to uncover the cost categories associated with fixing a defect and the factors affecting the decisions about when to fix a defect. The goal of this study is to determine whether the addition of cost-benefit analysis could improve the decision making and benefit the software project. * We carried out this study with researchers from ABB USCRC. ABB provided the subject projects and data. Part of the results has been published at the International MTD Workshop 2012 |
|
Defect Debt Study |
|
The code-level technical debt accumulated by a system can be identified through different source code analysis techniques; what has not been studied is how a larger set of techniques overlap with respect to flagging source code components, and how the use of these techniques helps identifying code components that are in debt. This study aims at comparing the results of different technical debt identification approaches to understand their commonalities and differences and to evaluate their relationship to software quality. In this study we select four different technical debt identification techniques (code smells, automatic static analysis (ASA) issues, grime buildup, and modularity violations) and apply them to 13 versions of the Apache Hadoop open source software project. We collect and aggregate statistical measures to investigate whether the different techniques identified TD indicators in the same classes and whether those classes exposed high defect and change proneness. * We carried out this study with researchers from Drexel University, Montana State University, Politecnico di Torino and Siemens Healthcare. The results have been published in the Software Quality Journal |
|
HADOOP Study |
|
While the aforementioned retrospective study will provide evidence of a benefit from applying the technical debt management approach, it will not shed light on the costs of the approach. This insight will come from the case study, which focuses on the future releases of the selected software projects. In the case study we will be applying the technical debt management process to the new releases of the projects. The goal of this study is to reveal the costs of explicit technical debt management. The findings from this case study and the retrospective study, together, will be used to develop a theory of technical debt, as well as refinements to the proposed technical debt management approach. * We have new collaborators who are planning to host this study at their organization. |
|
Technical Debt Case Study |
|
The technical debt concept, while highly useful as a metaphor, has utility beyond the facilitation of discussion. The metaphor can also be translated into a useful set of methods and tools that support the identification, measurement, monitoring, management, and payment of technical debt. In this context, we are conducting a study that focuses on the practical identification of technical debt, one area that could be facilitated by tools and techniques. The first contribution of this study is the evaluation of human elicitation of technical debt. We will evaluate a technical debt template that can be used to capture, store, and communicate essential properties of technical debt. Besides the template, our case study will give some insight into the dynamics of eliciting technical debt from a team of developers, all familiar with different aspects of the system being analyzed. As a second contribution we will evaluate the utility of tool support for technical debt identification. * We have successfully carried out the study with developers from Kali Software. Kali Software provided the subject projects and data. Partial results can be found in the paper published at 17th International Conference on Evaluation and Assessment in Software Engineering (EASE 2013), Porto de Galinhas, Brazil, April 2013 . |
|
Developer-reported Technical Debt |
