An empirical model of technical debt and interest

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

“…Approximately 65% of all code anomalies were related to 78% of all architecture problems [9]; therefore it could be thought that these techniques overlap. However Zazworka et al [ 10] Focusing on code technical debt, Nugroho et al [20] propose a method based on lines of code, code duplication, McCabe's cyclomatic complexity, parameter counts, and dependency counts to score software on the basis of its maintainability. This approach calculates the total technical debt in a system but does not identify concrete technical debt items.…”

“…Based on this accumulated knowledge, it is assumed that a similar problem in a similar project will imply a same effort to solve the problem. Following this criteria, in [20] and [35] a function of the estimated percentage of lines of code to be changed and an estimation of effort per line of code are used. Both variables are estimated using statistical information collected from other projects using the same technology.…”

“…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].…”

“…One strategy used to estímate technical debt's economic consequences is oriented to provide a big picture of the whole system without providing low-level detail of how technical debt is distributed in the system. Nugroho et al [20] propose a method based on code metrics (lines of code, code duplication, McCabe's eyelomatic complexity, parameter counts, and dependeney counts) to score software on the basis of its maintainability. This same approach can be seen in [35].…”

Establishing a Framework for Managing Interest in Technical Debt

“…The probability of extra work TD can cause to future development Koolmanojwong (2013) More expensive to fix than it is to do it right the first time Letouzey (2012) The negative impact of TD Marinescu (2012) Extra maintenance effort required in the future due to hasty, inappropriate design McGregor (2012) Any extra work over the expected amount, when later we carry out the deferred activity Nord (2012) Increasing rework cost of the unpaid TD Nugroho (2011) The extra maintenance cost spent for not achieving the ideal quality level Schmid (2013) Additional effort spent on not quite good code Potential penalty paid in the future as a result of not completing tasks in the present…”