A Consolidated Understanding of Technical debt

Technical debt utilises financial debt as a metaphor to describe the phenomenon of increasing software development costs over time. Whilst this phenomenon is evidently detrimental to the long-term success of software development, it appears to be poorly understood in the academic literature. The absence of a clear definition and model for technical debt means that the notion of technical debt remains metaphorical, thus preventing the realisation of technical debt’s utility as a conceptual and technical communication device. This exploratory study reconciles the high-level, abstracted view of technical debt presented in academic literature. It establishes the boundaries of the technical debt phenomenon and develops a comprehensive theoretical framework to facilitate future research. The resulting theoretical framework portrays a holistic view of technical debt that incorporates a set of precedents and outcomes, as well as the phenomenon itself.

[1]  Ivan Porres,et al.  Metrics Functions for Kanban Guards , 2010, 2010 17th IEEE International Conference and Workshops on Engineering of Computer Based Systems.

[2]  Robert L. Nord,et al.  Managing technical debt in software-reliant systems , 2010, FoSER '10.

[3]  Jonathan P. Bowen,et al.  Formal Versus Agile: Survival of the Fittest , 2009, Computer.

[4]  Justin D. Davis,et al.  Surviving the Economic Downturn , 2009, 2009 Agile Conference.

[5]  Colin J. Neill,et al.  Paying down design debt with strategic refactoring , 2006, Computer.

[6]  Ward Cunningham,et al.  The WyCash portfolio management system , 1992, OOPSLA '92.

[7]  LasseniusCasper,et al.  What Types of Defects Are Really Discovered in Code Reviews , 2009 .

[8]  Forrest Shull,et al.  Perfectionists in a World of Finite Resources , 2011, IEEE Softw..

[9]  Mika Mäntylä,et al.  What Types of Defects Are Really Discovered in Code Reviews? , 2009, IEEE Transactions on Software Engineering.

[10]  Rebecca Wirfs-Brock,et al.  Designing Then and Now , 2008, IEEE Software.

[11]  Anders Wall,et al.  A Method for Balancing Short- and Long-Term Investments: Quality vs. Features , 2008, 2008 34th Euromicro Conference Software Engineering and Advanced Applications.

[12]  Anders Wall,et al.  Key Aspects of Software Release Planning in Industry , 2008 .

[13]  Barbara Kitchenham,et al.  Procedures for Performing Systematic Reviews , 2004 .

[14]  Robert L. Nord,et al.  Enabling Agility Through Architecture , 2010 .

[15]  Patrick Debois,et al.  Agile Infrastructure and Operations: How Infra-gile are You? , 2008, Agile 2008 Conference.

[16]  Richard Torkar,et al.  Adopting Free/Libre/Open Source Software Practices, Techniques and Methods for Industrial Use , 2011, J. Assoc. Inf. Syst..

[17]  Audris Mockus,et al.  Does Code Decay? Assessing the Evidence from Change Management Data , 2001, IEEE Trans. Software Eng..

[18]  Robert L. Glass,et al.  An assessment of systems and software engineering scholars and institutions (1993-1997) , 1997, Journal of Systems and Software.

[19]  John Klein,et al.  How Does the Architect’s Role Change as the Software Ages? , 2005, 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05).

[20]  Tsong Yueh Chen,et al.  An assessment of systems and software engineering scholars and institutions (1993-1997) , 1997, J. Syst. Softw..