In Search of a Metric for Managing Architectural Technical Debt

Practices designed to expedite the delivery of stakeholder value can paradoxically lead to unexpected rework costs that ultimately degrade the flow of value over time. This is especially observable when features are developed based on immediate value, while dependencies that may slow down future development efforts are neglected. The technical debt metaphor conceptualizes this tradeoff between short-term and long-term value: taking shortcuts to optimize the delivery of features in the short term incurs debt, analogous to financial debt, that must be paid off later to optimize long-term success. In this paper, we describe taking an architecture-focused and measurement-based approach to develop a metric that assists in strategically managing technical debt. Such an approach can be used to optimize the cost of development over time while continuing to deliver value to the customer. We demonstrate our approach by describing its application to an ongoing system development effort.

[1]  Meir M. Lehman,et al.  Program evolution: processes of software change , 1985 .

[2]  Robert L. Nord,et al.  Analysis and Management of Architectural Dependencies in Iterative Release Planning , 2011, 2011 Ninth Working IEEE/IFIP Conference on Software Architecture.

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

[4]  Thomas Zimmermann,et al.  Analytics for software development , 2010, FoSER '10.

[5]  Philippe Kruchten,et al.  A conceptual model of disasters encompassing multiple stakeholder domains , 2008 .

[6]  Michael Weiss,et al.  Design Evolution of an Open Source Project Using an Improved Modularity Metric , 2009, OSS.

[7]  Juri Jatskevich,et al.  Dynamic recovery of critical infrastructures: real-time temporal coordination , 2008, Int. J. Crit. Infrastructures.

[8]  Miryung Kim,et al.  Discovering and representing systematic code changes , 2009, 2009 IEEE 31st International Conference on Software Engineering.

[9]  Bikram Sengupta,et al.  Software evolution in agile development: a case study , 2010, SPLASH/OOPSLA Companion.

[10]  Tyson R. Browning,et al.  Managing complex product development projects with design structure matrices and domain mapping matrices , 2007 .

[11]  David Lorge Parnas,et al.  Software aging , 1994, Proceedings of 16th International Conference on Software Engineering.

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

[13]  Alan MacCormack,et al.  Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis , 2011 .

[14]  Judith A. Stafford,et al.  Achieving Agility through Architecture Visibility , 2009, QoSA.

[15]  Cláudio Sant'Anna,et al.  From retrospect to prospect: Assessing modularity and stability from software architecture , 2009, 2009 Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture.

[16]  张吟,et al.  Contact and Friction of One- and Two-Dimensional Nanostructures , 2013 .

[17]  Mike Cohn,et al.  Agile Estimating and Planning , 2005 .

[18]  Jürgen Döllner,et al.  Monitoring code quality and development activity by software maps , 2011, MTD '11.

[19]  Eric Allman,et al.  Managing Technical Debt , 2012, ACM Queue.

[20]  Peri L. Tarr,et al.  An enterprise perspective on technical debt , 2011, MTD '11.

[21]  Philippe Kruchten,et al.  A canonical data model for simulator interoperation in a collaborative system for disaster response simulation , 2011, 2011 24th Canadian Conference on Electrical and Computer Engineering(CCECE).

[22]  W. R. Howard Agile Project Management: Creating Innovative Products , 2010 .

[23]  Chris Sterling,et al.  Managing Software Debt: Building for Inevitable Change , 2010 .

[24]  Forrest Shull,et al.  Building empirical support for automated code smell detection , 2010, ESEM '10.

[25]  Mark T True,et al.  Software Requirements , 2005 .