Abstract
The technical debt metaphor acknowledges that software 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 needs. 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 life cycle, strategic management of architectural debt is of primary importance. Some aspects of technical debt–but not all technical debt– affect product quality. This tutorial introduces the technical debt metaphor and the techniques for measuring and communicating this technical debt, integrating it fully with the software development lifecycle.)
Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
