Es gibt einen Spruch, der vor allem durch die Navy SEALs bekannt geworden ist:

„Slow is smooth and smooth is fast.“

Gemeint ist damit, dass übereiltes Handeln zu Fehlern führt, die am Ende mehr Zeit kosten als die vermeintlich gesparte. Wer hingegen ruhig und kontrolliert vorgeht, arbeitet präziser, macht weniger Fehler und erreicht das Ziel paradoxerweise früher. In Hochdrucksituationen, in denen Sekunden über Erfolg und Misserfolg entscheiden, mag das kontraintuitiv klingen. Doch genau dort hat sich dieses Prinzip bewährt.

In der Softwareentwicklung begegnet mir ein ähnliches Muster. Die Branche steht unter permanentem Zeitdruck, Deadlines sind eng, Anforderungen ändern sich laufend, und der Reflex, so schnell wie möglich Code zu schreiben, ist tief verankert. Fortschritt wird oft daran gemessen, wie schnell neuer Code entsteht. Doch gerade dieser Reflex führt häufig dazu, dass Projekte am Ende länger dauern als nötig. Die Parallele zu den Navy SEALs ist frappierend, und ich bin überzeugt, dass ihr Grundsatz einer der wertvollsten Ratschläge ist, den Softwareteams beherzigen können.

Wenn Geschwindigkeit zur Falle wird

Die Versuchung liegt auf der Hand: Ein neues Feature steht an, die Anforderungen scheinen klar, also öffnet man den Editor und beginnt zu tippen. Schließlich wird Software in Code gemessen, nicht in Whiteboard-Skizzen. Je früher Code entsteht, desto früher ist man fertig. So zumindest die gängige Annahme.

Die Realität zeichnet ein anderes Bild. Code, der ohne gründliche Vorüberlegung entsteht, basiert auf impliziten Annahmen. Jede und jeder im Team hat eine eigene Vorstellung davon, wie die Lösung funktionieren soll, aber diese Vorstellungen werden selten abgeglichen. Die Annahmen stellen sich oft erst spät als falsch heraus, etwa wenn sich zeigt, dass die gewählte Schnittstelle für die tatsächlichen Anwendungsfälle ungeeignet ist oder dass ein Sonderfall die gesamte Architektur infrage stellt. Was harmlos begann, wird zum strukturellen Problem.

Was dann folgt, sind Korrekturschleifen. Nicht eine, sondern mehrere. Dazu kommen Diskussionen, die man besser vorher geführt hätte, Refactorings, die im Grunde Neuschreibungen sind, und eine wachsende Menge an technischen Schulden. Der Code, der so schnell entstanden ist, muss erklärt, verteidigt und überarbeitet werden. Aus dem vermeintlich schnellen Start wird ein zähes, kostspieliges Nacharbeiten.

Das Tückische daran ist, dass dieser Effekt selten sichtbar wird. Niemand misst, wie viel Zeit ein Team mit Nacharbeit verbringt, die bei besserem Vorgehen vermeidbar gewesen wäre. Die Stunden versickern in Bugfixes, in „kleinen Anpassungen“ und in Meetings, in denen man klärt, was man vorher hätte klären sollen. Die anfängliche Geschwindigkeit war eine Illusion.

Ein Experiment zu zweit

Vor etlichen Jahren haben ein Kollege und ich einen Entwicklungsprozess etabliert, der von außen betrachtet geradezu verschwenderisch wirkte. Wann immer wir ein neues Modul oder eine neue Komponente entwickeln sollten, haben wir nicht als Erstes den Editor geöffnet. Stattdessen sind wir ans Whiteboard gegangen.

Dort haben wir das Problem von der anderen Seite her aufgerollt: Nicht „Wie bauen wir das?“, sondern „Wie soll es sich anfühlen, wenn jemand diesen Code verwendet?“ Diese Frage klingt simpel, aber sie verändert die gesamte Perspektive. Das Prinzip ist unter dem Begriff „Working backwards“ bekannt, wie es unter anderem bei AWS praktiziert wird. Man beginnt beim gewünschten Ergebnis und arbeitet sich von dort zurück zur Implementierung.

