Wir arbeiten nach einem einfachen Grundsatz. Eine Funktion entsteht bei uns erst, wenn klar ist, dass sie jetzt gebraucht wird. Was vielleicht irgendwann nützlich sein könnte, belassen wir im Backlog, bis aus dem Vielleicht ein echter Bedarf geworden ist. In der Softwareentwicklung trägt diese Haltung einen Namen: YAGNI.
Was YAGNI bedeutet und weshalb Vorratsdenken bei Softwareprojekten schadet
YAGNI steht für „You Aren’t Gonna Need It“, auf Deutsch ungefähr „Du wirst es nicht brauchen“. Genau so ist der Grundsatz auch gemeint.
Das klingt beinahe zu schlicht, um einen eigenen Namen zu verdienen. Trotzdem braucht es einen. Etwas auf Vorrat anzulegen wirkt vorausschauend und in vielen Lebensbereichen ist es das auch. Bei Softwareprojekten sehen wir das anders. Warum, das ist der Kern dieses Textes.
Je leichter die Umsetzung wird, desto wichtiger ist Zurückhaltung
Weniger zu bauen sieht im ersten Moment nach weniger Gegenwert aus. Für uns ist es das Gegenteil. Zurückhaltung beim Bauen schützt genau das, wofür Sie bezahlen, nämlich verlässliche Software, die wartbar bleibt.
Trotzdem fällt uns diese Zurückhaltung nicht von selbst zu. Der Reiz, eine Funktion noch einzubauen, weil sie sich gerade anbietet und so naheliegend wirkt, ist für uns auch nach fast zwei Jahrzehnten nicht kleiner geworden. Im Gegenteil: Heute ist dieser Reiz größer denn je, weil moderne KI-Werkzeuge zur Softwareentwicklung, etwa Claude Code von Anthropic, GitHub Copilot oder Codex von OpenAI, die Schwelle zur Umsetzung drastisch senken. Eine Funktion ist schneller gebaut als je zuvor und das macht die Versuchung, sie „eben noch schnell mitzunehmen“, immens. Diesen Sog spüren wir bei fast jedem Projekt aufs Neue. Wir halten also an unserer Disziplin nicht deshalb fest, weil sie uns leichtfällt. Wir halten daran fest, weil wir die Versuchung selbst bestens kennen und wissen, wohin sie führt.
Nicht jeder Preis erscheint auf der Rechnung
Eine neue Funktion kostet zuerst bei der Entstehung. Sie muss durchdacht, umgesetzt und getestet werden, bevor sie ein einziges Mal etwas Nützliches tut. Dieser Posten steht am Ende auf der Rechnung, er ist sichtbar und mit ihm rechnet jeder.
Daneben steht jedoch ein zweiter Posten, den die Rechnung nicht zeigt, nämlich die Opportunitätskosten. Das ist das, was Sie nicht bekommen, weil Ihre Mittel anderswo gebunden sind. Dieselbe Woche etwa, die in eine auf Verdacht gebaute Funktion fließt, hätte für eine Funktion genutzt werden können, auf die Ihre Nutzer wirklich warten. Beides hat einen realen Preis. Dass nur der erste davon auf einer Rechnung auftaucht, macht den zweiten nicht kleiner.
Bauen kostet einmal, Pflegen dauerhaft
Der teuerste Teil kommt erst nach der Auslieferung. Jede Funktion, die einmal im Produkt steckt, will gepflegt, aktuell gehalten und bei jeder Änderung mitbedacht werden. Diese Last ist also bei jeder Weiterentwicklung erneut zu schultern. Das gilt auch dann, wenn diese Funktion eigentlich niemand benutzt.
Deshalb ist dieser Posten der teuerste von allen. Die Umsetzung kostet einmal, die anschließende Pflege kostet dauerhaft. Mit jeder weiteren Funktion steigt der Wartungsaufwand. Nicht weil eine einzelne Funktion besonders aufwändig wäre, sondern weil eine immer längere Liste von Funktionen in ihrer Summe jede spätere Änderung verlangsamt. Dieser wachsende Wartungsaufwand verhält sich wie eine technische und gestalterische Schuld, die man bewusst steuern muss, damit sie ein Projekt nicht lähmt.
Discovery und MVP machen aus Wetten echte Entscheidungen
Bleibt ein letzter Posten. Er entsteht aus einer Wette. Wer auf Verdacht baut, setzt darauf, dass eine Annahme über die Zukunft zutrifft. Trifft sie nicht zu, kommt der nachträgliche Umbau hinzu, zusätzlich zu allem, was schon investiert wurde. Was als Abkürzung gedacht war, wird so zum Umweg.
Daraus folgt für uns eine einfache Konsequenz. Wir treffen Entscheidungen so spät, wie wir es verantworten können, nämlich im letzten Augenblick, bevor weiteres Aufschieben selbst beginnt, etwas zu kosten. In der Softwareentwicklung heißt dieser Zeitpunkt Last Responsible Moment. Bis dahin halten wir uns alle Möglichkeiten offen, statt sie früh zu verbauen.
Damit aus diesem späten Entscheiden kein Zaudern wird, gehen wir methodisch vor. Unsere Discovery hat ein klares Ziel. Bevor wir bauen, fragen wir viel, aber nicht endlos. Wir wollen verstehen, was ein Produkt wirklich leisten muss, welche Annahmen tragen und welche bloß plausibel klingen. Dieses Fragen ist fokussiert. Es führt zu einer Entscheidung, statt sie aufzuschieben. Danach liefern wir möglichst früh nur die Kernfunktionen aus und beobachten, wie echte Nutzer damit umgehen. Aus ihrem Verhalten lernen wir, was als Nächstes tatsächlich gebraucht wird, statt es zu vermuten. Dieser Ansatz ist als Lean Startup bekannt. Sein zentrales Werkzeug ist das Minimum Viable Product, kurz MVP. Gemeint ist das kleinste funktionierende Produkt, das echtes Lernen über den wahren Bedarf der Nutzer ermöglicht.
Auf diesem Weg entsteht Software, die einerseits schlank und wartbar bleibt und sich andererseits gut weiterentwickeln lässt, weil sie nicht unter dem Gewicht ungenutzter Funktionen erstarrt. Dadurch fließt Ihr Budget am Ende dorthin, wo es zählt: in echten Mehrwert für Nutzer, statt Funktionen, die nur für ein vages „Irgendwann“ auf Vorrat liegen.