As industry and government customers demand increasingly rapid innovation and the ability to adapt products and systems to emerging needs, the time frames for releasing new software capabilities continue to shorten. Likewise, Agile software development processes, with their emphasis on releasing new software capabilities rapidly, are increasing in popularity beyond their initial small team and project context. Practices intended to speed up the delivery of value to users, however, often result in high rework costs that ultimately offset the benefits of faster delivery, especially when good engineering practices are forgotten along the way. This rework and degrading quality often is referred to as technical debt. This post describes our research on improving the overall value delivered to users by strategically managing technical debt, which involves decisions made to defer necessary work during the planning or execution of a software project.

The technical debt metaphor was coined by Ward Cunningham to explain the need for software refactoring, which is a disciplined way to restructure code to improve some properties of the software. A little technical debt, in the form of development or testing short cuts, speeds up product delivery, just as borrowing money speeds up purchases. Just as too much monetary debt can eventually drive you into bankruptcy, however, too much technical debt can eventually impede the quality and functionality of your software. In particular, every minute spent managing not-quite-right code counts as interest on the technical debt that should be paid off (e.g., via refactoring or rewriting) to ensure long-term success. If left unmanaged, technical debt can cause significant functional and financial problems that increase software evolution costs.

The SEI works with many organizations that have large, multi-year, mission- and safety-critical projects. These projects typically have a range of quality attribute requirements, including low-latency, high availability, resilient security, and rapid modifiability. Organizations that focus their software development predominantly on customer-facing capabilities--which is a common theme in conventional Agile projects--often postpone addressing these requirements, which can increase technical debt.

For example, through our work on architecture-centric engineering, we often encounter projects that defer modifiability requirements, specifically portability. This delay enables organizations to deliver software products to customers quickly by initially developing them for a single operating system, such as Windows, and form factor, such as desktops. As the projects progress, however, customers may motivate ports of their software to other operating systems, such as Linux or Mac OSX, or to environments with different form factors, such as mobile handheld devices. There are clearly trade-offs between shipping software quickly (e.g., to gain initial market share) and ensuring the software can be ported quickly to other platforms (e.g., to increase subsequent market share). Shipping software quickly may require foregoing designing for portability as a form of technical debt. When the need to port to other operating systems or form factors arises, this debt should be paid back in the form of redesigning all or parts of the system.

To systematically address the trade-offs outlined above, our research focuses on providing software engineers an analysis and measurement framework for managing technical debt from a strategic and architectural perspective. Thus far, we developed a release planning framework that clarifies how to integrate architectural concerns with Agile project management methods, such as Scrum. This framework allows users to relate functional requirements, often referred to as "stories" in Agile development, with architectural decisions. Some common architectural decisions involve deciding how the system will be decomposed into subsystems, resolving the elements that will be responsible for common functionality, and picking major patterns that define the structure of the system. Individual stories cannot be regarded in isolation, however, since they depend on other stories and architectural elements, which we model with a release-planning focus. Understanding these dependencies also allows the development team to make informed decisions about architectural technical debt.

Our current work focuses on architectural technical debt, which involves architectural decisions made to defer necessary work during the planning or execution of a software project, such as short-cuts taken in designing the structure of the system that may require rework. An important aspect of our work is that such short-cuts may degrade code quality, and thus require different methods to monitor and manage. We are particularly interested in identifying the measurable aspects of architectural technical debt by exploring dependency analysis. For example, when should an organization consider rearchitecting and refactoring to avoid developing a system that becomes hard to maintain or extend? Likewise, when should an architecture enable the incurrence of additional technical debt to optimize delivery?

To enhance scalability and automation, a key theme of our research is its focus on metrics that can be extracted from the code and module structures of a software system and used to provide insights into architectural dependencies that impact system-wide architectural rework. Analyzing these dependencies involves inspecting code units and understanding how they relate to the architecture. Many tools (such as Coverity, Understand, Lattix, and SonarJ) can extract metrics from code, including coupling (the degree to which software elements depend on each other) and cohesion (a measure of how strongly-related the responsibilities of a single element are).

The insights provided by these metrics are particularly important to avoid developing capabilities based on immediate value, while neglecting dependencies that may impede future development efforts. We are specifically investigating propagation costs, which quantify how changes ripple through the software of the overall system. State-of-the-art dependency analysis tools analyze the code itself, which limits their applicability to later phrases of the software lifecycle. In contrast, our research is determining which insights can be gained when architecture and capability dependencies are examined earlier in the software lifecycle, instead of waiting until after implementation begins.

As part of this research project, I and my colleagues in the Research, Technology, and System Solutions program--Robert Nord and Nanette Brown--are working with Dr. Philippe Kruchten, professor of software engineering in the Department of Electrical and Computer Engineering of the University of British Columbia who is active within agile development communities, and Raghu Sangwan, an associate professor of software engineering at Penn State University whose research and teaching involves analysis, design, and development of software-intensive systems, and Don O'Connell, technical fellow of software architecture at the Boeing Company. We also plan to partner with other organizations on this initiative. For example, we have conducted a workshop with eight leading research organizations and universities working in areas related to technical debt research to share early results and identify key gaps in the research. The workshop resulted in a joint position statement that underscored the importance of further work on developing quantitative models to appropriately manage technical debt as a part of the future research agenda for software engineering.

By the end of this project, we will produce a model for managing technical debt that will allow the incurrence of some debt to increase delivery tempo when needed, but prevent too much accumulation, which would impede the ability to deliver. This model will offer software engineers a sound, quantifiable technique for adjusting course on the amount of debt to carry (and the amount of architecting to pay it off) to optimize return on investment beyond what exists today. My colleagues and I will be blogging about the progress of this project throughout the year and look forward to hearing your comments on our work.

Additional Resources:

For more information on this, please visit the following websites

http://saturnnetwork.wordpress.com/2009/11/12/from-the-trenches-communicating-the-value-of-architecting-within-agile-development/

www.crosstalkonline.org/storage/issue-archives/2010/201011/201011-Brown.pdf
SEI Report: Considerations for Using Agile in DoD Acquisition
www.sei.cmu.edu/library/abstracts/reports/10tn002.cfm

Technical Debt Workshop
www.sei.cmu.edu/community/td2011/