Technical debt – why the term causes more confusion than clarity. And how to do it better.

Konstantin Sokolov and Egon Wuchner give a presentation on the following topic:

Are we software engineers really clear what we mean when we talk about technical debt?

“Sure”, is the answer, “it’s about smells, bugs, need for refactoring, missing tests …”. To some extent, we can even measure their scope and need. But how do we decide what to address first? How and what do we measure so that other stakeholders even understand us and how do we convince product owners, project managers, and department heads of the necessary budget?

In the talk we show how to do it better based on data. How to start with the consequences of technical debt, capture maintenance and increasing overheads in development as KPIs and identify their hotspots in the code. How to identify code quality, architecture quality, test quality, etc. as root causes and correlate them with the KPIs. And how to forecast technical debt in the architecture in numbers in order to perform a cost-benefit analysis. And how team collaboration also impacts Technical Debt. These challenges have been the same for several decades. Microservices have not changed that.

Where an when?

Leave a Reply