Eine wahre Geschichte, wie man falsche Dinge beschleunigt

Der ursprüngliche 40-minütige Talk ist bei WeAreDevelopers verfügbar.

Das Problem beginnt einen Schritt später, nämlich dann, wenn aus einer messbaren Steigerung der Geschwindigkeit stillschweigend der Beweis abgeleitet wird, dass sich das System selbst verbessert hat.

Geschwindigkeit ist attraktiv, weil sie sich leicht beobachten lässt. Ein Build dauert zwölf statt zwanzig Minuten, ein Release-Zyklus schrumpft von zwei Wochen auf zwei Tage, ein Team schließt mehr Tickets ab, eine Plattform verarbeitet mehr Traffic. Das sind echte Zahlen und sie ergeben hervorragende Charts. Richtung ist weniger kooperativ. Sehr viel schwieriger lässt sich messen, ob das, was wir jetzt schneller produzieren, überhaupt existieren sollte, ob es das dahinterliegende System tatsächlich verbessert oder ob wir lediglich die Reibung beseitigt haben, die eine schlechte Entscheidung bisher ausgebremst hat.

Dieser Unterschied ist wichtig, weil lokale Optimierung nicht dasselbe ist wie die Verbesserung des Gesamtsystems. Ein Team kann tatsächlich schneller werden und dabei an anderer Stelle mehr Arbeit erzeugen. Ein automatisierter Prozess kann einen manuellen Schritt beseitigen und Abhängigkeiten schaffen, an die sich sechs Monate später niemand mehr erinnert. Eine Integration kann ein ganz reales Problem lösen und die Gesamtarchitektur trotzdem schwerer verständlich machen als vorher. Keine dieser Verbesserungen muss vorgetäuscht sein. Sie können alle exakt das tun, was von ihnen erwartet wird, und das eigentliche System dennoch in die falsche Richtung bewegen.

Bewegung lässt sich leicht messen, bei Richtung fangen die Schwierigkeiten an.

Eine Zeit lang funktionierte das. Mit Geld ließ sich Aufmerksamkeit kaufen, Aufmerksamkeit produzierte die nächste Wachstumskurve und Wachstum rechtfertigte weiteres Geld. Die Maschinerie war ausgesprochen gut darin, genau den Teil zu beschleunigen, den ohnehin alle messen wollten. Das Problem tauchte erst auf, als die Bewertung irgendwann einen Beleg sehen wollte.

Die Finanzwelt lieferte später eine kompliziertere Variante desselben strukturellen Fehlers. Mehr Abstraktion, mehr Hebelwirkung und mehr Abstand zwischen den Menschen, die Risiken erzeugten, und denen, die sie am Ende trugen, ließen das Risiko nicht verschwinden, sondern machten das System schwerer lesbar. Wenn ein Problem durch genügend Schichten wandert, kommt irgendwann der Punkt, an dem es weniger wie ein ungelöstes Problem und mehr wie ein Implementierungsdetail aussieht.

Softwarearchitekten sollte das unangenehm vertraut vorkommen. Wir abstrahieren, kapseln, integrieren und automatisieren, weil sich dadurch Redundanz vermeiden und komplizierte Dinge handhabbar machen lassen. Aber jede Abstraktion schafft auch Abstand, und dieser Abstand kann genau den Punkt unsichtbar machen, an dem niemand mehr das Gesamtsystem versteht. Gute Entwicklung kann Komplexität reduzieren, schlechte Entwicklung kann sie verstecken. Von außen kann beides erstaunlich lange fast identisch aussehen.

Der Flash Crash von 2010 war eine sehr viel komprimiertere Demonstration. Automatisierte Handelssysteme reagierten mit Maschinengeschwindigkeit auf Marktbedingungen und aufeinander, die Liquidität brach ein und der Ablauf musste anschließend rekonstruiert werden. Die Maschinen reagierten; die Menschen erklärten später, was passiert war.

Das ist kein Argument gegen Automatisierung. Maschinen sollen schneller reagieren als Menschen; sonst gäbe es wenig Grund, viele dieser Systeme überhaupt zu automatisieren. Der interessante Unterschied liegt nicht zwischen Maschinen und menschlicher Geschwindigkeit, sondern zwischen Reaktion und Korrektur.

