On the interest of architectural technical debt: Uncovering the contagious debt phenomenon

A known problem in large software companies is to balance the prioritization of short‐term and long‐term business goals. As an example, architecture suboptimality (Architectural Technical Debt), incurred to deliver fast, might hinder future feature development. However, some technical debt generates more interest to be paid than other. We conducted a multi‐phase, multiple‐case embedded case study comprehending 9 sites at 6 large international software companies. We have investigated which architectural technical debt items generate more interest , how the interest occurs during software development and which costly extra‐activities are triggered as a result. We presented a taxonomy of the most dangerous items identified during the qualitative investigation and a model of their effects that can be used for prioritization, for further investigation and as a quality model for extracting more precise and context‐specific metrics. We found that some architectural technical debt items are contagious, causing the interest to be not only fixed, but potentially compound, which leads to the hidden growth of interest (possibly exponential). We found important factors to be monitored to refactor the debt before it becomes too costly. Instances of these phenomena need to be identified and stopped before the development reaches a crises.

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

[2]  Yuanfang Cai,et al.  A Case Study in Locating the Architectural Roots of Technical Debt , 2015, 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering.

[3]  Christine Nadel,et al.  Case Study Research Design And Methods , 2016 .

[4]  Audris Mockus,et al.  Quantifying the Effect of Code Smells on Maintenance Effort , 2013, IEEE Transactions on Software Engineering.

[5]  Jan Bosch,et al.  A Systematic Literature Review and a Unified Model of ATD , 2016, 2016 42th Euromicro Conference on Software Engineering and Advanced Applications (SEAA).

[6]  Yuanfang Cai,et al.  Using technical debt data in decision making: Potential decision approaches , 2012, 2012 Third International Workshop on Managing Technical Debt (MTD).

[7]  Christian Berger,et al.  Explicating, Understanding, and Managing Technical Debt from Self-Driving Miniature Car Projects , 2014, 2014 Sixth International Workshop on Managing Technical Debt.

[8]  Walter Bartosz,et al.  Antipattern and Code Smell False Positives: Preliminary Conceptualization and Classification , 2016 .

[9]  Jan Bosch,et al.  Investigating Architectural Technical Debt accumulation and refactoring over time: A multiple-case study , 2015, Inf. Softw. Technol..

[10]  Per Runeson,et al.  Guidelines for conducting and reporting case study research in software engineering , 2009, Empirical Software Engineering.

[11]  Robert L. Nord,et al.  Reducing Friction in Software Development , 2016, IEEE Software.

[12]  Jan Bosch,et al.  Architecture Technical Debt: Understanding Causes and a Qualitative Model , 2014, 2014 40th EUROMICRO Conference on Software Engineering and Advanced Applications.

[13]  Apostolos Ampatzoglou,et al.  The financial aspect of managing technical debt: A systematic literature review , 2015, Inf. Softw. Technol..

[14]  Joost Visser,et al.  An empirical model of technical debt and interest , 2011, MTD '11.

[15]  Jan Bosch,et al.  An Empirically Developed Method to Aid Decisions on Architectural Technical Debt Refactoring: AnaConDebt , 2016, 2016 IEEE/ACM 38th International Conference on Software Engineering Companion (ICSE-C).

[16]  Klaus Schmid A formal approach to technical debt decision making , 2013, QoSA '13.

[17]  Richard T. Vidgen,et al.  An exploration of technical debt , 2013, J. Syst. Softw..

[18]  André L. M. Santos,et al.  Tracking technical debt — An exploratory case study , 2011, 2011 27th IEEE International Conference on Software Maintenance (ICSM).

[19]  Antonio Martini,et al.  Estimating and Quantifying the Benefits of Refactoring to Improve a Component Modularity: A Case Study , 2016, 2016 42th Euromicro Conference on Software Engineering and Advanced Applications (SEAA).

[20]  Robert L. Nord,et al.  Technical Debt: From Metaphor to Theory and Practice , 2012, IEEE Software.

[21]  A. Strauss,et al.  Grounded Theory in Practice , 1997 .

[22]  Peng Liang,et al.  A systematic mapping study on technical debt and its management , 2015, J. Syst. Softw..

[23]  Forrest Shull,et al.  A case study on effectively identifying technical debt , 2013, EASE '13.

[24]  Davide Falessi,et al.  Validating and prioritizing quality rules for managing technical debt: An industrial case study , 2015, 2015 IEEE 7th International Workshop on Managing Technical Debt (MTD).

[25]  Lars-Erik Gadde,et al.  Systematic combining: an abductive approach to case research , 2002 .

[26]  Robert L. Nord,et al.  In Search of a Metric for Managing Architectural Technical Debt , 2012, 2012 Joint Working IEEE/IFIP Conference on Software Architecture and European Conference on Software Architecture.

[27]  Elvira-Maria Arvanitou,et al.  Introducing a Ripple Effect Measure: A Theoretical and Empirical Validation , 2015, 2015 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM).

[28]  Jan Bosch,et al.  The Danger of Architectural Technical Debt: Contagious Debt and Vicious Circles , 2015, 2015 12th Working IEEE/IFIP Conference on Software Architecture.

[29]  Carolyn B. Seaman,et al.  A portfolio approach to technical debt management , 2011, MTD '11.