Tracking technical debt — An exploratory case study

An Analysis of Techniques and Methods for Technical Debt Management: A Reflection from the Architecture Perspective

“…Curtís et al [22] detect code and architectural violations and use information obtained from several projects to estímate the effort needed to solve these kinds of violations, considering the programming language. The second strategy consists of detecting technical debt items and utilizing the typical effort estimation that the organization uses [36] 3) Interest Estimation: For the interest estimation, some studies use an estimated maintenance effort based on information collected from other projects using the same technology [20] [35]. Others use defect likelihood and change likelihood to estímate the technical debt items' impact on system quality; in their case, they focus on classes with the God class code smell [14] [29].…”

Supporting Technical Debt Cataloging with TD-Tracker Tool

“…These types summarize all defined types proposed by [31]. Each type of technical debt represents a different activity since the process or tool used in identification of this activity can be different.…”

“…The structure for cataloging technical debt in the proposed approach is based on the documentation structure introduced as part of the Technical Debt Management Framework (TDMF) [4,31] by Seaman et al This structure is extended in order to decompose entries into reusable components as well as to properly present technical debt in different software development activities.…”

“…At this point it is necessary to contextualize decision making, but it is not detailed since the work is limited to TD identification and cataloging process, also to describe a tool for tracking TD. Guo et al [31] described one scenario in which the technical debt list is used to facilitate decision making in release planning. For this planning, the project manager sorts TD according to their cost and benefit and determines the set that should be paid to minimize the cost and maximize the benefits of the project.…”

How Bad is it? – A Branching Activity Model to Estimate the Impact of Information Security Breaches

“…It is vital that people and organizations recognize and learn from near-miss events. Another example is captured in the phrase 'technical debt' (Brown et al 2010, Guo et al 2011, Klinger et al 2011, which refers to short cuts and other expedient actions taken by IT system designers prior to a release. These may not 'cost' them anything in the very short-run, but sooner or later the 'debt' must be paid off eventually, either through patching or through the cost of security breaches.…”