Ein System kann extrem schnell reagieren, ohne entsprechend gut erkennen zu können, dass seine eigenen Reaktionen die Lage verschlimmern. Es kann im Rahmen seiner aktuellen Logik perfekt funktionieren und zugleich schlecht darin sein zu erkennen, dass genau diese Logik Teil des Problems geworden ist. An diesem Punkt erhöht zusätzliche Geschwindigkeit nicht die Kontrolle. Sie verkürzt lediglich die Zeit zwischen dem ursprünglichen Fehler und seinen Folgen.

Jetzt machen wir die Umgebung komplizierter. Wir fügen mehr Variablen, mögliche Zustände, Abhängigkeiten und mehr Wechselwirkungen zwischen ihnen hinzu. Irgendwann hat der Regler nicht mehr genügend Möglichkeiten, zu unterscheiden, was gerade passiert, oder angemessen darauf zu reagieren. Ihn schneller zu machen löst dieses Problem nicht. Ein Thermostat, das die Heizung tausendmal pro Sekunde ein- und ausschalten kann, bleibt ein Thermostat.

Ashbys Gesetz der erforderlichen Varietät liefert dafür ein nützliches Denkmodell. Ein Regler braucht in seinen möglichen Reaktionen genügend Vielfalt, um mit der Vielfalt der Störungen umgehen zu können, die er kontrollieren soll. Die Mathematik dahinter ist präziser, als wir sie hier brauchen; die praktische Konsequenz ist einfach genug. Wenn man die Bandbreite der Zustände vergrößert, die ein System erzeugen oder antreffen kann, braucht man auch genügend Möglichkeiten, diese Zustände zu unterscheiden und darauf zu reagieren.

Genau hier bringen sich Technologieunternehmen immer wieder selbst in Schwierigkeiten. Wir erhöhen die Zahl möglicher Zustände eines Systems und feiern, dass die Maschinerie, die diese Zustände verarbeitet, schneller geworden ist. Wir fügen Integrationen, Automatisierung, Services, Abhängigkeiten und neue Pfade durch die Architektur hinzu, erhöhen anschließend den Durchsatz und nennen das Fortschritt.

Doch Durchsatz und Kontrolle sind nicht dieselbe Fähigkeit. Ein schnelleres System kann eine vorhandene Reaktion schneller ausführen. Es bekommt dadurch nicht automatisch eine bessere Reaktion, ein besseres Modell der Situation oder eine bessere Möglichkeit zu erkennen, dass seine Annahmen falsch sind.

Die Umgebung wird komplexer, der Regler nicht.

Das Problem beginnt, wenn die durch diese Verbesserungen erzeugte Komplexität schneller wächst als die Fähigkeit des Systems, sich selbst dabei zu verstehen und zu korrigieren.

Eine Pipeline kann schneller werden, während die Entscheidungen, die in sie hineinfließen, weiterhin schlecht sind. Infrastruktur kann besser skalieren, während die Architektur zunehmend schwerer zu durchdringen ist. Automatisierung kann manuelle Arbeit beseitigen und gleichzeitig ein Netz von Beziehungen erzeugen, von dem niemand mehr ein vollständiges mentales Modell besitzt. Die Maschinerie verbessert sich, aber es gibt kein Gesetz, nach dem die Steuerung im gleichen Maß besser werden müsste.

So formuliert klingt das offensichtlich, trotzdem verhält sich ein erheblicher Teil der Technologiebranche noch immer so, als wäre Beschleunigung ein Beleg für Reife. Ein System, das eine schlechte Entscheidung in einer statt in zehn Minuten ausführen kann, ist nicht zehnmal besser geworden. Es ist nur zehnmal schneller darin geworden, eine schlechte Entscheidung auszuführen.

Besonders schwer zu erkennen wird das Problem, wenn jede der lokalen Optimierungen tatsächlich einzeln funktioniert. Jedes Team kann zeigen, dass seine Version besser läuft als vorher, jede einzelne Änderung lässt sich begründen, jedes Dashboard kann grün sein. Und trotzdem kann das Gesamtsystem schwerer zu ändern, schwerer zu erklären und schwerer zu kontrollieren sein, weil jede Verbesserung die Zahl der Wechselwirkungen erhöht hat, die irgendjemand anderes verstehen muss.

An diesem Punkt hört Geschwindigkeit auf, nur ein Vorteil zu sein, und beginnt all das zu verstärken, was das System falsch macht.