Stell dir vor: ein Entwickler hat ein Word-Dokument. 23 Schritte, mit Screenshots. Schritt 7: “Cache invalidieren (siehe Confluence-Seite ‘Cache Management’, Link funktioniert nur im VPN).” Schritt 14: “Warten bis der Health Check grün wird. Wenn nach 3 Minuten noch rot, Schritt 11 wiederholen aber diesmal mit dem Flag --force-recreate.” Schritt 19: “Kollegen fragen ob die Downstream-Consumer neu gestartet werden müssen.”
Dieser eine Entwickler kann das Deployment fehlerfrei durchführen. Er alleine. Wenn er im Urlaub ist, wird nicht deployed. Wenn er krank ist, wird nicht deployed. Wenn er mittags beim Döner ist und ein Hotfix rausmuss, wartet das Team.
Das ist kein Prozess. Das ist eine Geiselnahme.
Die Person die alles weiß
Hunt und Thomas schreiben im letzten Kapitel über pragmatische Teams. Aber das was hängen bleibt, steht zwischen den Zeilen: die gefährlichste Person in deinem Team ist nicht die schwächste. Es ist die stärkste.
Stell dir vor: ein Entwickler, Java-Backend, zieht drei Spring-Boot-Services alleine hoch. Sauber gebaut, ordentliche Test Coverage, durchdachte Hexagonal Architecture. Code Reviews? “Verlangsamt mich nur.” Pair Programming? “Ich erklär’s euch wenn’s fertig ist.” Wissen teilen? “Steht doch im Code.”
Er kündigt. Zwei Wochen Kündigungsfrist.
Danach hat das Team drei Services, die niemand anfassen kann. Der Payment-Reconciliation-Service hat eine Custom DSL für Abrechnungsregeln, die nur Sinn ergibt wenn man weiß warum bestimmte Architekturentscheidungen getroffen wurden. Das steht nirgends. Nicht in den Commits, nicht in einem ADR, nicht in Confluence. Es stand in seinem Kopf, und sein Kopf ist jetzt bei einem anderen Arbeitgeber.
Sechs Monate braucht das Team, um diese Services wieder under control zu kriegen. Sechs Monate.
“Quality is a team issue.”
Stimmt. Aber nicht so wie man denkt. Qualität heißt nicht, dass jeder im Team guten Code schreibt. Qualität heißt, dass das Team als Ganzes funktioniert, wenn eine einzelne Person morgen weg ist.
Automate Everything (naja, fast)
“Don’t use manual procedures.”
Das Word-Dokument hätte nie existieren dürfen. Das ist die Aussage von Hunt und Thomas, und in 90% der Fälle haben sie recht. Jeder manuelle Schritt ist eine Fehlerquelle. Um drei Uhr nachmittags, nach dem dritten Deployment des Tages, vergisst du den Cache zu invalidieren. Oder du führst das Migration-Script gegen Staging statt Prod aus. Oder umgekehrt. Beides schlecht.
Build: ein Befehl. Tests: bei jedem Push automatisch. Deployment: ein Knopf, Rollback ein zweiter. Infrastruktur: Terraform, nicht “ich hab das mal in der AWS Console geklickt.”
Aber.
Hunt und Thomas haben das 1999 geschrieben. Die Welt war eine andere. Und der Satz “automate everything” wird in manchen Teams zum Dogma, das mehr Schaden anrichtet als Das Word-Dokument.
Stell dir vor: ein Dreierperson-Team investiert drei Wochen in eine Terraform-Pipeline, die sie zweimal im Jahr benutzen. Die alte Methode: einer logged sich in die Console ein, klickt vier Buttons. Dauert 10 Minuten. “Aber es ist nicht automatisiert!” Richtig. Es muss auch nicht.
Automation lohnt sich wenn: der Prozess häufig ist, fehleranfällig, und mehr als eine Person betrifft. Das 23-Schritte-Dokument? Sofort automatisieren. Das jährliche SSL-Zertifikat-Renewal das drei Klicks braucht? Ein Runbook im Wiki reicht. Der Aufwand, das zu automatisieren, ist größer als der Aufwand, es dreimal manuell zu machen.
Pragmatisch heißt nicht automatisch. Pragmatisch heißt: den richtigen Aufwand an der richtigen Stelle.
Wo die Bugs wirklich leben
“Test your software, or your users will.”
Ich sollte mir den Satz über den Monitor hängen. Aber das ist nicht die Stelle die mich zum Nachdenken gebracht hat. Das hier ist sie:
Stell dir vor: zwei Services. Order-Service, Go. Billing-Service, Java. Der Order-Service schickt eine Bestellung an Billing. Feld quantity, der Order-Service schickt es als String: "3". Der Billing-Service erwartet einen Integer: 3. Auf beiden Seiten: perfekte Unit Tests. Order-Service testet, dass er das richtige JSON baut. Billing-Service testet, dass er eine Bestellung korrekt verarbeitet.
100% grün. Alles kaputt.
Weil kein einziger Test geprüft hat, was passiert wenn die beiden Services miteinander reden. Der Contract zwischen den Services das Feld quantity, sein Typ, sein Format existierte nur als implizite Annahme. Auf der einen Seite: “ist halt ein String, JavaScript-Erbe.” Auf der anderen Seite: “ist offensichtlich ein Integer.” Offensichtlich. Bis Produktion.
“Design to test.”
Hunt und Thomas meinen damit: Code der schwer zu testen ist, ist schlecht designed. Stimmt. Aber ich geh weiter. Das eigentliche Testproblem in den meisten Teams sind nicht fehlende Unit Tests. Es sind fehlende Integration Tests. Fehlende Contract Tests. Fehlende Tests an den Grenzen, wo zwei Systeme aufeinander treffen.
Die Regel daraus: teste die Nahtstellen. Nicht die Logik innerhalb eines Service, die ist meistens offensichtlich, und wenn sie es nicht ist, hast du ein anderes Problem. Sondern die Stellen wo System A eine Annahme über System B macht. Da leben die Bugs. Da explodiert Freitagabend die Produktion.
Ein Contract Test für das quantity-Feld hätte 20 Minuten gedauert. Die Produktionsstörung hat vier Stunden gekostet plus ein Postmortem plus ein Stakeholder-Call am Montag.
Broken Windows im Team
“Teams as a whole should not tolerate broken windows.”
Kennst du aus Kapitel 1, die Broken-Windows-Theorie. Auf Team-Ebene wird sie erst richtig gefährlich.
Stell dir vor: ein Entwickler fängt an, Tests zu skippen. Nicht böswillig. Zeitdruck, Sprint-Ende, “schreib ich morgen.” Morgen wird nächste Woche. Nächste Woche wird nie. Und dann sieht der nächste Entwickler, dass PRs ohne Tests durchgehen. Und der nächste. Nach drei Sprints: Coverage von 78% auf 41%. Nicht weil alle absichtlich aufgehört haben zu testen. Sondern weil ein Signal im Raum steht Tests sind hier optional.
Team-Kultur ist nicht was im Confluence-Wiki steht. Team-Kultur ist was passiert wenn Zeitdruck kommt.
Schluss
Das Buch endet mit einem Appell. Hunt und Thomas fragen, was für ein Entwickler du sein willst.
Ich finde die Frage falsch gestellt. Es geht nicht um Haltung oder Leidenschaft oder ob du “dein Handwerk ernst nimmst.” Es geht um Gewohnheiten. Schreibst du den Test oder nicht. Automatisierst du das Deployment oder lässt du es bei Das Word-Dokument. Sprichst du das Problem an oder hoffst du dass es jemand anders tut.
Die Antwort ist nicht einmal. Die Antwort ist jeden Tag.
Das war die Serie. Das Buch ist von 1999 und immer noch relevanter als die meisten Conference Talks die ich dieses Jahr gesehen hab.