Konkret bedeutete das: Wir haben am Whiteboard Codebeispiele skizziert. Nicht den internen Aufbau, sondern die öffentliche Schnittstelle. Wie würde eine Entwicklerin oder ein Entwickler dieses Modul aufrufen? Welche Parameter wären intuitiv? Welche Rückgabewerte würden erwartet? Welche Fehlerfälle müsste man behandeln, und wie sollte das aussehen?

Dieses Vorgehen erzwang, dass wir uns intensiv mit der Domäne und den Anforderungen auseinandersetzten, bevor eine einzige Zeile produktiven Codes entstand. Es zwang uns, Fragen zu stellen, die beim sofortigen Losprogrammieren untergegangen wären. Häufig stellten wir dabei fest, dass unsere anfänglichen Vorstellungen von der Schnittstelle nicht tragfähig waren. Dann haben wir das Whiteboard gewischt und von vorn begonnen, so oft wie nötig. Das kostete trotzdem nur Stunden, keine Tage oder gar eine Woche.

Am Ende dieser Phase hatten wir ein gemeinsames, explizites Verständnis davon, was wir eigentlich bauen wollten. Nicht ungefähr, nicht implizit, sondern konkret und greifbar. Wir konnten jedem im Team erklären, warum die Schnittstelle genau so aussehen sollte und nicht anders. Diese Klarheit war kein Nebenprodukt, sie war das eigentliche Ziel.

Wegwerfen als Investition

Nach der Whiteboard-Phase folgte ein Schritt, der auf den ersten Blick noch ungewöhnlicher wirkt: Wir haben einen Prototyp geschrieben, mit dem klaren Vorsatz, ihn anschließend wegzuwerfen. Kein sauberer Code, keine Tests, keine Dokumentation. Nur ein schneller, funktionaler Durchstich, um unsere Thesen zu überprüfen.

Dieser Prototyp diente ausschließlich dem Lernen. Am Whiteboard kann man vieles klären, aber bestimmte Dinge zeigen sich erst, wenn man tatsächlich Code schreibt. Theorie und Praxis klaffen in der Softwareentwicklung oft weiter auseinander, als man wahrhaben möchte. Wie verhält sich die Schnittstelle, wenn man sie wirklich benutzt? Wo fühlt sie sich sperrig an? Welche Randfälle tauchen auf, an die man nicht gedacht hat? Wo hat man die Komplexität über- oder unterschätzt? Welche Abhängigkeiten ergeben sich, die auf dem Whiteboard nicht sichtbar waren?

Der entscheidende Punkt war, dass dieser Prototyp keine Verpflichtung mit sich brachte. Weil von Anfang an feststand, dass er weggeworfen würde, konnten wir frei experimentieren. Es gab keinen Druck, die einmal gewählte Struktur beizubehalten, nur weil schon Code da war. Wir konnten Sackgassen ohne schlechtes Gewissen verlassen und Alternativen ausprobieren. Wir konnten Fehler machen, ohne dass diese Fehler sich in der Codebasis festsetzten.

Das Wegwerfen selbst fiel erstaunlich leicht. Nicht, weil uns der Code egal war, sondern weil das eigentliche Ergebnis dieser Phase nicht der Code selbst war. Das Ergebnis war Erkenntnis: ein tiefes, praktisches Verständnis dafür, wie die Lösung aussehen sollte und welche Fallstricke zu vermeiden waren. Dieses Verständnis ließ sich nicht durch Nachdenken allein gewinnen. Es brauchte die Erfahrung des Tuns, das Scheitern in einer sicheren Umgebung.

Die finale Fassung mit Rückenwind

Erst im dritten Anlauf haben wir den eigentlichen, produktiven Code geschrieben. Und hier zeigte sich der Lohn der Vorarbeit: Das Schreiben ging bemerkenswert schnell. Nicht, weil wir uns beeilten, sondern weil wir wussten, was wir taten. Die Unsicherheit, die normalerweise jede Entwicklung begleitet, war weitgehend verschwunden. An ihre Stelle war Zuversicht getreten.

