Die letzten 10% sind die echten 90%

Es gibt eine Regel in der Softwareentwicklung, die jeder kennt und trotzdem jedes Mal vergisst: Die 90-90-Regel. Die ersten 90 Prozent des Codes brauchen 90 Prozent der Zeit. Die letzten 10 Prozent brauchen die anderen 90 Prozent der Zeit. Ja, das sind 180 Prozent. Willkommen in der Realität.

Tom Cargill von den Bell Labs hat das in den 80ern formuliert. Seitdem hat sich an der Gültigkeit dieser Beobachtung exakt nichts geändert. Und ich habe es in über 25 Jahren Softwareentwicklung in jedem einzelnen Projekt erlebt. Ohne Ausnahme.

Wie es immer anfängt

Am Whiteboard sieht jedes Projekt machbar aus. Die Architektur ist klar, die Komponenten sind definiert, der Zeitplan steht. Zwei Sprints für das Backend, einer für das Frontend, einer für Testing. Fertig in acht Wochen. Alle nicken. Alle glauben dran.

Dann beginnt die eigentliche Arbeit.

Der Happy Path funktioniert nach zwei Wochen. Die Demo sieht fantastisch aus. Der Kunde ist begeistert. Das Projektmanagement aktualisiert das Gantt-Chart: „90 Prozent fertig.“ Die Stimmung ist gut.

90 Prozent fertig. Der gefährlichste Satz in der Softwareentwicklung.

Ein Projekt, das mir das beigebracht hat

Vor ein paar Jahren: Ein mittelständischer Onlineshop, Relaunch auf Shopware 6. Neues Theme, neue Produktstruktur, API-Anbindung ans Warenwirtschaftssystem. Drei Monate geschätzt. Die ersten sechs Wochen liefen wie am Schnürchen. Theme stand, Produktimport lief, der Bestellprozess funktionierte. Demo beim Kunden: Standing Ovations. Fast.

Dann kam die QA-Phase.

Der Produktimport funktionierte — bei 500 Produkten. Der Kunde hatte Zehntausende. Bei dieser Menge lief der Import über zehn Stunden und brach dann mit einem Memory-Fehler ab. Also Batch-Processing einbauen. Aber der Batch-Prozess erzeugte Duplikate, wenn er nach einem Abbruch neu gestartet wurde. Also Idempotenz einbauen. Aber die Idempotenz-Prüfung machte den Import noch langsamer. Also Caching. Aber das Caching — na ja, du siehst, wohin das führt.

Dann die Variantenlogik. Ein Produkt in drei Farben und fünf Größen: 15 Varianten. Funktioniert. Ein Produkt mit Farbe, Größe, Material und Sonderkonfiguration: 180 Varianten. Die Produktseite brauchte acht Sekunden zum Laden. Acht Sekunden. Da ist der Kunde längst weg.

Dann die Schnittstelle zum Warenwirtschaftssystem. In der Dokumentation stand: „REST-API, JSON-Format.“ In der Realität: Eine API, die je nach Wochentag unterschiedliche Datumsformate zurückgab. Kein Witz. Montags ISO 8601, mittwochs deutsches Format. Der Hersteller fand das nicht ungewöhnlich.

Drei Monate geschätzt. Sechs Monate gebraucht. Und das war kein Scheitern — das war die 90-90-Regel in Aktion.

Die unsichtbaren 90 Prozent

Was in der Demo funktioniert und was in Produktion funktioniert, sind zwei verschiedene Welten. Die Demo hat einen Benutzer: den Kunden, der zuschaut. Produktion hat tausend Benutzer, die alle gleichzeitig Dinge tun, die du dir nicht vorstellen konntest.

Was passiert, wenn der Benutzer das Formular zweimal abschickt, weil der Button nicht sofort reagiert hat? Was passiert bei 10.000 gleichzeitigen Zugriffen statt bei 10? Was passiert, wenn die externe API nicht mit einem Fehler antwortet, sondern einfach gar nicht?

Dazu kommen die Datenmengen: Was passiert, wenn der Datensatz nicht 100 Einträge hat, sondern 2 Millionen? Oder die Zeichensätze: Was passiert, wenn jemand einen Umlaut im Firmennamen hat und dein System das nicht erwartet? Und dann ist da noch der Black Friday, an dem der Traffic-Spike den Cache invalidiert und 500 Requests gleichzeitig die Datenbank treffen.

