Die Bremswirkung technischer Schulden sichtbar gemacht
Technische Schulden werden oft als Metapher behandelt, doch sie verhalten sich eher wie ein Naturgesetz: Sie sind ein Bremskoeffizient auf die Geschwindigkeit deines Teams.
Gesund: Das Team hält ein nachhaltiges, professionelles Tempo.
In A Philosophy of Software Design definiert John Ousterhout Komplexität als „alles an der Struktur eines Softwaresystems, das es schwer verständlich und schwer änderbar macht". Dieses interaktive Modell macht diese Reibung sichtbar. Es beleuchtet das Spannungsfeld zwischen taktischer Programmierung (jetzt schnell ausliefern) und strategischer Programmierung (in Design für die Zukunft investieren).
Komplexität sammelt sich an, ob es uns gefällt oder nicht. Das Einzige, worauf wir Einfluss haben, ist, wie viel Zeit wir uns nehmen, um mit ihr umzugehen. Mehr Zeit für Bugfixes und Refactoring bedeutet weniger Zeit, um Features auszuliefern. Du brauchst also eine Strategie.
Vier Archetypen
- Startup-Rush (10 %): Der „taktische" Ansatz. Anfangs lieferst du schnell, doch du borgst dir Zeit aus der Zukunft. Irgendwann wird die Schuldenlast so schwer, dass Moral und Geschwindigkeit zusammenbrechen.
- Nachhaltig (30 %): Der „strategische" Sweet Spot. Du investierst gerade genug (etwa ein Drittel deiner Zeit), um die Schulden konstant zu halten. Das bringt langfristig die höchste Geschwindigkeit.
- Enterprise-sicher (50 %): Ein risikoarmer, langsamerer Ansatz, bei dem Stabilität Vorrang vor neuen Features hat.
- Komplettes Refactoring (80 %): Die Notbremse. Du lieferst nichts mehr aus, um aufzuräumen. Es funktioniert, aber die Erholung ist schmerzhaft und langsam.
Wie das Modell funktioniert
Diese Simulation ist nicht zufällig. Sie wird vom Kampf zwischen zwei gegensätzlichen Kräften angetrieben: Entropie und Investition.
- Das Wachstum der Komplexität (Entropie). Software neigt von Natur aus zur Unordnung, je mehr Features hinzukommen. Tust du nichts, wachsen die Schulden, und je mehr sie wachsen, desto stärker verzinsen sie sich.
- Die Tilgung (Investition). Indem du Zeit fürs Aufräumen einplanst, erzeugst du eine „Tilgungsrate". Das Ziel ist das Gleichgewicht, in dem deine Tilgung dem natürlichen Wachstum der Komplexität entspricht.
- Die Bremswirkung auf die Geschwindigkeit. Das ist der Kernmechanismus: Geschwindigkeit hängt nicht nur davon ab, wie schnell du tippst. Sie ist
100 % − (Bremse durch Schulden) − (Zeit fürs Refactoring).
Die Falle: Hörst du mit dem Refactoring auf, sparst du zunächst Zeit (die Geschwindigkeit schnellt hoch). Doch während die Schulden anwachsen, wird die „Bremse" gewaltig und würgt dein Tempo weit stärker ab, als das Refactoring es je getan hätte.
Hinterher ist man immer klüger
100 % Geschwindigkeit ist ein Warnsignal
Bewegt sich ein Team mit „100", borgt es sich Zeit aus der Zukunft. Die „fehlenden" 30 % Geschwindigkeit in einem gesunden Team sind keine Verschwendung; sie sind die Betriebskosten. Kommunikation, Design und Wartung sind harte Arbeit.
Der euphorische Entwickler ist ein Mythos
Eine Moral von 85–90 % ist die realistische Obergrenze. Die Lücke zwischen 85 und 100 steht für professionelle Disziplin: die notwendige Reibung durch Tests, Dokumentation und Code-Reviews. „Rundum glücklich" heißt meist, die harten Teile auszulassen.
Schulden werfen Zinsen ab
Technische Schulden liegen nicht einfach herum; sie verzinsen sich. Mit wachsender Komplexität steigt die „Steuer" auf jede neue Codezeile. Wartest du zu lange, wird der Break-Even-Punkt fürs Refactoring unerreichbar hoch.
Ausliefern ist Sauerstoff
Entwickler hassen schlechten Code, aber sie hassen es genauso, nicht auszuliefern. Eine Strategie mit 100 % Refactoring (Gold Plating) tötet die Moral genauso schnell wie 0 % Refactoring (Spaghetticode). Ingenieure müssen den Schwung der Auslieferung spüren, um bei der Sache zu bleiben.
Der „ökonomische" Punkt ohne Wiederkehr
Technische Schulden sind nicht dann tödlich, wenn der Code unreparierbar ist, sondern wenn die Kosten der Erholung unbezahlbar werden. Bei Sättigung bedeutet das nötige „komplette Refactoring", monatelang nichts auszuliefern. Das ist wirtschaftlicher Bankrott.
Sauberer Code ist nicht das Ziel
70 % Geschwindigkeit (mitsamt Wartungskosten) sind besser als 40 % Geschwindigkeit (perfekter Code). Hast du 0 % Schulden, kommst aber nur langsam voran, weil du Code polierst, scheiterst du genauso wie das Team mit hohen Schulden. Das Ziel ist das nachhaltige Maximum.
Fazit
Die Simulation belegt Ousterhouts zentrale These: Komplexität sammelt sich an, wenn man nicht in Design investiert. Die effektivsten Teams sind nicht die, die am schnellsten tippen; es sind die, die eine „nachhaltige" Balance halten und verhindern, dass der Bremskoeffizient die Oberhand gewinnt.
Sieh dir den Vortrag an, den ich auf TNGs Big Techday 24 besucht habe: