Die teuerste Zeile Code ist die, die man zweimal schreibt

Ein Entwickler bekommt eine Aufgabe. Er versteht sie, öffnet die Datei, die ihm am naheliegendsten erscheint, und beginnt zu schreiben. Zwei Tage später steht das Feature. Es funktioniert. Der Pull Request ist grün.

Drei Wochen später stellt jemand fest, dass es dieselbe Funktion schon gab — in einem anderen Service, leicht anders benannt, von einem anderen Kollegen geschrieben. Jetzt existiert die Logik zweimal. Sie wird zweimal gepflegt. Sie driftet auseinander. Irgendwann verhalten sich beide Varianten unterschiedlich, und niemand weiß mehr, welche die richtige ist.

Das ist kein seltener Unfall. Das ist der Normalfall in jedem Team, das ohne Discovery-Disziplin arbeitet.

Was ist Discovery-First?

Discovery-First ist die Disziplin, vor der ersten Codezeile fünf Fragen schriftlich zu beantworten: Gibt es eine Lösung schon? Wo wäre der richtige Ort dafür? Welches Muster passt? Welcher Test deckt Ähnliches ab? Was bricht, wenn das hier wächst? Erst wenn diese Fragen geklärt sind, wird Code geschrieben.

Das kostet eine halbe Stunde. Manchmal weniger. Diese halbe Stunde fühlt sich nach Verzögerung an — man könnte doch schon tippen. Genau dieses Gefühl ist die Falle. Es bewertet sichtbare Aktivität höher als unsichtbare Vermeidung.

Die Rechnung ist aber eindeutig. Eine doppelt geschriebene Funktion kostet nicht nur die zweite Implementierung. Sie kostet jeden zukünftigen Bugfix doppelt, jede Anpassung doppelt, und irgendwann einen Tag Detektivarbeit, um herauszufinden, warum sich zwei vermeintlich gleiche Codepfade unterschiedlich verhalten. Gegen all das ist eine halbe Stunde Recherche der günstigste Preis, den man je zahlen wird.

Warum Discovery-First die erste Hälfte von DRY ist

DRY — Don’t Repeat Yourself — wird meist als Konsolidierungs-Regel verstanden: wenn du Duplikate siehst, fasse sie zusammen. Das ist die zweite Hälfte. Die erste Hälfte ist, das Duplikat gar nicht erst entstehen zu lassen.

Und hier wird es interessant, sobald KI-Assistenz im Spiel ist. Ein Sprachmodell, das eine Aufgabe bekommt, schreibt mit größter Selbstverständlichkeit eine neue Funktion. Es hat keinen Reflex, vorher das Repository abzusuchen — es sei denn, man baut ihm diesen Reflex ein. Wer LLM-gestützt entwickelt, ohne Discovery-First explizit zu verankern, bekommt Duplikate nicht trotz, sondern wegen der höheren Geschwindigkeit. Das Werkzeug produziert schneller — auch die Fehler.

Wie verankert man Discovery-First im Team?

Disziplin, die nur in einem Wiki steht, ist keine Disziplin. Drei Maßnahmen machen Discovery-First real, und keine davon ist aufwendig:

• Ein fester Pre-Code-Check. Fünf Fragen, schriftlich beantwortet, bevor die erste Datei angelegt wird. Bei neuen Mandaten setze ich das als Pflichtschritt im Plan-Dokument auf — nicht als Empfehlung.
• Begründungspflicht bei neuen Dateien. Jede neue Datei — Service, Komponente, Hilfsmodul — bekommt einen Satz: warum wurde das nicht in eine bestehende Datei ergänzt? Wer diesen Satz nicht schreiben kann, hat die Discovery nicht gemacht.
• Ein Gate, das Duplikate sichtbar macht. Manche Duplikate lassen sich mechanisch finden. Ein einfacher Check vor dem Push, der auf verdächtige Ähnlichkeiten hinweist, fängt mehr ab, als man glaubt.

Alle drei zusammen verschieben die Kultur von „erst tippen” zu „erst nachsehen”.

Bremst Discovery-First nicht aus?

Der häufigste Einwand lautet: Discovery-First bremst, und in einem schnellen Team kann man sich das nicht leisten. Das Gegenteil stimmt. Ein Team ist nicht schnell, weil es viel Code produziert. Es ist schnell, weil es wenig Code zweimal anfassen muss.

Jede Stunde, die in das Verstehen des Bestehenden fließt, spart ein Vielfaches an Stunden, die sonst in das Entwirren von dessen Folgen fließen würde. Wer wirklich schnell sein will, fragt zuerst.

Die teuerste Zeile Code ist nicht die schwierige. Es ist die, die schon existiert hat.