"Qualitätsinvestition statt technischer Schulden"

Martin hat mich auf den sehr interessanten, bei Heise Developer veröffentlichten Artikel Qualitätsinvention statt technischer Schulden aufmerksam gemacht.

Die Metapher der Qualitätsinvestition ist wirklich ein Gewinn. Die alleinige Betrachtung der technischen Schulden kommuniziert zwar die Folgen fortwährender Qualitätskompromisse, hilft aber recht wenig bei der Planung zukünftiger Iterationen. Stattdessen hinterlässt sie eher ein Gefühl der Ratlosigkeit ("Oh je, alles so verschuldet hier. Wo sollen wir anfangen aufzuräumen?"). Die weiterführende Gegenüberstellung von Sanierungs- und Nicht-Sanierungskosten (Remedy Cost/RC, Non-Remedy-Cost/NRC) unter Einbezug der Änderungswahrscheinlichkeit (Probability of Change/PC) ist da sehr hilfreich. Es stimmt, manche "Schulden" muss man nie zurückzahlen wenn der entsprechende Code nicht geändert werden muss. Für diese Betrachtung des Return of Invests (ROI) braucht man zusätzlich eine Schätzung der Änderungswahrscheinlichkeit wodurch sich der Fokus wieder zurück auf die Planung richtet. Das ist gut.

Wenn man schon die technischen Schulden mit Unterstützung eines Tools wie SonarQube differenziert und automatisiert ermittelt (bottom-up), scheint auch der Einsatz von CodeQ Invest gegenüber manuellen Schätzungen (meist top-down) sinnvoll.

Dazu ist es widerum hilfreich die Genauigkeiten der entsprechenden Schätzungen abzuwägen. Kennt man die Änderungswahrscheinlichkeiten sehr genau (kleiner Unsicherheitskorridor) ist eine genaue und differenzierte Analyse der Schulden natürlich auch toll. Als Numeriker würde man dann sagen, dass das Problem der Ermittlung der Kosten "gut konditioniert" ist.

Kenn man die Änderungswahrscheinlichkeiten nur so genau dass eine Angabe in T-Shirt-Größen (S,M,L,XL) ausreicht gewinnt man mit einer aufwendigen, differenzierten Analyse bis auf Klassenebene herunter würde nicht besonders viel. Der "ungenauere Faktor" (Änderungswahrscheinlichkeit) dominiert den genaueren Faktor ("technische Schulden") und bestimmt damit die Gesamtgenauigkeit (Nicht-/Sanierungskosten).

Oft wird ja auch andersherum argumentiert: "Ach, eine genaue Schulden-Analyse ist ja so aufwendig. Da lohnt es nicht eine genaue Änderungs-Planung zu machen".
Diese ökonomisch motivierten Rechnungen ändern sich drastisch, wenn sich der Aufwand für differenzierte Schulden-Analysen durch den Einsatz von Tools wie "SonarQube" erheblich reduziert. Dann rechnet es sich auf einmal wieder auch die Änderungsplanung genauer zu machen.

Um dem Argument "Schön, dass wir die genauen Schulden mit SonarQube jetzt so leicht ermitteln können. Aber ach, für die Gesamtplanung hilft das nicht viel, da ja eine differenzierte Änderungsplanung so aufwendig ist" zu begegnen, gilt es auch den Aufwand für detaillierte Schätzungen der Änderungswahrscheinlichkeiten zu reduzieren.

Mit CodeQ Invest wird das Schätzen/Ermitteln der Änderungswahrscheinlichkeiten
zwar nicht einfacher. Abereinfacher. CodeQ Invest unterstützt Einerseits das automatische Schätzen durch Extrapolation aus der SCM Historie (zurzeit nur git). Das entspricht ungefähr dem "Bauchgefühl" das wir als Entwickler nach und nach durch Erfahrung mit dem Projekt erwerben, ist aber objektiver. Andererseits lassen sich manuelle Schätzungen leicht eingeben und anwenden. Beispielsweise kann wegen geplanter Releases recht klar sein welche Komponenten sich definitiv ändern und welche vielleicht indirekt davon betroffen sind (deren Änderungswahrscheinlichkeit kann dann in erster Näherung durch den Kopplungsgrad approximiert werden, der sich automatisch ermitteln lässt.Insgesamt sinkt der Aufwand für das Durchspielen von Szenarien mit verschiedenen Änderungswahrscheinlichkeiten drastisch. Und das hilft enorm bei der Entscheidung ob eine Qualitätsinvestition für eine Komponente hier und jetzt ökonomisch sinnvoll ist.