Hauptgedanke

Ein Entwickler, der einen Defekt übernimmt, den er selbst eingeführt hat, repariert nicht nur. Er ist die einzige Person, die vergleichen kann, was er zu liefern glaubte, mit dem, was tatsächlich passiert ist. Er sieht, wo sein Verständnis des Bedarfs unvollständig war, ob der Test fehlte, der den Fall abgefangen hätte, ob die Spezifikation die Mehrdeutigkeit offenließ, die er allein entschieden hat, ob die Architektur den Fehler wahrscheinlich machte.

Ein anderer Entwickler, der an seiner Stelle korrigiert, findet die technische Ursache, nicht die Entscheidungsursache. Er repariert das Symptom, ohne dass die Information dorthin zurückgelangt, wo sie etwas verändert hätte.

Erst dieser Kreislauf — liefern, auf die Folge stoßen, erkennen, was fehlte — bringt die Verbesserung hervor. Er ist keine Nebenwirkung der Korrektur, sondern ihr eigentlicher Wert.

Warum das wichtig ist

Das liefert ein Gestaltungskriterium für Qualitätspolitiken: Eine Politik, die die Korrekturzeit optimiert, ohne zu fragen, wer korrigiert, erkauft Schnelligkeit, indem sie das Lernen abschafft.

Es erklärt auch, warum sich in einem Team dieselben Entwurfsfehler wiederholen. Sie kommen nicht aus mangelnder Kompetenz, sondern aus einem Informationsfluss, der nie zum Urheber zurückführt.

Nuancen und Grenzen

Der Kreislauf schließt sich nur, wenn der Defekt auf seine Ursache zurückgeführt wird und nicht bloß auf seine Codezeile: Wer korrigiert, ohne zu benennen, was vorher gefehlt hat, liefert nur eine Reparatur mehr.

Und er hat eine Frist: Je später der Defekt auftaucht, desto weniger erinnert sich der Urheber daran, was er beim Liefern zu tun glaubte.

Offene Fragen

• Wo hält man fest, was die Korrektur offenlegt — fehlender Test, mehrdeutige Spezifikation, fragile Architektur —, damit es auf die nächste Lieferung wirkt, statt im Kopf dessen zu bleiben, der korrigiert hat?