Complexity, design erosion, decisions - how do you shed light on chaos when things go wrong?

Is it the complexity of the task, the resulting design erosion or is it wrong decisions that lead to problems? Does the complexity lead to early design erosion? Or was the diagnosis wrong, leading to continued difficulty in implementing new features despite design improvement countermeasures? The presentation shows that there can be several possible faults (i.e. causes) for common failures (as symptoms). Failures and possible faults need to be measured as metrics to conclude a good diagnosis and the right countermeasures.

In the talk we will go into some Failure/Faults/Measures chains and show a procedure for managers and developers what and how to measure in order to establish a learning process. Instead of completeness we want to provide examples (based on concrete projects):

How, for example, for a high error density with many follow-up bugs (failures), several potential causes (faults) can come into question: poor code documentation, diffuse developer accountability, or high feature coupling of the corresponding code modules. And how to use measurements to arrive at a diagnosis and possible countermeasures, the effect of which on faults and error density can in turn be measured.

First presented at OOP 2021