Yuepu Guo

Measuring and Monitoring Technical Debt

Abstract Technical debt is a metaphor for immature, incomplete, or inadequate artifacts in the software development lifecycle that cause higher costs and lower quality in the long run. These artifacts remaining in a system affect subsequent development and maintenance activities, and so can be seen as a type of debt that the system developers owe the system. Incurring technical debt may speed up software development in the short run, but such benefit is achieved at the cost of extra work in the future, as if paying interest on the debt. In this sense, the technical debt metaphor characterizes the relationship between the short-term benefits of delaying certain software maintenance tasks or doing them quickly and less carefully, and the long-term cost of those delays. However, managing technical debt is more complicated than managing financial debt because of the uncertainty involved. In this chapter, the authors review the main issues associated with technical debt, and propose a technical debt management framework and a research plan for validation. The objective of our research agenda is to develop and validate a comprehensive technical debt theory that formalizes the relationship between the cost and benefit sides of the concept. Further, we propose to use the theory to propose mechanisms (processes and tools) for measuring and managing technical debt in software product maintenance. The theory and management mechanisms are intended ultimately to contribute to the improved quality of software and facilitate decision making in software maintenance.

Using technical debt data in decision making: potential decision approaches

The management of technical debt ultimately requires decision making - about incurring, paying off, or deferring technical debt instances. This position paper discusses several existing approaches to complex decision making, and suggests that exploring their applicability to technical debt decision making would be a worthwhile subject for further research.

A portfolio approach to technical debt management

Technical debt describes the effect of immature software artifacts on software maintenance - the potential of extra effort required in future as if paying interest for the incurred debt. The uncertainty of interest payment further complicates the problem of what debt should be incurred or repaid and when. To help software managers make informed decisions, a portfolio approach is proposed in this paper. The approach leverages the portfolio management theory in the finance domain to determine the optimal collection of technical debt items that should be incurred or held. We expect this approach could provide a new perspective for technical debt management.

Tracking technical debt — An exploratory case study

The technical debt metaphor is increasingly being used to describe the effect of delaying certain software maintenance tasks on software projects. Practitioners understand intuitively how technical debt can turn into a serious problem if it is left unattended. However, it remains unknown how serious the problem is and whether explicit measurement and management of technical debt is useful. In this paper, we explore the effect of technical debt by tracking a single delayed maintenance task in a real software project throughout its lifecycle and simulate how explicit technical debt management might have changed project outcomes. The results from this study demonstrate how and to what extent technical debt affects software projects. The study also sheds light on the research methodologies that can be used to investigate the technical debt management problem.

Defect categorization: making use of a decade of widely varying historical data

This paper describes our experience in aggregating a number of historical datasets containing inspection defect data using different categorization schemes. Our goal was to make use of the historical data by creating models to guide future development projects. We describe our approach to reconciling the different choices used in the historical datasets to categorize defects, and the challenges we faced. We also present a set of recommendations for others involved in classifying defects.

Defining the decision factors for managing defects: a technical debt perspective

Making a decision about whether to fix or defer fixing a defect is important to software projects. Deferring defects accumulates a technical debt that burdens the software team and customer with a less than optimal solution. The decision to defer fixing a defect is made by Software Change Control Boards (CCBs) based on a set of decision factors. In this paper, we evaluated the set of decision factors used by two CCBs at ABB in the context of technical debt management The aim was to determine how a model of cost and benefits of incurring technical debt could be part of the CCB decision process. We identified the cost categories and decision factors for fixing and deferring defects as a result of interviews with CCB members. We found that the decision factors could incorporate the financial aspects when using the technical debt metaphor. We identify opportunities for further research to integrate technical debt concepts with the decision factors towards better long term outcomes.

Exploring the costs of technical debt management --- a case study

Technical debt is a metaphor for delayed software maintenance tasks. Incurring technical debt may bring short-term benefits to a project, but such benefits are often achieved at the cost of extra work in future, analogous to paying interest on the debt. Currently technical debt is managed implicitly, if at all. However, on large systems, it is too easy to lose track of delayed tasks or to misunderstand their impact. Therefore, we have proposed a new approach to managing technical debt, which we believe to be helpful for software managers to make informed decisions. In this study we explored the costs of the new approach by tracking the technical debt management activities in an on-going software project. The results from the study provided insights into the impact of technical debt management on software projects. In particular, we found that there is a significant start-up cost when beginning to track and monitor technical debt, but the cost of ongoing management soon declines to very reasonable levels.

Domain-specific tailoring of code smells: an empirical study

Code smells refer to commonly occurring patterns in source code that indicate poor programming practices or code decay. Detecting code smells helps developers find design problems that can cause trouble in future maintenance. Detection rules for code smells, based on software metrics, have been proposed, but they do not take domain-specific characteristics into consideration. In this study we investigate whether such generic heuristics can be tailored to include domain-specific factors. Input into these domain-specific heuristics comes from an iterative empirical field study in a software maintenance project. The results yield valuable insight into code smell detection.

Web application fault classification - an exploratory study

Controlled experiments in web application testing use seeded faults to evaluate the effectiveness of the testing technique. However, the classes of seeded faults are not always experimentally supported by real-world fault data. In this paper, we conduct an exploratory study on two large open source web systems to identify a fault classification that is representative of and supported by real world faults. Through our study we provide support to several categories of an existing web application fault classification, and identify one new fault category and six new sub-categories. Researchers and experimenters will find the proposed fault classification useful when evaluating techniques for testing web applications.

A survey of software project managers on software process change

Software project managers play an important role in selecting their software development process. In this study we conducted a survey of software project managers about software process change. The result of the survey revealed several factors affecting this type of decision making. It also revealed critical issues in software development projects. In particular, the findings point to the importance of a piloting strategy in technology transfer, as well as the importance of highlighting cost, quality, and schedule information in reporting evidence of a new techniques effectiveness. We expect that the findings of this study could facilitate research on technology transfer and adoption.