Meetings durch langsame Deployments (2015)
(tidyfirst.substack.com)- In Situationen, in denen Engineers das Gefühl haben, wegen zu vieler Meetings keinen Code ausliefern zu können, könnte die eigentliche Ursache langsame Deployment-Fähigkeit und der dadurch entstehende organisatorische Overhead sein
- Chuck Rossi von Facebook meint, dass die Anzahl der Änderungen, die ein einzelnes Deployment verkraften kann, nahezu fest zu sein scheint; wenn man mehr Änderungen unterbringen will, muss man häufiger deployen
- Facebook erhöhte die Deployment-Frequenz für PHP-Code von wöchentlich auf täglich und schließlich auf 3-mal pro Tag; auch der Release-Zyklus für mobile Apps wurde von 6 Wochen auf 4 und dann auf 2 Wochen verkürzt, hauptsächlich vorangetrieben vom Release-Engineering-Team
- Wenn das Änderungsvolumen die Deployment-Grenze überschreitet, steigt die Zahl der Änderungen pro Deployment nicht ohne Weiteres; stattdessen passt sich die Organisation an, indem Overhead wie Meetings, Reviews und Handoffs zunimmt und so das Gesamtvolumen an Änderungen sinkt
- Um mehr Änderungen durchzubekommen, reicht es nicht, nur Meetings zu reduzieren; man muss Deployment-Kapazität aufbauen, indem man Deployment-Zyklen, Tests, Monitoring, Isolation und die sozialen Beziehungen im Team verbessert
Meetings sind möglicherweise nicht die Ursache, sondern das Ergebnis
- Die häufige Klage „Wegen der vielen Meetings kann ich keinen Code deployen“ könnte die Kausalität umdrehen
- Organisatorischen Overhead hinzuzufügen oder zu entfernen ist vergleichsweise einfach, die Fähigkeit einer Organisation, Code zu deployen, zu erhöhen hingegen deutlich schwieriger
- Meetings und Reviews könnten das Ergebnis einer organisatorischen Anpassung sein, damit das Deployment-System nicht überlastet wird
- Chuck Rossi beobachtete bei Facebook, dass die Zahl der Änderungen, die ein einzelnes Deployment verarbeiten kann, offenbar begrenzt ist
- Wenn man mehr Änderungen will, braucht man mehr Deployments
- PHP-Code-Deployments wurden von wöchentlich auf täglich und dann auf 3-mal pro Tag erhöht
- Der Release-Zyklus mobiler Apps wurde von 6 Wochen auf 4 und dann auf 2 Wochen verkürzt
- Diese Verbesserung wurde hauptsächlich vom Release-Engineering-Team vorangetrieben
Ohne mehr Deployment-Kapazität wächst der Overhead
- Die „Anzahl der Änderungen pro Deployment“ wirkt wie eine unelastische Kennzahl, die sich nicht leicht erhöhen lässt und nur mit großem Aufwand verbessert werden kann
- Wenn die erzeugte Menge an Änderungen die aktuelle Grenze überschreitet, entsteht eher Druck, das gesamte Änderungsvolumen zu senken, statt die Zahl der Änderungen pro Deployment zu erhöhen
- Meetings, Reviews, Handoffs und anderer Overhead nehmen zu
- Mit der Zeit können auch Begeisterung und Eigeninitiative abnehmen
- Mehr Overhead kann eine positive Feedback-Schleife erzeugen
- Weniger Arbeit wird verarbeitet
- Der Druck steigt
- Fehler nehmen zu
- Die Zahl der Änderungen pro Deployment sinkt weiter
- Der Overhead nimmt erneut zu
- Isolierte Versuche, nur den Overhead zu senken, können den Druck erhöhen und dadurch den Overhead wieder anwachsen lassen
- Um mehr Änderungen durchzuschleusen, muss man das Deployment-Kapazität als „fernes Ende des Schlauchs“ erweitern
- Der schwierige Weg: Deployment-Zyklen verkürzen und das daraus entstehende Chaos bewältigen
- Der noch schwierigere Weg: die Zahl der Änderungen pro Deployment durch bessere Tests, besseres Monitoring, stärkere Isolation zwischen Komponenten und bessere soziale Beziehungen im Team erhöhen
- Allein der Versuch, Meetings zu reduzieren, kann zu „Meetings darüber, wie man Meetings reduziert“ führen
- Das lässt sich als Beispiel für einen Reverse-Causality-Thinkie verstehen, bei dem eine zunächst falsch wirkende Idee bewusst platziert wird
2 Kommentare
Das ist eine gute Meinung.
Meinungen auf Hacker News
Leider scheint mir die Schlussfolgerung dieses Beitrags etwas verkehrt herum zu sein. Es ist wichtig, das Deployment-Risiko durch bessere Tests und organisatorische Eigenschaften zu senken, aber das ist nicht der einzige funktionierende Ansatz.
Der Autor sagt, die Zahl der Änderungen pro Deployment sei festgelegt und schwer zu erhöhen; das hier gemeinte „Reverse Thinkie“ ist meiner Ansicht nach vielmehr, die Zahl der Änderungen pro Deployment zu reduzieren. Der Grund, warum es Deployment-Meetings gibt, ist Risiko, und je mehr Änderungen in einem Deployment stecken, desto höher ist die Wahrscheinlichkeit, dass Bugs oder Betriebsprobleme hineingeraten. Wenn man kleine Änderungen häufig deployt, liefert man Wert schneller aus und macht auch Fehlschläge kleiner.
Kombiniert man das mit Canary Deployments und schrittweisem Rollout, wird Deployment nicht mehr zu einer Frage des Schalters, der etwas kaputtmacht oder nicht, sondern zu einer Welt, in der Ausfälle in Leistungsabfall oder begrenzte Auswirkungen umgewandelt werden. Dieser Ansatz wird auch in der DORA-Forschung[0], in Accelerate[1], The Phoenix Project[2] und dessen geistigem Vorläufer The Goal[3] gut behandelt.
[0] https://dora.dev/
[1] https://www.amazon.co.uk/Accelerate-Software-Performing-Tech...
[2] https://www.amazon.co.uk/Phoenix-Project-Helping-Business-An...
[3] https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp...
Entscheidend ist, wie viel Zeit und Ressourcen eine Organisation in automatisierte Tests investiert. Release-Meetings entstehen, weil die Infrastruktur fehlt, um vor und nach dem Deployment zu verifizieren und fehlgeschlagene Änderungen zurückzurollen; der Mangel an automatischer Verifikation wird dann durch provisorische manuelle Checks aufgefüllt. Wenn der QA-Organisation technische Fähigkeiten fehlen, drängt sie aus Selbsterhaltungstrieb auf manuelle Abläufe.
Schlimmer noch: Manchmal wird die Teilnahme an solchen Meetings als Zeichen von Exzellenz und Best Practice verkauft. Denn Menschen, die eingestellt wurden, um ein Problem abzumildern, haben keinen Anreiz, dieses Problem grundlegend zu beseitigen. Wenn Bugs in die Produktion gelangen, wird daraus „ein von Entwicklern verursachtes Problem, das QA aus diesen oder jenen Gründen nicht gefunden hat“; mit automatisierten Tests ist es dagegen schon in der PR-Phase schwer, so etwas überhaupt zu übersehen.
Meetings entstehen nicht wegen des Risikos, sondern weil es in der Organisation Rollen gibt, die Risiko als Existenzgrund brauchen und denen die Technik fehlt, es zu reduzieren. Wenn man nach dem Deployment minimal automatisiert prüfen kann, ob die Änderung ausgeführt wurde und funktioniert, und bei Fehlschlägen automatisch zurückrollen kann, werden Meetings überflüssig.
Viele dieser Prozesse sind meiner Ansicht nach rationale, aber nichttechnische Reaktionen, um eine schlechte Situation möglichst erträglich zu machen, wenn es keine grundlegende Lösung gibt. Ganz harmlos sind sie allerdings nicht. In manchen Organisationen haben Entscheider auch bei neuen Projekten oder Projekten zur Beseitigung bestehender Ineffizienz immer wieder menschenzentrierte Prozesse als Lösung vorgeschoben.
Das liegt an mangelnder technischer Vorstellungskraft oder daran, dass man im bisherigen Problem-Frame gefangen ist; deshalb müssen Menschen mit dieser Vorstellungskraft sagen, dass menschliche Prozesse dort, wo es möglich ist, durch technische Änderungen minimiert werden sollten. Nicht alle menschlichen Prozesse lassen sich durch Technik beseitigen, aber ich möchte mich nicht dünn über unnötige Dinge verteilen.
Man könnte annehmen, dass es „zu viel“ ist, in einem bestimmten Zeitraum mehr als 2 % aller Prozesse zu ändern; dieser Wert lässt sich anpassen. Er dürfte auch je nach Bereich unterschiedlich sein, daher sollten das Team für Zahlungsabwicklungs-Code und das Team für HR-Code unterschiedliche Maßstäbe haben, und es kann sinnvoll sein, Releases oder Teams rotieren zu lassen.
In diesem Zeitraum übernimmt dieses Team die schwierige Arbeit, und wenn sie live ist, wechselt es wieder zu leichterer Arbeit. Dasselbe Prinzip gilt für Grabenangriffe, Vormärsche von Bataillonen und Operationen verbundener Waffen.
Natürlich ist das ein Managementproblem, aber es lässt sich zu einem guten Teil automatisieren, und sensorische Eingaben wie die Frage, welches Team zuletzt an sensiblen Modulen committet hat, sind ebenfalls nützlich. Schließlich macht diese Sichtweise die Sprints in Agile/Scrum merkwürdig. Wenn man weiß, dass man nicht den ganzen Marathon im Sprint laufen kann, wie rotiert man dann die Vorbereitung auf Sprints?
Man kann Feature Flags verwenden, aber dann entsteht ein „Backlog nicht aktivierter Features“. Am Ende werden Features meist von Menschen konsumiert, und Menschen brauchen Schulung für Veränderungen.
Er hat sich schon lange, bevor irgendjemand The Phoenix Project schrieb, mit Flow beschäftigt, die Prinzipien des Toyota Production System übersetzt und Physik auf Geschäftsprozesse angewandt. Ich mag The Phoenix Project ebenfalls, aber im Vergleich zu The Goal ist es eher eine billige Adaption, die Leute aus der IT-Branche davon abhält, Geschichten über Produktionslinien zu lesen und davonzulaufen mit „Ich bin PrOgrAmmEr, kreative Arbeit kann man nicht wie eine Fabrik optimieren“.
Deshalb ist The Phoenix Project der geistige Nachfolger von The Goal, nicht umgekehrt.
Ich möchte versuchen, das Konzept der „Software Literacy“ zu erklären. Es bedeutet, dass ein Unternehmen heute, so wie es mit englischen Texten wie Richtliniendokumenten und E-Mails betrieben werden kann, auch mit Code betrieben werden kann.
Daraus ergeben sich Schlussfolgerungen wie „Wenn GPUs die Arbeit machen, sind Coder die neuen Manager“ oder dass man eine unternehmensweite Testvorrichtung braucht, damit die Auswirkungen von Änderungen klar sind. Das scheint auch direkt mit diesem hervorragenden Artikel zusammenzuhängen. Wenn nicht alle Entscheider Code als First-Class-Objekt im Änderungsprozess sehen, statt Jira oder Projektpläne, dann sind diese Entscheider softwareseitig nicht literate.
Die Frage „Wie diskutiert man das mit nichttechnischen Führungskräften?“ kommt oft auf, und die Antwort lautet: gar nicht. Diese Führungskräfte müssen sich ändern. Das ist eine gewaltige Generationenbarriere, die ich schon vor 30 Jahren für ein Problem hielt, aber naiv dachte, sie würde verschwinden, sobald Coder nachrücken. Weil man aber nicht coden können muss, um ein Unternehmen zu „führen“, wird sie schwer zu überwinden sein, solange es nicht peinlich ist, nicht coden zu können, so wie es für einen Zeitungsredakteur peinlich wäre, nicht schreiben zu können.
Der Kern ist, dass wir Unternehmen brauchen, die mit einem neuen, sich gegenseitig verstärkenden Begriffssatz betrieben werden können – nicht SOPs, Tests und Meetings, sondern Systeme als Kommunikation.
Allerdings weiß ich nicht, warum man das „Literacy“ nennt. Maturana & Varelas Begriff Autopoiesis liegt näher am Kern, und Stafford Beers Autopoietic Systems könnten ebenfalls eine gute intellektuelle Grundlage liefern.
Andererseits sieht ein reines Software-„Business“ irgendwann einfach wie SaaS aus, oder?
Organisationen werden Versuche, Deployments zu verbessern, aktiv blockieren. Sie sagen mit ernster Miene Dinge wie „Jenkins darf nicht in die Nähe der Produktionsumgebung“, „Ohne QA können wir nicht live gehen“ oder „Wir brauchen diese Zeit, um die Softwarequalität ausreichend sicherzustellen“.
Gleichzeitig gibt es im Betrieb Millionen von Bugs, und das Produkt erfüllt die Nutzeranforderungen kaum. Am Ende ist es in den meisten Organisationen praktisch unmöglich, gegen die Bürokratie zu kämpfen. Besonders dann, wenn man nicht zu den 200 Management-Schichten gehört, die solche Meetings überhaupt erzeugen.
Ich würde am liebsten alle außer etwa zwei Programmierern und Designern hinauswerfen und sie das unter sich ausfechten lassen – ohne Agile Coaches, Product Owner, Scrum Master oder Produktexperten. Langsame Deployments sind ein Problem, aber nicht das Problem selbst.
Wenn man immer wieder an Orte gerät, die sich nicht verändern lassen, sollte man im Vorstellungsgespräch gezielter danach fragen. In kleineren Unternehmen gab es viele, die passend zu meinen Vorlieben keine verrückte Bürokratie hatten, und auch jetzt in einem Großunternehmen bewegt sich vieles langsam in die richtige Richtung, wenn man konsistent und überzeugend vorgeht.
Man muss verstehen, dass Dinge Zeit brauchen, nachvollziehen, warum Menschen sie so eingerichtet haben, und dann überzeugende Argumente finden, um sie zu verbessern. Es gibt wirklich schlechte Orte, und dort sollte man tatsächlich nicht bleiben, aber Verzweiflung hilft wenig.
Da gäbe es viel zu entwirren, aber meine Voreingenommenheit geht in Richtung dieser Behauptung.
Jenkins ist das Wordpress der Softwareentwicklung. Es ist eine riesige zustandsbehaftete Schleife, die Plugins ohne Rechte-Trennung ausführt. Einer Jenkins-Instanz Produktions-Admin-Credentials zu geben, kann gleichbedeutend damit sein, irgendeiner Person in Rumänien, die ein nie auditiertes Plugin gebaut hat, Root-Schlüssel zu geben. Es ist völlig nachvollziehbar, dass das nicht alle wollen.
„Ohne QA können wir nicht live gehen“ ebenso. Wenn man etwas in Produktion deployt, das nie durch QA gegangen ist, wozu gibt es QA dann? Um es später zu reparieren? Wenn man QA keine Befugnisse gibt, hat QA weder die Chance, gute Arbeit zu leisten, noch die Chance, stolz auf die eigene Arbeit zu sein.
Bei jeder Initiative führte Jenkins vom ersten Tag an bis in die Produktion, oft direkt mit trunkbasierter Entwicklung, und Qualität lag in der Verantwortung aller Entwickler. Auf Ebene einzelner Beitragender gab es keinen „Kampf gegen Bürokratie“, auch wenn Führungskräfte wohl gelegentlich heftig diskutierten, wenn externe Partner und Stakeholder tief eingebunden waren.
Nur Programmierer und Designer übrig zu lassen, klingt für mich angenehm, skaliert aber nicht. Es braucht mindestens eine Person als Produkt-„Owner“, „Experte“ oder „Manager“, die Stakeholder-Prioritäten in eine Queue bringt. Diese Rolle kann auch als „Hut“ abwechselnd von Entwicklern und Designern getragen werden, aber manche Menschen sind in dieser Fähigkeit außergewöhnlich gut.
Ich verstehe auch, dass viele Organisationen nicht so arbeiten. Wenn man ein Unternehmen in diese Richtung verändert, hat es geholfen, ein einzelnes experimentelles Team auf freiwilliger Basis aufzubauen, das sich diesen Praktiken verschreibt, und es durch von oben verliehene Autorität zu schützen, ohne es zu steuern. Natürlich ist das hier California.
Etwas am Rande verwandt: Ich habe einmal an einem Ort gearbeitet, an dem die CI-Pipeline etwa 25 Minuten dauerte und davon über 3000 Unit-/Integrationstests 18 Minuten beanspruchten.
Jedes Mal, wenn in Produktion ein Problem auftrat, wurden weitere Tests hinzugefügt, und natürlich brauchte die Wiederherstellung, wenn etwas schiefging, mindestens 50 Minuten. Nach langem Nachdenken beschlossen wir, uns auf Recovery zu konzentrieren, lockerten und vereinfachten einige Tests, brachten alles auf unter 5 Minuten und nutzten Canary-Deployments statt Rolling Updates.
Für uns war das eine wirklich erfrischende Erfahrung, aber in gewisser Weise fühlte es sich auch falsch an.
Natürlich steckt in dieser Deployment-Geschwindigkeit allerlei mit drin, aber fast alles davon sind gute Dinge.
Etwas am Rande: Warum ist CloudFormation so langsam?
Es gab einen Fall, in dem eine Lambda in einer VPC gelöscht wurde, die mit EFS verbunden war. Das Deployment selbst war ziemlich schnell, aber CloudFormation brauchte etwa 20 Minuten, um aufzuräumen und fertig zu werden.
Jedes Mal, wenn Zustandsänderungen transaktional ausgerollt werden, müssen in jedem Schritt Vorbedingungen und Nachbedingungen geprüft werden. Wenn man ein Bündel von Änderungen veröffentlichen will, die auch nur ein wenig voneinander abhängen, bleibt einem nichts anderes übrig, als jede Änderung in sequenziellen Schritten auszurollen. Jeder Schritt macht mehrere Netzwerkaufrufe, um die Änderung anzuwenden, zu authentifizieren und den Zustand abzufragen; jeder davon dauert etwa 50–200 ms, und das summiert sich schnell.
Wenn man dieselbe App mit Terraform oder Ansible bei einem anderen Cloud-Anbieter ausrollt, kommt man zu ähnlichen Ergebnissen. Dieselbe Änderung manuell auszurollen, macht aus ein paar Minuten einen ganzen Tag Plackerei.
Das größte Problem von IaC ist, dass es zu High-Level ist und intern zu viel erledigt, sodass es Leute gibt, die nicht wissen, welche Änderungen tatsächlich angewendet werden oder was gerade passiert. Und dann beschweren sie sich, dass es lange dauert.
Ich habe dazu persönlich etwas im Berufsleben erlebt. Vor dem Weihnachtsurlaub gab es eine große Änderung, und die Angst war groß. Die Organisation reagierte, indem sie mehr Tests einführte, also mehr Regressionstests, was den Overhead erhöhte.
Dadurch stieg das Risiko, dass Änderungen in dev meine Änderungen in meinem Branch kaputtmachen. Es ging nicht um Code-Merge-Konflikte, sondern um ein Risiko aus Sicht eines komplexen adaptiven Systems. Als Reaktion auf dieses Risiko setzte ich Meetings an und erklärte den Kollegen bei der Vorstellung des Projektplans die Erwartung: Wenn sie in PRs Kommentare zum Code-Stil hinterließen, würden diese auf spätere PRs verschoben und am Ende ignoriert.
Was nötig gewesen wäre, waren feingranulare Tests mit besserer Isolation zwischen Komponenten. Das Problem ist, dass das Management nur auf einer viel zu hohen Ebene hinschaut und Meetings nicht als Mittel, sondern als an sich erstrebenswertes Ziel betrachtet. Mehr Meetings bedeuten mehr Zusammenarbeit, und das sei gut. Ich würde gern Ratschläge dazu sehen, wie man technische Veränderungen mit nichttechnischem Management vorantreibt.
Verwandter Beitrag: Slow Deployment Causes Meetings - https://news.ycombinator.com/item?id=10622834 - November 2015, 26 Kommentare
Mit Microservices kann man auch die Deployment-Frequenz horizontal skalieren.
Mit einer monolithischen App aus unabhängigen Modulen kann man genauso oft deployen wie mit Microservices, ohne deren Hauptnachteile: die Komplexität von Infrastruktur/CI/CD und die Umwandlung von Funktionsaufrufen in der App in unzuverlässige Kommunikationsprobleme verteilter Systeme. Unnötiger akzidenteller Komplexität sollte man widerstehen.
[1] https://www.fearofoblivion.com/build-a-modular-monolith-firs...
[2] https://ardalis.com/introducing-modular-monoliths-goldilocks...
Und man bekommt das schöne neue Problem der Deployment-Planung und der Synchronisierung von Feature-Releases.
Andernfalls bekommt man gleichzeitig die Probleme verteilter Daten und zusätzliche Komplexitätsstufen, also mehr Meetings als beim Monolithen.
Bei einem Monolithen besteht die Gefahr, dass man in einem riesigen Durcheinander aus SOLID, DRY und anderem „Clean Code“-Unsinn landet, in dem niemand mehr etwas ändern kann, weil er fürchtet, etwas kaputtzumachen. Das heißt nicht, dass objektorientierte Prinzipien an sich offensichtlich falsch wären, aber sie sind oft so extrem vage, dass niemand sie richtig anwenden kann.
Ich muss immer lachen, wenn Uncle Bob jede Kritik mit „Sie haben die Prinzipien missverstanden“ abtut. Wenn so viele Leute falschliegen, könnten dann nicht die Prinzipien schlecht sein? Microservices schützen auch nicht vor schlechter Governance; sie zeigen die Probleme nur in anderer Form. Es ist sehr leicht und meiner Ansicht nach häufig, mehrere Microservices zu haben, bei denen niemand weiß, welche Auswirkungen eine Änderung auf andere Services hat.
Letztlich ist es ein Team-Management-Problem, und meiner Erfahrung nach ist das genau der Bereich, in dem unsere Branche am schlechtesten ist. Mit einer neuen Generation von Ansätzen wie „Team Topologies“ wird es vielleicht besser, aber selbst wenn das wirklich gelöst wird, wird es Jahrzehnte dauern. Solange Organisationen „IT“ nur als Kostenstelle sehen und Anforderungen nicht so formulieren, dass sie in Best-Practice-Prozesse des Software Engineerings eingebunden werden können, liegt es oft auch außerhalb der Hände der Digitalisierungsabteilung.
Einer der Gründe, warum ich Go als Allzwecksprache mag, ist, dass es vom Design her einfach ist und dadurch oft zu Codebasen führt, die sich leichter ändern lassen. Ich habe gesehen, wie einige Onlinebanken und Plattformen für Vermietung/Asset-Management auf Go umgestiegen sind und dadurch wachsen konnten, weil sie tatsächlich liefern konnten, was das Business brauchte. Konkurrenten dagegen steckten in unhandlichen Java- oder C#-Codebasen fest und brachten, wenn sie Glück hatten, einmal pro Halbjahr ein fehlerbehaftetes Feature heraus.
Das ist kein Problem von Go, Java oder C# selbst, sondern davon, dass altmodische objektorientierte Architektur und Design so leicht zu vermurksen sind. An einem früheren Arbeitsplatz gab es über tausend C#-Interfaces, aber kein einziges Interface wurde von mehr als einer Klasse genutzt. Zehntausende Interfaces lagen alle im selben Ordner und Namespace, und das zu finden, was man brauchte, war reine Glückssache. So etwas kann man auch in Go oder jeder anderen Sprache tun, aber wenn man nicht in einer alten objektorientierten Clean-Code-Sprachkultur steckt, ist es weniger wahrscheinlich. Besonders in C# ist die Standardabstraktion kulturell so tief verankert, dass es schwerer ist, sie nicht zu verwenden.
Persönlich habe ich eine heimliche Zuneigung zu Python-Organisationen. Sie liefern immer schnell, und der Code ist furchtbar. Liebenswert.
Im Großen und Ganzen richtig, aber ebenso irrelevant
Kurz gesagt zählen nur die Software-Performance und damit die menschliche Performance. Risikomanagement und Risikoakzeptanz lassen sich in Zahlen messen. Bei Software ist das viel einfacher als in anderen Berufen, weil Software Engineers Risiken nur innerhalb bekannter betrieblicher Einschränkungen akzeptieren können und alles andere verschoben wird.
Wenn man schneller werden will, muss man vor allem die menschliche Iterationsfrequenz maximieren. Wenn man nicht iterieren kann, weil man auf eine Freigabe wartet, ist man blockiert; wenn man auf einen Build oder ein Neuladen des Bildschirms wartet, wird man ausgebremst. Auch das lässt sich in Zahlen messen.
Wenn A 100-mal schneller iterieren kann als B, wird Korrektheit zweitrangig. B muss Korrektheit maximieren, weil B langsam ist. A hat extreme Flexibilität, um zu lernen, zu scheitern und sich zu verbessern, um schneller und korrekter zu werden.
Ein Teil davon, schneller zu iterieren und zugleich Risiken zu reduzieren, ist schnelle Testautomatisierung. Wenn A innerhalb der Zeit von vier menschlichen Iterationen mehr als 90 % Testabdeckung ausführen kann, ist diese Testautomatisierung immer noch 25-mal schneller als eine Iteration von B, und das Regressionsrisiko ist um mehr als 90 % geringer.
Schnelle Deployments erzeugen War Rooms für Incident Response
Noch viel wichtiger als dieser Rückgang war, dass man bei Problemen die Ursache viel schneller fand. Da nur sehr wenige Änderungen zurückgerollt wurden, war auch das Zurücksetzen viel sicherer und einfacher. Niemand will Arbeit von drei Wochen zurückrollen. Das ist Chaos.