Technical debt is a burden and an opportunity at the same time. There are many different definitions, but what does technical debt really mean? It seemed to have something to do with the problems we were facing. We have many different large code bases grown over decades, with their difficulties and flaws. Is that all technical debt? How serious is it? How can the non-expert understand the implication of it?
This experience report describes our journey from having only diffuse information, gut feelings of developers about architectural problems, and many project surprises to a transparent way of managing our technical debt and being able to estimate and communicate the consequences of it.
We needed to define the term technical debt in our context and created a management process. We set up a ticket system to categorize, rate, and describe the debt and its implication. Introducing and following that process, we faced various challenges while initially exploring the debt we had already accumulated, understanding the effects on our projects, and finding solutions to decrease it.
See the slides.Watch the video.
