Nur noch dieses eine Feature …

hi@marvinstrauch.de (Marvin Strauch) — Wed, 10 Jun 2026 00:00:00 GMT

Noch lief keine einzige Firewall in Produktion. Sie war gerade erst in Entwicklung: die Firewall für die dataforest cloud, mit der Nutzer ihren ein- und ausgehenden Datenverkehr selbst kontrollieren. Kein Nutzer hatte je eine Regel geschrieben. Aber die nächste Idee war schon geboren: geteilte IP-Listen, die man an einer Stelle pflegt, damit man nicht in jeder Firewall dieselben Adressen einzeln einträgt. Eine großartige Idee.

Die Listen waren schon halb gebaut: eine eigene Seite, ein Eintrag in der Navigation, fertige Übersetzungen. Nur lief immer noch keine einzige Firewall in Produktion. Am Dach wurde gebaut, bevor die Wände standen. Also habe ich die Listen erst mal zurückgestellt: voller Fokus auf die Firewall.

Der Impuls ist menschlich. Man will zu viel auf einmal und verliert dabei den Kern aus dem Blick. Dahinter steckt ein Trugschluss: Mehr ist besser. Nur stimmt das nicht.

Das nächste Feature lockt

Warum zieht es einen so verlässlich dorthin? Weil das Hinzufügen sichtbar ist und das Fertigstellen nicht. Das fängt schon im Daily an. »Ich habe die geteilten Listen angefangen« klingt nach »sehr beschäftigt«. Sagt man dagegen zum fünften Mal, man sitze noch an der Firewall, klingt es, als käme man nicht weiter.

Und es liegt nicht nur daran, wie es nach außen wirkt. Auch ohne Publikum zieht es einen zum Hinzufügen. Eine Studie in Nature hat das in acht Experimenten gezeigt: Sollen Menschen etwas verbessern, fügen sie meist etwas hinzu und übersehen die Lösung, die etwas wegnimmt, selbst dort, wo Weglassen klar besser wäre. Und je weniger Zeit zum Nachdenken bleibt, desto eher fügt man hinzu, statt wegzunehmen. Also genau dann, wenn man im Endspurt für ein neues Feature steckt.

Die geteilten Listen kamen aus dem Team. Wer so einen Vorschlag macht, will das Produkt besser machen: Die Person setzt die Brille des Nutzers auf und sieht, was dieser eines Tages brauchen könnte. An der Qualität der Idee liegt es meistens nicht.

Aber während über die nächste Idee geredet wird, verliert man das Wesentliche aus den Augen. Der Nutzer wartet auf das eine Feature, das fast fertig ist. Man selbst sagt sich: »Nur noch diese eine Ergänzung oder Anpassung, dann ist es wirklich fertig«, und so verschiebt sich das Release immer weiter. Den Preis dafür nennt Donald Reinertsen Cost of Delay: die Kosten, die sich mit jedem weiteren Tag summieren, an dem etwas nicht draußen ist. Weil diese Kosten unsichtbar sind, tut man so, als wäre Verschieben kostenlos. Was zu spät kommt, fällt niemandem als Fehler auf, und was nie fertig wird, vermisst vermeintlich keiner.

Technik ist kein Selbstzweck

Das Zuviel ist nicht immer ein neues Feature. Letzten Herbst habe ich für ein Frontend eine Komponente gebaut, die andere Komponenten lazy lädt, wenn diese wirklich in den Viewport kommen. Sie war voll ausgestattet mit einer Ladeanimation, Error-Handling und einem Timeout für den Fall, dass es ganz übel läuft. Mein Anspruch war, noch die letzten Millisekunden aus dem User Interface herauszukitzeln.

Eingesetzt hat sie leider bis heute niemand. Alle Komponenten werden ganz normal geladen. Aber über die Geschwindigkeit hat sich nie ein Nutzer beschwert. Ganz im Gegenteil: Sehr viele Nutzer loben, wie schnell sich alles anfühlt.

Und so hatte ich Technik um der Technik willen gebaut, ohne ein echtes Problem zu lösen. »Verfrühte Optimierung ist die Wurzel allen Übels«, hat Donald Knuth schon vor einem halben Jahrhundert festgestellt. Schlimm war nicht die Zeit, die ich in die Komponente gesteckt habe. Schlimm wäre gewesen, die Maschinerie überall einzuziehen: Spürbar schneller wäre nichts geworden, nur komplizierter in der Wartung und anfälliger für Bugs.

Der Mut zum Weglassen

Und manchmal muss auch fertiger Code wieder raus. Weit über tausend Zeilen, um neuen Nutzern die Cloud zu erklären: mit eigener komplexer Seitenstruktur und einem eigenen Layout. So sah das Onboarding der Cloud aus. Leider hat es nicht so stabil funktioniert, wie ich mir das vorgestellt hatte, weshalb ich es durch ein simples Modal im Dashboard ersetzt habe. Am Ende blieben siebzig Zeilen Code übrig, die jetzt richtig gut funktionieren.

Unbequem ist das schon: erst das Wesentliche fertig bauen, und zwar richtig. Und den Mut haben, das meiste wegzulassen.

Das heißt nicht, dass mehr immer falsch ist. Manchmal ist die nächste Funktion genau die, die fehlt. Die Kunst ist, diesen Moment vom bloßen Reflex des Hinzufügens zu unterscheiden. Und aus eigener Erfahrung kann ich sagen, das ist gar nicht so einfach.

»Weniger, aber besser«, das Leitmotiv des Gestalters Dieter Rams, ist mit der Zeit mein eigenes geworden. Das eine Feature, das in hoher Qualität läuft, ist mehr wert als zehn angefangene Funktionen, die bald das Licht der Welt erblicken werden (ganz sicher!). Die Firewalls laufen inzwischen in Produktion. Die geteilten Listen kommen, wenn sie dran sind. Und auch das Onboarding feiert sicherlich eines Tages sein Comeback.

Wenn du ein Feature vermisst, dann schreib mir doch eine Mail an hi@marvinstrauch.de, und bei der nächsten Roadmap-Planung habe ich endlich das beste Argument, das es gibt: einen Nutzer, der eine Funktion wirklich braucht.