Die Architektur stand, die Schnittstellen waren durchdacht, die typischen Stolperstellen waren bekannt. Wir mussten nicht mehr experimentieren oder grundlegende Entscheidungen treffen, denn das hatten wir bereits hinter uns. Stattdessen konnten wir uns darauf konzentrieren, sauberen, gut strukturierten Code zu schreiben, der von Anfang an den Qualitätsansprüchen genügt.

Genau in dieser Phase kamen auch Tests und Dokumentation hinzu. Beides fällt erheblich leichter, wenn man die Lösung verstanden hat und nicht im Nebel stochert. Tests für eine durchdachte Schnittstelle zu schreiben, ist keine Last, sondern eine Bestätigung. Man weiß, welche Fälle relevant sind, und kann sie gezielt abdecken. Und Dokumentation für ein Modul zu verfassen, dessen Designentscheidungen man bewusst getroffen hat, ist keine Pflichtübung, sondern eine natürliche Ergänzung.

Das gesamte Vorgehen fand im Pair-Programming statt. Zwei Personen am selben Problem, von der Whiteboard-Diskussion über den Prototyp bis zum fertigen Code. Auch das wirkt auf den ersten Blick teuer: Zwei Entwicklerinnen oder Entwickler für eine Aufgabe, das ist doch doppelter Aufwand? Die Praxis erzählte eine andere Geschichte. Vier Augen sehen mehr als zwei, und der ständige Dialog verhindert, dass sich jemand in eine Sackgasse verrennt, ohne es zu bemerken. Was wir an scheinbarer Effizienz aufgaben, gewannen wir an Qualität und Geschwindigkeit zurück.

„Wie könnt ihr euch das leisten?“

Wann immer ich diesen Prozess beschrieben habe, war die häufigste Reaktion eine Mischung aus Interesse und Unglauben. Die Fragen lauteten: „Wie könnt ihr euch das leisten?“ und „Wie bringt ihr eure Kunden dazu, das mitzumachen?“

Die Antwort war einfacher, als die meisten erwartet haben: Wir waren schneller und günstiger als andere. Nicht trotz, sondern wegen dieses Vorgehens. Das klingt nach einer bequemen Behauptung, aber die Zahlen stützten sie.

Der Grund liegt in einer Beobachtung, die sich über Jahre hinweg immer wieder bestätigt hat: Unser Code hat beim ersten echten Versuch mit einer überdurchschnittlich hohen Rate funktioniert. Er war weitgehend fehlerfrei, die Schnittstellen passten zu den tatsächlichen Anforderungen, und die Architektur trug auch dann noch, wenn später Erweiterungen hinzukamen. Was auf dem Papier nach Mehraufwand aussah, war in Wahrheit eine Abkürzung.

Was auf der anderen Seite wegfiel, war erheblich: keine endlosen Korrekturschleifen, keine späten Architekturentscheidungen unter Druck, keine Wochen, in denen das Team im Grunde damit beschäftigt war, frühe Fehler zu reparieren. Kein mühsames Debugging von Code, den man vor drei Wochen geschrieben und inzwischen halb vergessen hatte. Keine hitzigen Diskussionen darüber, ob man den bestehenden Ansatz noch retten kann oder doch lieber neu anfangen sollte. Für unsere Kundinnen und Kunden bedeutete das: zuverlässigere Zeitpläne, weniger Überraschungen und am Ende niedrigere Gesamtkosten.

Der Prozess sah langsamer aus, weil die erste sichtbare Codezeile später entstand. Aber die erste sichtbare Codezeile ist nicht der relevante Messpunkt. Relevant ist, wann funktionierende, zuverlässige Software ausgeliefert wird. Und diesen Punkt haben wir regelmäßig früher erreicht als Teams, die vom ersten Tag an in die Tasten gehauen haben.

Schnell geschriebener Code ist nicht besserer Code

