Delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of short-term expedients. The technical debt metaphor is gaining significant traction in the software development community as a way to understand and communicate such issues. The power of the metaphor is that it communicates well the essence of the tradeoffs that are at the core of many software engineering decisions–balancing economic outcomes while continuing to meet business and user needs. The downside, however, is that the more the metaphor resonates the more there is need to understand the quantifiable and scientific principles to avoid confusion. In addition, today the metaphor is used not only to refer to suboptimal coding and refactoring practices as it was originally used by Ward Cunningham, but also to describe issues observed during different software development activities: requirements debt, testing debt, and architectural debt to name a few.
As part of our Communicating the Value of Architecting within Agile Development project, we have been working on technical debt from the perspective of strategic architecture-related technical debt with Philippe Kruchten and Erin Lim from the University of British Columbia. Philippe summarizes some of our outputs here.
In addition, on May 23, 2011 we will be organizing a workshop co-located with the International Conference on Software Engineering (ICSE 2011) in Hawaii to scrutinize the diverse issues that are related to technical debt and the software development lifecycle. The details of the call for papers and other logistics are at our workshop site. We invite practitioners and researchers to join us in discussing early findings, future directions, experiences, and results.
– Ipek Ozkaya, SEI