Managing technical debt in practice

Understanding the impact of technical debt in coding and testing

“…The findings from this study showed that developers use their own taxonomy based on their experience and interpretation for TD. Likewise, Siebra et al [17] reported on a study carried out by collecting data from documents, emails, and interviews to characterize technical debt. The results of this study highlighted the advantages of technical debt in software development projects and defined team modification as another source of TD in software development projects.…”

Establishing a Framework for Managing Interest in Technical Debt

“…The probability that TD, if not repaid, will make other work more expensive Decreasing maintainability The probability that TD, if not repaid, will make other work more expensive Siebra (2012) Extra Effort Snipes (2012) The extra cost required to complete a maintenance activity in the future if the task is postponed, plus the cost of other work that is required due to the presence of the TD (2011) Expected interest amount and interest standard deviation can be estimated using historical effort, usage, change, and defect data.…”

“…We organize the tentative research design by goal: Types of Interest: An interesting research direction could be the empirical investigation of:  whether I(r) and I(m) occur with the same frequency, and  whether I(r) and I(m) produce a similar amount of interest when they occur,  how I(r) and I(m) amount could be modelled, as a function of the principal, or the underlying structure of the TDI. So far, these questions have been explored only by ), Nugroho et al (2011), and Siebra et al (2012, by exploring historical changes and documentation. The research state-of-the-art lacks real-world evidence on effort allocation.…”

RT 128: New Project Incubator

“…Since Ward Cunningham first drew the comparison between technical complexity and debt in his experience report in 1992 (Cunningham, 1992), research on TD detection and evaluation has been prosperous and fruitful in multiple domains including software architecture/design and software code quality in both academia and industry. Over the past three decades, about a hundred of studies have been published, with their topics ranging from TD conceptual analysis (e.g., (Siebra et al, 2012;Schmid, 2013), detection (e.g., (Marinescu, 2004;Wong et al, 2011;Marinescu, 2012;Zazworka et al, 2014), to evaluation (e.g., (Izurieta et al, 2013;Ktata and Lévesque, 2010;Nugroho et al, 2011). Although the increasing number of studies produced significant benefits in defining and assessing TD as well as improving software quality (Sharma, 2012;Ramasubbu and Kemerer, 2013;Griffith et al, 2014), there lacks of a consistent and consolidated view of the definitions and determinant factors of TD, which may result in confusion on its detection and evaluation in both academic research and industrial practice.…”