Measuring and Monitoring Technical Debt

Abstract

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.

Examining Technical Debt Accumulation in Software Implementations

“…When creating these dependent solutions, if additional work is required due to inoptimality in these areas, this constitutes as paying interest. Seaman, et al, formalize this further by defining interest as an occurrence probability coupled with a value [19]. The occurrence probability takes into account that not all technical debt affects the project: for example if a part of the software implementation is never re-used, the probability of this part hindering further implementation updates is zero.…”

“…This is problematic, especially in our case, where we must apply the definition in the extraction process. Further, as both definitions in [20] and [19] extend the concept to technical debt management, the problem of repay probability adjustment is encountered. In both cases, the problem is not fully overcome, as the probability of technical debt becoming payable is mostly affected by the unforeseeable future development environment.…”

“…Management of technical debt can be either implicit -like in many agile software practices, where reviews are made during and in between iterations to ensure that the subproducts meet the organizations definition of done-or explicit -like employing a variation of the Technical Debt Management Framework [19,8]. In either case, the success of technical debt management is largely, if not solely, dependent onto the availability of current technical debt information [20].…”

Supporting Technical Debt Cataloging with TD-Tracker Tool

“…Design or code debt can be identified by statically analyzing source code or inspecting code compliance to standards [4]. Izurieta et al [6] mentioned techniques and tools that could potentially be useful in the identification activity.…”

“…Seaman and Guo [4] explain a tradeoff when dealing with technical debt. They argue that software managers need to balance between incurring TD and the associated costs when planning their projects.…”