Ich hatte einen Chef, der von „You Ain’t Gonna Need It“ überhaupt nichts hielt. Sein Argument war einfach und klang auf den ersten Blick vernünftig: Eine Funktion soll nur einmal angefasst werden. Also soll sie beim ersten Mal vollständig ausspezifiziert und vollständig implementiert werden. Kein Nacharbeiten, kein Nachliefern, kein „das kommt später“. Keine Verteilung von Funktionalitäten auf verschiedene Sprints.

Ich war dagegen. Damals schon. Aber am Ende setzt sich ein Chef durch, und so haben wir gebaut, was er wollte: vollständige CRUD-Implementierungen, bevor klar war, ob jede Operation auch gebraucht wird. Create, read, update, delete, alles da, alles fertig, niemand fragt, ob jemand das delete jemals anfasst.

Das Ergebnis war Code, der existierte, ohne je aufgerufen zu werden. Code, der getestet werden musste, gewartet werden musste, mitgeschleppt werden musste. Code, der auf dem Papier vollständig war und in der Praxis überflüssig.

Ich habe diese Haltung nie übernommen.

Was gerade passiert ist

Ich arbeite zur Zeit an einer Webanwendung mit einem News-Bereich. Die Idee: News entstehen automatisch aus dem Kontext. Eine Aktion findet statt, im Hintergrund wird ausgewertet, ob das eine Meldung wert ist, und wenn ja, wird sie erstellt. Das war die erste Anforderung. Die KI hat sie umgesetzt. Fertig.

Später hat sich gezeigt, dass es manchmal sinnvoll ist, eine News anzupassen. Neuer Use Case, vorher nicht absehbar. Ich habe ein Issue geschrieben, die KI hat es in fünf Minuten implementiert, und es wurde deployed.

Der ursprüngliche Plan sah vor, News in einem Ringpuffer zu verwalten: immer zehn Einträge, der elfte verdrängt den ersten. Kein explizites Löschen, weil das nicht gebraucht wurde.

Im Betrieb hat sich herausgestellt, dass manuelles Löschen doch sinnvoll wäre. Also ein weiteres Issue. Wieder fünf Minuten. Wieder deployed.

Drei separate Schritte. Drei Implementierungen. Keine davon verschwendet.

Hätte ich von Anfang an vollständiges CRUD gebaut, wäre Delete von Tag eins dabei gewesen. Vielleicht hätte ich es nie gebraucht. Vielleicht wäre der Ringpuffer ausreichend gewesen. Ich hätte Code geschrieben, der auf dem Papier vollständig war und in der Praxis womöglich nie aufgerufen wurde.

Warum das jetzt anders wirkt

YAGNI ist kein neues Prinzip. Es ist seit Jahrzehnten Teil des XP-Kanons und trotzdem in vielen Teams nicht durchsetzbar, weil das Argument dagegen immer dasselbe war: Nacharbeiten kostet. Wer eine Funktion zweimal anfasst, verbraucht mehr Zeit als jemand, der es gleich richtig macht.

Das stimmte, solange Implementierung teuer war.

Mit KI im Entwicklungsprozess verschiebt sich dieses Verhältnis. Ich habe das in „KI entwickelt jetzt auch Anforderungen“ beschrieben: Das Bottleneck liegt nicht mehr im Schreiben von Code. Ein Feature, das früher zwei Tage Einarbeitung gekostet hätte, ist heute an einem Nachmittag implementierbar. Das ist kein quantitativer Unterschied. Es ist ein qualitativer.

Wer heute trotzdem alles vorausimplementiert, bezahlt denselben Preis wie früher, nur ohne die Rechtfertigung dafür.

Ich schreibe ein Issue, wenn ich etwas brauche. Die KI setzt es um. Wenn ich es später nicht brauche, habe ich es auch nicht gebaut. Wenn ich es doch brauche, baue ich es dann. Die Kosten dafür sind so niedrig, dass das Argument meines ehemaligen Chefs schlicht nicht mehr gilt.

Glücklicherweise bin ich jetzt mein eigener Chef.