Hauptgedanke

„Wer den Bug erzeugt, behebt ihn“ liest man spontan als Bearbeitungsregel: Sie würde festlegen, wer die Korrekturarbeit erledigt. Ihre Hauptwirkung liegt jedoch vor der Korrektur.

Ein Entwickler, der weiß, dass seine Defekte direkt zu ihm zurückkommen, liefert anders. Er testet mehr, er prüft sorgfältiger, er spielt eine fragile Änderung weniger bereitwillig ein, nur um einen Termin zu halten, er lässt sich weniger leicht darauf ein, bei starker Unklarheit zu programmieren. Die Regel ist ein Anreiz, bevor sie eine Zuteilung ist.

Sie garantiert nichts: Auch ein gewissenhafter Entwickler kann einen Defekt erzeugen, und eine Zuteilungsregel ersetzt kein Produktionssystem. Was sie ändert, ist die private Abwägung, die jeder im Moment des Lieferns trifft, wenn niemand hinschaut.

Warum das wichtig ist

Das beantwortet den Kosteneinwand: Die Regel anzuwenden stört die Planung, verlangsamt das nächste Feature, holt jemanden zu einem Thema zurück, das er schon verlassen hat. Diese Kosten sind real, aber sie sind mit dem Strom von Defekten zu vergleichen, den die Regel verringert, nicht nur mit der Korrekturzeit, die sie verschiebt.

Es erklärt auch, warum Ausnahmen teuer sind: Jede Ausnahme verschiebt nicht nur eine Korrektur, sie schwächt den Anreiz für alle künftigen Lieferungen.

Nuancen und Grenzen

Der Anreiz setzt voraus, dass der Entwickler Einfluss auf das hatte, was er lieferte. Steht er unter einer aufgezwungenen Frist oder einer Spezifikation, die er nicht diskutieren durfte, erleidet er die Regel, ohne darauf reagieren zu können — und sie wird zur Strafe.

Sie sagt auch nichts über Defekte aus dem Legacy oder aus mehreren Beiträgen, bei denen kein Urheber erkennbar ist.

Offene Fragen

• Ab welcher Zeitspanne zwischen Lieferung und Auftreten des Defekts hört der Anreiz auf, auf die Art des Lieferns zu wirken?