Jeder einzelne dieser Punkte kann einen Tag kosten. Oder eine Woche. Oder einen kompletten Architektur-Umbau. Und keiner davon steht im ursprünglichen Backlog, weil niemand sie vorher sehen konnte.

Das Gefühl der letzten 10 Prozent

Es gibt ein spezifisches Gefühl, das jeder Entwickler kennt: Du bist „fast fertig“. Seit drei Wochen bist du „fast fertig“. Jeden Tag löst du ein Problem, und hinter jedem gelösten Problem tauchen zwei neue auf. Nicht weil du schlecht bist — sondern weil Software unter realen Bedingungen anders funktioniert als unter Laborbedingungen.

Du fixst den Performance-Bug, und plötzlich schlägt ein Test fehl, der vorher grün war. Du fixst den Test, und merkst, dass der Test eigentlich falsch war und bisher nur zufällig funktioniert hat. Du fixst den Test richtig, und findest dabei einen Edge Case, den niemand bedacht hat. Und so weiter.

Die letzten 10 Prozent fühlen sich an wie gegen einen Strom zu schwimmen, der stärker wird, je näher du dem Ufer kommst.

Warum Schätzungen immer falsch sind

Wir können die ersten 90 Prozent einigermaßen schätzen, weil sie vorhersehbar sind. CRUD-Operationen, Formulare, Layouts — das kennen wir, das können wir beziffern.

Die letzten 10 Prozent kann niemand schätzen, weil sie per Definition aus dem Unvorhersehbaren bestehen. Du kannst nicht schätzen, wie lange es dauert, einen Bug zu finden, den du noch nicht kennst. Du kannst nicht schätzen, wie ein System unter Last reagiert, das noch nie unter Last war. Du kannst nicht schätzen, welche Inkompatibilitäten zwischen deinem Code und der Produktivumgebung auftreten, weil du die Produktivumgebung noch nie gesehen hast.

Schätzen ist, was wir für die planbaren 90 Prozent tun. Raten ist, was wir für die restlichen 10 Prozent tun. Und Raten nennen wir dann „Puffer“.

Live ist nicht lokal

Der Klassiker, der mich in über 25 Jahren nie loslässt: „Auf meinem Rechner funktioniert’s.“ Ja. Auf deinem Rechner. Mit deinen Testdaten. Mit deiner Netzwerklatenz von null Millisekunden. Mit deinem einen Benutzer.

Live heißt: andere PHP-Version, andere Serverkonfiguration, andere Datenmengen, andere Nutzungsmuster, andere Browser, andere Zeitzonen, andere Zeichensätze. Live ist der Ort, an dem Annahmen sterben. Jede einzelne.

Docker hat vieles besser gemacht, ja. Aber auch Docker löst nicht das Problem, dass dein Staging-Server mit 8 GB RAM läuft und der Produktivserver mit 32 GB, aber dafür drei andere Services drauf hat, die du nicht kennst.

Akzeptanz statt Optimismus

Kein Projekt wird am Whiteboard fertig. Kein Projekt wird in der Planungsphase fertig. Software wird fertig durch das mühsame, unglamouröse, zeitfressende Debugging der letzten 10 Prozent, die sich als die eigentlichen 90 Prozent herausstellen.

Durch das dritte Refactoring der Fehlerbehandlung. Durch die Performance-Optimierung, die niemand eingeplant hat. Durch den Hotfix am Freitagabend, weil ein Edge Case aufgetaucht ist, den kein Test abgedeckt hat.

Die letzten 10 Prozent sind die echten 90 Prozent. Wer das bei der Planung nicht berücksichtigt, plant nicht — er schätzt. Und schätzen ist eine höfliche Umschreibung für Raten.

Die 90-90-Regel ist kein Bug der Softwareentwicklung. Sie ist ihr ehrlichstes Feature. Und der einzige Weg, mit ihr umzugehen, ist Akzeptanz. Nicht noch ein Tool, nicht noch ein Framework, nicht noch eine Methodik. Einfach die nüchterne Einsicht: Es wird länger dauern, als du denkst. Immer. Und das ist okay — solange du es einplanst.