Technische Schuld

Nein. Ein Bug ist falsches Verhalten, technische Schuld ist eine Struktur, die richtiges Verhalten teuer macht. Die Trennlinie verläuft beim Betroffenen: Fällt es dem Anwender auf, ist es ein Fehler; fällt es erst bei der nächsten Änderung auf, ist es Schuld. Praktische Folge für die Abarbeitung: Ein Fehler hat einen Termin, eine Schuld hat einen Zinssatz. Wer beides in dieselbe Liste schreibt, verliert die Dringlichkeit des einen und die Begründung des anderen.

Nein, nur bei Änderung. Martin Fowler beschrieb diese Grenze der Kreditmetapher im Oktober 2009: Ein Teil, den niemand anfasst, verursacht keinen Aufwand, auch wenn er schlecht gebaut ist. Sein Rechenbeispiel: Eine Funktion dauert in schlechter Struktur sechs statt vier Tage, also zwei Tage Zins; fünf Tage Aufräumen lohnen erst, wenn dort zwei bis drei vergleichbare Änderungen folgen. Ein Bericht, der die gesamte Schuld einer Anwendung summiert, überschätzt deshalb den wirklichen Aufwand.

Nur als Schätzung mit einer offengelegten Annahme. Die verbreitete Rechnung stammt aus der Dokumentation eines Analysewerkzeugs: Behebungsaufwand geteilt durch die veranschlagte Entwicklungszeit je Codezeile mal Zeilenzahl. Diese Zeit ist dort auf 30 Minuten voreingestellt und frei änderbar. Im Beispiel ergeben 122.563 Minuten Aufwand bei 63.987 Zeilen eine Quote von 6,4 Prozent; die Skala reicht von A bei höchstens 5 Prozent bis E ab 50 Prozent. Weil die 30 Minuten gesetzt und nicht gemessen sind, sind nur Quoten derselben Einstellung vergleichbar.

Nein, es findet nur, was sich als Regelverstoß formulieren lässt – Duplikate, Verschachtelungstiefe, ungenutzte Teile, veraltete Abhängigkeiten. Die Norm ISO/IEC 5055 bündelt dafür vier messbare Merkmale: Sicherheit, Zuverlässigkeit, Leistungsfähigkeit und Wartbarkeit. Ein falsch gezogener Schnitt zwischen zwei Bausteinen verstößt gegen keine Regel und erscheint in keiner Liste, obwohl er teurer ist als jedes Duplikat. Der Bericht eines Werkzeugs ist deshalb die Untergrenze des Betrags, nie der Betrag.

Im Mittel um 124 Prozent, im Ausreißer bis zum Neunfachen. Eine Untersuchung von März 2022 wertete 39 Produktions-Codebasen mit 30.737 Dateien aus: Arbeiten an Code niedriger Qualität brauchten durchschnittlich 124 Prozent länger, die längste gemessene Durchlaufzeit lag neunmal höher. Die Qualitätsstufen stammen aus dem Analysewerkzeug der Autoren, sind also keine neutrale Messung. Für einen Termin bleibt die Streuung das Problem, nicht der Mittelwert.