Heute, zahlreiche Jahre später, hat sich das Umfeld grundlegend verändert. KI-gestützte Werkzeuge erzeugen Code in einem Tempo, das noch vor Kurzem undenkbar war. Ein gut formulierter Prompt liefert in Sekunden, wofür früher Stunden nötig waren. Die Geschwindigkeit der Codeerzeugung hat sich vervielfacht, und die Werkzeuge werden mit jeder Generation leistungsfähiger.

Doch Geschwindigkeit bei der Codeerzeugung ist nicht dasselbe wie Geschwindigkeit bei der Problemlösung. Eine KI kann beeindruckend schnell Code produzieren, aber sie kann nicht wissen, ob dieser Code das richtige Problem löst. Sie kann eine Schnittstelle implementieren, aber nicht beurteilen, ob diese Schnittstelle für die tatsächlichen Anwendungsfälle sinnvoll ist. Sie kann Tests generieren, aber nicht entscheiden, welche Fälle wirklich kritisch sind und welche nur Rauschen erzeugen.

Was KI-Werkzeuge im Kern tun, ist verstärken. Sie verstärken das, was man hineinsteckt. Wer genau weiß, was die Lösung leisten soll, wie die Schnittstellen aussehen müssen und welche Randfälle zu beachten sind, bekommt von einer KI beeindruckend guten Code in kürzester Zeit. Die Maschine wird zum Beschleuniger für eine klare Idee. Wer diese Klarheit nicht hat, bekommt schneller das Falsche. Und falscher Code, der in Sekunden statt in Stunden entstanden ist, bleibt falscher Code. Er muss genauso überarbeitet, korrigiert und im schlimmsten Fall weggeworfen werden. Die KI hat dann nichts beschleunigt, sie hat nur die Illusion von Fortschritt erzeugt.

Und genau hier schließt sich der Kreis zum dreistufigen Prozess. Die Phase am Whiteboard, das Durchdenken der Verwenderperspektive, das bewusste Experimentieren mit einem Wegwerf-Prototyp: All das liefert genau die Klarheit, die man braucht, um KI-Werkzeuge sinnvoll einzusetzen. Man füttert die KI nicht mit vagen Vorstellungen, sondern mit präzisen Anforderungen. Die KI übernimmt dann den Teil, der tatsächlich beschleunigt werden kann: das Schreiben von Code, dessen Richtung bereits feststeht.

Die Versuchung ist groß, diesen Schritt zu überspringen. Wenn Code so billig zu erzeugen ist, warum nicht einfach ausprobieren und schauen, was passiert? Die Antwort ist dieselbe wie vor zwanzig Jahren: Weil das Erzeugen von Code nie der Engpass war. Der Engpass war und ist das Verstehen. Und Verstehen lässt sich nicht beschleunigen, indem man schneller tippt, ob mit oder ohne KI.

Langsam anfangen, um schnell anzukommen

„Slow is smooth and smooth is fast.“ Dieser Grundsatz der Navy SEALs hat nichts an Gültigkeit verloren, auch nicht in einer Zeit, in der Maschinen Code schneller schreiben als jeder Mensch.

Bewusst Tempo herauszunehmen, sich die Zeit zu geben, ein Problem wirklich zu durchdringen, bevor man es löst, fühlt sich an wie ein Luxus, den man sich nicht leisten kann. Die Erfahrung zeigt jedoch das Gegenteil: Es ist eine Investition, die sich zuverlässig auszahlt. In weniger Fehlern, in weniger Nacharbeit, in kürzerer Gesamtdauer und in Code, der nicht nur funktioniert, sondern trägt. In Teams, die weniger streiten und mehr liefern.

Ob man diesen Code dann selbst schreibt oder von einer KI schreiben lässt, ist zweitrangig. Entscheidend ist, dass man weiß, was man will, bevor man anfängt. Erst denken, dann experimentieren, dann bauen. In dieser Reihenfolge. Daran hat sich in all den Jahren nichts geändert.

(rme)