As software developers, my team and I were repeatedly in the situation of fighting for more quality and less feature pressure. In doing so, we often achieved concessions, but often the time we were given was insufficient and the result correspondingly unsatisfactory. If I am honest, we ourselves were not in a position to say exactly how bad the quality actually was.
Moreover, I have noticed time and again that developers, users and managers of software have fundamentally different priorities when it comes to quality. Developers often think about internal aspects like code quality and maintainability, users think about external features like bugs and usability, and managers need predictability and efficiency in the development process.
Of course, there are various metrics that try to measure the quality(s) of software, but these often only refer to very small sub-aspects and have more or less harmful side-effects.

In my talk I would like to point out the side effects of quality measurements and show a method for finding metrics that work better. I will point out weaknesses of single classical quality metrics and suggest better suited alternatives. In the end, this results in a network in which each metric is justified by a clear goal and a concrete question and in which weaknesses are mutually balanced.