Warum ist nie Zeit, es richtig zu machen – aber immer Zeit, es zu reparieren?

Es ist einer dieser Sätze, die in jedem Unternehmen fallen. In Meetings, in Retros, beim Kaffee: „Dafür haben wir jetzt keine Zeit.” Gemeint ist damit nie die Deadline. Gemeint ist: Wir machen es schnell statt gründlich. Und alle nicken, weil der Druck real ist.

Drei Monate später sitzt dasselbe Team zusammen. Diesmal lautet der Satz: „Das müssen wir nochmal anfassen.” Plötzlich ist Zeit da. Für Bugfixes, Workarounds, Nachbesserungen, Migrationen. Für alles, was man beim ersten Mal bewusst übersprungen hat.

Das ist kein Zufall. Es ist ein Muster – und es lohnt sich, dieses Muster zu verstehen.

Der unsichtbare Preis der Geschwindigkeit

Schnell liefern fühlt sich produktiv an. Es gibt ein Ergebnis, einen Haken auf der Liste, ein gutes Gefühl im Standup. Aber Geschwindigkeit ohne Sorgfalt erzeugt technische Schulden, organisatorische Schulden und manchmal auch menschliche Schulden. Die Kosten tauchen nur nicht sofort auf – sie verteilen sich über Wochen und Monate auf andere Budgets, andere Sprints, andere Teams.

Und genau das macht die Falle so tückisch: Der Aufwand für „schnell erledigt” ist sichtbar und begrenzt. Der Aufwand für „nachträglich repariert” verteilt sich so breit, dass ihn niemand mehr einem einzelnen Ursprung zuordnet. Es fehlt die direkte Rückkopplung.

Was beim ersten Mal wirklich fehlt

Hier wird es interessant, denn die Situation ist selten so eindeutig, wie sie im Nachhinein erscheint. Beim ersten Durchgang fehlen fast immer wesentliche Informationen. Anforderungen sind vage. Der Kontext ist unvollständig. Stakeholder wissen selbst noch nicht genau, was sie brauchen. Das System, in das man hineinbaut, verhält sich anders als dokumentiert – oder ist gar nicht dokumentiert.

Das heißt: Es gibt einen legitimen Grund, beim ersten Mal nicht alles perfekt zu machen. Wer auf vollständige Information wartet, liefert nie. Das ist keine Ausrede, das ist Realität. Gall’s Law bringt es auf den Punkt – jedes funktionierende komplexe System ist aus einem funktionierenden einfachen System entstanden. Nicht aus einem perfekt geplanten komplexen System.

Die ehrliche Frage ist also nicht „Warum machen wir es nicht gleich richtig?”, sondern: „Wissen wir genug, um es jetzt besser zu machen – und entscheiden uns trotzdem dagegen?”

Der Unterschied zwischen bewusst iterativ und fahrlässig schnell

Genau hier trennt sich gute Ingenieurskultur von schlechter Gewohnheit. Es gibt zwei grundverschiedene Haltungen, die oberflächlich gleich aussehen.

Die bewusst iterative Haltung sagt: Wir wissen noch nicht alles. Also bauen wir eine erste Version, die funktioniert, lernen daraus und verbessern gezielt. Wir akzeptieren Unvollkommenheit als Teil des Prozesses – aber wir planen die nächste Iteration ein, bevor wir die erste abschließen.

Die fahrlässig schnelle Haltung sagt: Wir haben keine Zeit. Also nehmen wir Abkürzungen, ignorieren bekannte Risiken und hoffen, dass es hält. Wenn nicht, kümmern wir uns später. Vielleicht. Wenn es brennt.

Der Unterschied liegt nicht im Ergebnis der ersten Version. Der Unterschied liegt in der Absicht – und darin, ob die zweite Iteration geplant oder erzwungen ist.

Warum Reparatur immer Budget bekommt

Es gibt einen psychologischen Mechanismus, der dieses Muster am Leben hält. Prävention ist unsichtbar. Wenn man etwas von Anfang an solide baut, passiert danach einfach … nichts. Kein Drama, kein Incident, kein Held, der nachts den Hotfix deployt. Das lässt sich schlecht in einer Präsentation verkaufen.

Ein Ausfall dagegen erzeugt Dringlichkeit. Und Dringlichkeit öffnet Budgets, verschiebt Prioritäten und gibt Teams plötzlich die Ressourcen, die sie vorher nie bekommen hätten. Es ist eine perverse Anreizstruktur: Wer Probleme verhindert, wird nicht belohnt. Wer Probleme löst, schon.

Das ist kein individuelles Versagen. Das ist ein systemisches Problem, das sich durch Organisationen jeder Größe zieht.

Was man konkret anders machen kann

Die Lösung ist nicht, beim ersten Mal Perfektion zu verlangen. Das wäre naiv und kontraproduktiv, gerade wenn Informationen fehlen. Stattdessen helfen ein paar Prinzipien, die in der Praxis funktionieren.

Unvollständiges Wissen einpreisen. Wenn klar ist, dass wichtige Informationen erst im Betrieb sichtbar werden, dann gehört die Review-Phase in den ursprünglichen Plan. Nicht als optionaler Bonus, sondern als fester Bestandteil. Eine Architektur, die man nicht anpassen kann, ist keine gute Architektur – sie ist eine Wette.

Bewusste Entscheidungen dokumentieren. Jede Abkürzung, die man nimmt, sollte als bewusste Entscheidung festgehalten werden. Nicht aus Bürokratie, sondern damit das zukünftige Team versteht, warum etwas so gebaut wurde – und wo die bekannten Schwachstellen liegen. Ein Architecture Decision Record kostet zehn Minuten und spart Wochen an Archäologie.

Den zweiten Durchgang planen, bevor der erste fertig ist. Wer von Anfang an weiß, dass eine Überarbeitung kommt, baut anders. Modularer, entkoppelter, mit klareren Schnittstellen. Nicht perfekt, aber veränderbar. Das ist der Unterschied zwischen einer schnellen Lösung und einer, die man schnell verbessern kann.

Sichtbarkeit für Prävention schaffen. Teams, die stabile Systeme betreiben, verdienen Anerkennung – nicht nur die, die Brände löschen. Metriken wie Mean Time Between Failures oder die Häufigkeit ungeplanter Arbeit machen sichtbar, was gute Vorarbeit leistet.

Zum Schluss

Es wird immer Situationen geben, in denen man nicht alle Informationen hat. In denen man unter Unsicherheit entscheiden muss. Das ist kein Bug – das ist der Normalzustand in komplexen Systemen. Die Frage ist nur, ob man diesen Umstand als Einladung zur Schlamperei interpretiert oder als Grund, bewusst iterativ zu arbeiten.

Der Satz „Dafür haben wir keine Zeit” ist selten wahr. Fast immer heißt er: „Dafür haben wir keine Priorität.” Und das ist eine Entscheidung, die man bewusst treffen sollte – mit dem Wissen, dass die Zeit für die Reparatur später garantiert kommen wird.

Nur teurer.