Who, When, Where?
Egon Wuchner Konstantin Sokolov
What is it about?
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 understand us at all and convince POs, project managers and department heads of the necessary budget?
In this talk, we'll show how to do it better in a data-based way. How to start with the consequences of technical debt, capture maintenance and compounding overheads in development as KPIs and identify their hotspots in 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. Finally, how team collaboration also impacts technical debt.
These challenges have been the same for several decades. Microservices have not changed that.
- Target audience: rchitects, project/technical managers, key developers, managers, decision makers
- Prerequisites: None
- Level: Intermediate
Problems addressed
- What is technical debt more accurately?
- How do you measure the consequences?
- What does an effective root cause analysis look like?
- How do I convince other stakeholders of the need?
- How does team collaboration impact technical debt?