The technical debt metaphor acknowledges that development teams
sometimes accept compromises in a system in one dimension (for example,
modularity) to meet an urgent demand in some other dimension (for
example, a deadline), and that such compromises incur a “debt.” If not
properly managed, the interest on this debt may continue to accrue,
severely hampering system stability and quality and impacting the team’s
ability to deliver enhancements at a pace that satisfies business
Although unmanaged debt can have disastrous results, strategically managed debt can help businesses and organizations take advantage of time-sensitive opportunities, fulfill market needs, and acquire stakeholder feedback. Because architecture has such leverage within the overall development lifecycle, strategic management of architectural debt is of primary importance.
During this session, we will discuss the technical debt metaphor and learn about techniques for measuring and communicating technical debt. We’ll compare strategies and share practices to help make these choices. We will conclude by raising awareness of efforts to move beyond the metaphor and provide software engineers a foundation for managing tradeoffs based on models of their economic impacts.