Software Engineering Institute

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 as a way to understand and communicate these issues. Often when a particular symptom in a system is described as technical debt, it's not just the code quality that is bad, but it's also accumulating problems that happen in terms of architectural changes that have occurred throughout the system's development. We see increasing industry interest and the emergence of related practices in an effort to handle maintainability, degrading quality, and strategic time-to market tradeoffs that the technical debt metaphor reifies.

• Philippe Kruchten, Robert Nord, Ipek Ozkaya. Managing Technical Debt: Reducing Friction in Software Development (book)
• SEI Cyber Minute: Representing Your Technical Debt (video)
• Interviews with key practitioners on technical debt: Jeromy Carriere, Michael Feathers, Steve McConnell, and Carolyn Seaman.
• Philippe Kruchten, Robert L. Nord, Ipek Ozkaya. "Technical Debt: From Metaphor to Theory and Practice." IEEE Software, Nov./Dec., 2012.
• The educational "Hard Choices Board Game" communicates the concepts of uncertainty, risk, options, and technical debt.

Highlight: "Managing the Consequences of Technical Debt: 5 Stories from the Field"

http://blog.sei.cmu.edu/archives.cfm/category/technical-debt

Industry and government stakeholders continue to demand increasingly rapid innovation and the ability to adjust products and systems to emerging needs. Amidst all the enthusiasm towards meeting these needs, the critical role of the underlying architecture is often overlooked. These articles focus on the architecture principles and practices that support rapid delivery while managing technical debt.

Find more resources on this topic in the collection below.

The SEI focuses on managing debt as an agile software architecture strategy. Specifically, SEI researchers are focusing on identifying any implications to the cost of architectural changes. Architectural technical debt is a design or construction approach that's expedient in the short term, but that creates a technical context in which the same work requires architectural rework and costs more to do later than it would cost to do now (including increased cost over time). A unifying perspective is emerging of technical debt as the invisible results of past decisions about software that affect its future. The effect can be negative in the form of poorly managed risks, but if properly managed can be seen in a positive light to add value in the form of deferred investment opportunities. A gap in the existing approaches and tools is a way to extract architectural metrics that can assist understanding the accumulating rework and degrading quality.

Find more resources on this topic in the collection below.