Refactoring: improving the design of existing code
Refactoring: improving the design of existing code
Detection Strategies: Metrics-Based Rules for Detecting Design Flaws
ICSM '04 Proceedings of the 20th IEEE International Conference on Software Maintenance
Object-Oriented Metrics in Practice
Object-Oriented Metrics in Practice
The evolution and impact of code smells: A case study of two open source systems
ESEM '09 Proceedings of the 2009 3rd International Symposium on Empirical Software Engineering and Measurement
Building empirical support for automated code smell detection
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
ICSM '10 Proceedings of the 2010 IEEE International Conference on Software Maintenance
A case study on effectively identifying technical debt
Proceedings of the 17th International Conference on Evaluation and Assessment in Software Engineering
An exploration of technical debt
Journal of Systems and Software
Hi-index | 0.00 |
Technical debt is the technical work developers owe a system, typically caused by speeding up development, e.g. before a software release. Approaches, such as code smell detection, have been developed to identify particular kinds of debt, e.g. design debt. Up until now, code smell detection has been used to help point to components that need to be freed from debt by refactoring. To date, a number of methods have been described for finding code smells in a system. However, typical debt properties, such as the value of the debt and interest rate to be paid, have not been well established. This position paper proposes an approach to using cost/benefit analysis to prioritize technical debt reduction work by ranking the value and interest of design debt caused by god classes. The method is based on metric analysis and software repository mining and is demonstrated on a commercial software application at a mid-size development company. The results are promising: the method helps to identify which refactoring activities should be performed first because they are likely to be cheap to make yet have significant effect, and which refactorings should be postponed due to high cost and low payoff.