  Technical Debt, considered by many to be the 'silent killer' of software
projects, has undeniably become part of the everyday vocabulary of software
engineers. We know it compromises the internal quality of a system, either
deliberately or inadvertently. We understand Technical Debt is not all
derogatory, often serving the purpose of expediency. But, it is associated with
a clear risk, especially for large and complex systems with extended service
life: if we do not properly manage Technical Debt, it threatens to "bankrupt"
those systems. Software engineers and organizations that develop
software-intensive systems are facing an increasingly more dire future state of
those systems if they do not start incorporating Technical Debt management into
their day to day practice. But how? What have the wins and losses of the past
decade of research and practice in managing Technical Debt taught us and where
should we focus next? In this paper, we examine the state of the art in both
industry and research communities in managing Technical Debt; we subsequently
distill the gaps in industrial practice and the research shortcomings, and
synthesize them to define and articulate a vision for what Technical Debt
management looks like five years hence.
