Measuring and Monitoring Technical Debt

TLDR: The objective of the 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 and propose mechanisms for measuring and managing technical debt in software product maintenance.

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.

Figures

Table 19. Costs of Technical Debt Management

Figure 13. Timeline of the SMB Evolution

Figure 8. Risk Analysis Matrix [62]

Table 17. Costs (in person-hours) of Technical Debt Management Activities over the Sprints

Figure 3. Cumulative Functionality in Two Scenarios [44]

Table 16. Changes in the Technical Debt List over the Sprints

Full text

APPROVAL SHEET
Title of Dissertation: Measuring and Monitoring Technical Debt
Name of Candidate: Yuepu Guo
Doctor of Philosophy, 2016
Dissertation and Abstract Approved: ( )
Carolyn Seaman
Associate Professor
Department of Information Systems
Date Approved: ________________

ABSTRACT
Title of Document: MEASURING AND MONITORING
TECHNICAL DEBT
Yuepu Guo, Ph.D., 2016
Directed By: Associate Professor Carolyn Seaman,
Department of Information Systems
Technical debt is a metaphor for the effects of delayed software development and
maintenance tasks. Due to the delay, software may carry immature artifacts in its
lifecycle, e.g., immature design, incomplete documentation, etc., which may 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 is common
for software projects and can often increase productivity in the short run. However,
like paying interest on the debt, such benefit is achieved at the cost of extra work in
future. In this sense the technical debt metaphor characterizes the relationship
between the short-term benefits of delaying certain software tasks or doing them
quickly and less carefully and the long-term cost of those delays or shortcuts. It
should be noted that the extra cost may not be realized if the portion of a system
containing technical debt will never be touched in the future. Therefore, the problem
boils down to managing risk and making informed decisions on which delayed tasks
need to be accomplished, and when. Currently, managers and leaders of software
maintenance carry out this risk analysis implicitly, if at all. However, on large
systems, it is too easy to lose track of delayed tasks or to misunderstand their impact.

The result is often unexpected delays and compromised quality. Therefore
identifying, measuring and monitoring technical debt would help managers make
informed decisions, resulting in higher quality of maintained software and greater
maintenance productivity. The objective of this research work is to contribute to a
comprehensive technical debt theory that characterizes the cost and benefit sides of
technical debt management. To achieve this objective, we carried out two types of
studies – retrospective study and case study – on real software projects. Through
decision simulation, the retrospective studies uncovered the benefits of explicit
technical debt management. The case studies revealed the costs of technical debt
management. The results from the studies provide insights into the technical debt
management problem, thus facilitating decision making in software projects and
practical application of technical debt management in the software industry.

MEASURING AND MONITORING TECHNICAL DEBT
By
Yuepu Guo
Dissertation submitted to the Faculty of the Graduate School of the
University of Maryland, Baltimore County, in partial fulfillment
of the requirements for the degree of
Doctor of Philosophy
2016

© Copyright by
Yuepu Guo
2016

Frequently asked questions

Q1. What are the contributions in this paper?

The objective of this research work is to contribute to a comprehensive technical debt theory that characterizes the cost and benefit sides of technical debt management. To achieve this objective, the authors carried out two types of studies – retrospective study and case study – on real software projects. The results from the studies provide insights into the technical debt management problem, thus facilitating decision making in software projects and practical application of technical debt management in the software industry. 

Q2. What are the future works in this paper?

Therefore, the authors ’ ve included in their future work to study software projects in governmental systems, which will help us uncover more factors affecting benefits and costs of technical debt management and thus improve the generalizability of the theory they are building for technical debt management. Similarly, the authors also plan to study non-Agile projects ( all those they ’ ve studied have been Agile ), as software development process could affect technical debt management and the related decision making as well. N. Brown et al., `` Managing technical debt in software-reliant systems, '' in Proceedings of the FSE/SDP workshop on Future of software engineering research, Santa Fe, New Mexico, USA, 2010, pp. 47-52, 1882373: ACM. [ 29 ] 

Q3. What is the key to developing a technical debt management process?

Since technical debt is closely related to software risks, a process for managing risk is key to developing a technical debt management process. 

Q4. What are the five tasks that are used to guide the risk management process?

CRM consists of five continuous tasks to guide the risk management process: identify software risks using SEI’s risk taxonomy, analyze the risks to determine their probability of occurrence, impact on theorganization and the relationships between individual risk statements, plan risk mitigation for the identified risk areas, track individual risks, mitigation plans, and the risk process to determine theeffectiveness of mitigation actions and the risk process, control deviations from planned risk mitigation actions and make decisions,e.g., close, re-plan, continue tracking. 

Q5. What is the common metric for evaluating the potential loss of risk?

The simplest metric for evaluating the potential loss of risk, i.e., risk impact, is to use an ordinal rating scale, which defines the impact as low, medium and high [62]. 

Q6. What are some of the approaches used for risk analysis?

some approaches used for risk analysis, especially those used for probability estimation and risk prioritization, are also applicable to technical debt management. 

Q7. What are the dimensions of technical debt?

The dimensions of technical debt proposed in their study largely conform to the classification based on software lifecycle, including code debt, design and architectural debt, knowledge distribution and documentation debt, and testing debt. 

Q8. What is the way to pay off the debt associated with god classes?

One strategy for paying off the debt associated with god classes is to choose classes starting with the upper left corner of the chart, and then moving down and to the right. 

Q9. What is the principal, interest probability and interest amount of technical debt in the proposed approach?

The principal, interest probability and interest amount of technical debt in their proposed approach are initially estimated as high, medium or low, as is often done in risk estimation. 

Q10. What is the effect of technical debt on software development?

for technical debt, intentional or not, the effect is that the maintenance time or cost is reduced in the current stage, i.e., technical debt speeds up software development in the short run.