ACM SIGPLAN Notices
Object-Oriented Metrics in Practice
Object-Oriented Metrics in Practice
Mining metrics to predict component failures
Proceedings of the 28th international conference on Software engineering
Source Code Analysis: A Road Map
FOSE '07 2007 Future of Software Engineering
A systematic review of software maintainability prediction and metrics
ESEM '09 Proceedings of the 2009 3rd International Symposium on Empirical Software Engineering and Measurement
Domain-specific tailoring of code smells: an empirical study
Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 2
Building empirical support for automated code smell detection
Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement
CodeVizard: a tool to aid the analysis of software evolution
Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement
Managing technical debt in software-reliant systems
Proceedings of the FSE/SDP workshop on Future of software engineering research
Investigating the impact of design debt on software quality
Proceedings of the 2nd Workshop on Managing Technical Debt
Prioritizing design debt investment opportunities
Proceedings of the 2nd Workshop on Managing Technical Debt
Hi-index | 0.00 |
Context: The technical debt (TD) concept describes a tradeoff between short-term and long-term goals in software development. While it is highly useful as a metaphor, it has utility beyond the facilitation of discussion, to inspire a useful set of methods and tools that support the identification, measurement, monitoring, management, and payment of TD. Objective: This study focuses on the identification of TD. We evaluate human elicitation of TD and compare it to automated identification. Method: We asked a development team to identify TD items in artifacts from a software project on which they were working. We provided the participants with a TD template and a short questionnaire. In addition, we also collected the output of three tools to automatically identify TD and compared it to the results of human elicitation. Results: There is little overlap between the TD reported by different developers, so aggregation, rather than consensus, is an appropriate way to combine TD reported by multiple developers. The tools used are especially useful for identifying defect debt but cannot help in identifying many other types of debt, so involving humans in the identification process is necessary. Conclusion: We have conducted a case study that focuses on the practical identification of TD, one area that could be facilitated by tools and techniques. It contributes to the TD landscape, which depicts an understanding of relationships between different types of debt and how they are best discovered.