YAGNI steht für „You Aren’t Gonna Need It“ — du wirst es nicht brauchen. Das YAGNI-Prinzip in der Softwareentwicklung besagt: Eine Funktion wird erst gebaut, wenn sie tatsächlich gebraucht wird, nicht weil jemand vermutet, dass sie später einmal nützlich sein könnte. Es stammt aus dem Extreme Programming und soll Code klein, verständlich und änderbar halten.
Woher YAGNI kommt
Der Begriff entstand Ende der 1990er im Umfeld von Extreme Programming (XP) — einer agilen Vorgehensweise, die auf kurze Entwicklungszyklen, Tests und ständiges Umbauen des Codes setzt. Kent Beck und Chet Hendrickson beobachteten im Chrysler-C3-Projekt, dass praktisch jede vorsorglich eingeplante Zukunftsfunktion am Ende doch nicht gebraucht wurde.
Ron Jeffries, einer der XP-Mitbegründer, hat die Regel in einem Satz zusammengefasst: „Always implement things when you actually need them, never when you just foresee that you [will] need them.“ — Baue Dinge, wenn du sie wirklich brauchst, nie, wenn du nur ahnst, dass du sie brauchen wirst. Nachzulesen ist das im Buch Extreme Programming Installed von Jeffries, Anderson und Hendrickson.
Im deutschsprachigen Raum taucht YAGNI heute meist im selben Atemzug mit Clean Code auf — also der Idee, Code so zu schreiben, dass ihn ein anderer Mensch in einem halben Jahr noch versteht.
Anzeige
Ein Beispiel: die Exportfunktion, die niemand wollte
Ein Team bekommt die Anforderung: „Die Kundenliste soll sich als CSV-Datei herunterladen lassen.“ Zwei Wege:
- Ohne YAGNI: Es entsteht ein generischer ExportService mit Plugin-Struktur, Format-Registry und vorbereiteten Klassen für XLSX, JSON und PDF — „brauchen wir bestimmt irgendwann“. Ergebnis: mehrere hundert Zeilen Code, eine Konfigurationsdatei und drei Formate, die nie jemand aufruft.
- Mit YAGNI: Es entsteht eine Funktion, die genau eine CSV-Datei erzeugt. Kommt später wirklich die Anforderung „auch als Excel“, wird an dieser Stelle umgebaut — mit dem Wissen, wie das Excel-Format aussehen soll, statt mit einer Vermutung von vor zwei Jahren.
Mein eigenes Backup-Skript für den Heimserver hatte anfangs drei Ziele: NAS, USB-Platte und Cloud. Genutzt habe ich nie mehr als eines. Die beiden anderen Zweige habe ich bei jedem Umbau trotzdem mitgetestet, mitdokumentiert und mitrepariert — bis ich sie irgendwann gelöscht habe. Genau dieses Mitschleppen meint YAGNI.
Die vier Kosten überflüssiger Funktionen
Martin Fowler hat 2015 aufgeschrieben, warum vorsorgliche Funktionen (er nennt sie „presumptive features“) teuer sind. Das YAGNI-Prinzip in der Softwareentwicklung argumentiert nämlich nicht ästhetisch, sondern wirtschaftlich:
- Kosten des Bauens: Analyse, Programmierung und Tests für etwas, das nie jemand benutzt.
- Kosten der Verzögerung: Solange am Vorrats-Feature gearbeitet wird, wartet das Feature, das heute Geld oder Nerven spart.
- Kosten des Mitschleppens: Jede zusätzliche Abstraktion macht den Code größer und schwerer verständlich — und bremst damit jede spätere Änderung, auch an ganz anderen Stellen.
- Kosten der Reparatur: Kommt die Anforderung doch, passt die alte Vorbereitung meist nicht genau. Dann wird der ungenutzte Code erst verstanden, dann umgebaut — teurer, als ihn nie geschrieben zu haben.
Der unangenehme Teil: Die ersten beiden Kosten fallen sofort an, die letzten beiden merkt man erst Monate später. Deshalb fühlt sich Vorbauen im Moment produktiv an.
Wann das YAGNI-Prinzip in der Softwareentwicklung nicht gilt
YAGNI ist keine Erlaubnis, schlampig zu arbeiten. Fowler grenzt es klar ein: Es gilt für vermutete Fachfunktionen — nicht für Aufwand, der Software leichter änderbar macht. Diese vier Ausnahmen solltest du kennen:
- Änderbarkeit selbst: automatisierte Tests, Refactoring (das Umbauen von Code ohne Verhaltensänderung), saubere Modulgrenzen, Continuous Integration. Ohne dieses Netz wird Weglassen zum Bumerang.
- Sicherheit und Datenschutz: Authentifizierung, Rechtevergabe, Verschlüsselung, Logging und Backups sind keine Features „für später“. Sie nachzurüsten ist deutlich teurer als sie einzuplanen.
- Schwer umkehrbare Entscheidungen: Datenmodell, Zeichenkodierung, Zeitzonen-Handling, öffentliche Schnittstellen-Verträge. Eine Funktion löscht man in fünf Minuten, eine falsch modellierte Tabelle mit zwei Millionen Datensätzen nicht.
- Bekannte, terminierte Anforderungen: Steht die zweite Sprache im Vertrag und startet in sechs Wochen, ist das keine Vermutung, sondern Planung.
Faustregel: Alles, was du später ohne Datenverlust umbauen kannst, darfst du weglassen. Alles, was dich hinterher zu einer Migration zwingt, denkst du vorher zu Ende.
YAGNI, KISS und DRY — was ist der Unterschied?
Die drei Prinzipien werden in Prüfungsfragen gern durcheinandergeworfen, obwohl sie auf verschiedene Fragen antworten:
| Prinzip | Frage, die es beantwortet | Typischer Fehler ohne das Prinzip |
|---|---|---|
| YAGNI | Soll ich das jetzt überhaupt bauen? | Overengineering: Vorrats-Features und Abstraktionen auf Verdacht |
| KISS (Keep It Simple, Stupid) | Wie einfach darf die Lösung sein? | Unnötig komplizierte Konstruktionen für ein einfaches Problem |
| DRY (Don’t Repeat Yourself) | Wo steht dieses Wissen genau einmal? | Copy-Paste-Code, der an drei Stellen gefixt werden muss |
Sie können sich auch widersprechen: Wer DRY zu früh anwendet, baut eine gemeinsame Funktion für zwei Fälle, die sich später auseinanderentwickeln — und landet bei genau der Komplexität, die YAGNI verhindern wollte. Zweimal derselbe Code ist oft günstiger als eine falsche Verallgemeinerung.
So wendest du YAGNI im Alltag an
- Frag bei jeder Zusatzfunktion: Wer braucht das in dieser Woche? Gibt es keinen konkreten Nutzer und keine konkrete Anforderung, wird sie nicht gebaut.
- Schreib die Idee ins Backlog oder Ticket-System statt in den Code. Ideen kosten dort nichts, Code schon.
- Bau die einfachste Variante, die funktionieren kann („do the simplest thing that could possibly work“) — inklusive Test.
- Wird die Erweiterung wirklich gebraucht, refaktoriere an dieser Stelle. Das Sicherheitsnetz aus Tests ist die Bedingung dafür, nicht die Kür.
- Räum rückwirkend auf: ungenutzte Parameter, tote Konfigurationsschalter und leere Interface-Implementierungen dürfen weg. Die Versionsverwaltung erinnert sich für dich.
Das YAGNI-Prinzip in der Softwareentwicklung ist damit kein Verbot des Nachdenkens, sondern eine Verschiebung: Du denkst über die Struktur nach, die Änderungen billig macht — und nicht über Funktionen, die vielleicht nie jemand anfordert.
Warum YAGNI ohne Tests zum Bumerang wird
YAGNI funktioniert nur zusammen mit den anderen XP-Praktiken: automatisierte Unit-Tests, ständiges Refactoring und Continuous Integration, also das häufige Zusammenführen und automatische Prüfen aller Änderungen. Fehlt dieses Fundament, traut sich niemand mehr, bestehenden Code umzubauen — und dann wird aus „bauen wir später“ ein Berg technischer Schulden, der irgendwann nur noch mit einer Neuentwicklung abzutragen ist. Fowler formuliert es so: Ohne änderbaren Code wird YAGNI vom Segen zum Fluch.
Häufige Fragen
Wofür steht die Abkürzung YAGNI?
YAGNI steht für „You Aren’t Gonna Need It“, also „Du wirst es nicht brauchen“. Der Begriff stammt aus dem Extreme Programming und bedeutet: Funktionen erst implementieren, wenn sie tatsächlich benötigt werden.
Widerspricht YAGNI dem Prinzip DRY?
Nein, beide antworten auf verschiedene Fragen — sie können sich aber reiben. Wer DRY zu früh anwendet, verallgemeinert zwei Fälle, die sich später trennen. Doppelter Code ist oft billiger als eine falsche Abstraktion.
Gilt YAGNI auch für Sicherheit und Backups?
Nein. Authentifizierung, Rechtevergabe, Verschlüsselung und Backups sind keine Vorrats-Features, sondern Grundlagen. Sie nachträglich einzubauen kostet meist deutlich mehr als sie von Anfang an mitzudenken.
Welche vier Kosten verursachen vorsorgliche Features?
Martin Fowler nennt Kosten des Bauens, Kosten der Verzögerung, Kosten des Mitschleppens und Kosten der Reparatur. Die ersten beiden fallen sofort an, die anderen zwei zeigen sich erst Monate später.
Warum braucht YAGNI automatisierte Tests?
Weil später umgebaut wird, statt vorzubauen. Ohne Unit-Tests, Refactoring und Continuous Integration traut sich niemand an bestehenden Code — dann bleibt Weggelassenes für immer liegen und wird zur technischen Schuld.
