// ActionNote
Kein stilles Überschreiben
Warum eine idempotente Deploy-Pipeline Sabines Schnellfix lautlos überschrieb — und welche Annahme über menschliches Verhalten hinter diesem Architektur-Fehler steckt.
Veröffentlicht: 30. April 2026 · Holger Theymann
Bei Kilometer 30 hatte ich gedacht, ich hätte das Problem gelöst. Sechs Stunden später machte Sabine den Anruf, und ich saß mit einem Kaffee in der Küche und verstand nichts mehr.
"Holger, der Bereich, wo du gestern was geändert hast — ist weg."
// Der Code hat funktioniert. Das ist das Problem.
Wir hatten es vereinbart: Edits laufen über das Repo, die WordPress-Oberfläche fasst nichts an, denn die Repo-Pipeline überschreibt beim Deployment sowieso alles. Eine Quelle, eine Wahrheit. Das stand im Onboarding-Doc, drei Zeilen lang, fett gedruckt.
Sabine hatte das Onboarding-Doc gelesen und es verstanden. Und gestern Nachmittag, fünfzehn Minuten bevor der Klient zur Tür reinkam, fiel ihr auf, dass im Footer noch das alte Datum stand. Also hat sie WordPress aufgemacht, das Datum geändert, gespeichert. Drei Sekunden Arbeit. Dann hat sie noch zwei andere Stellen mitgenommen, die sie eh schon länger korrigieren wollte. Der Klient kam, alles war gut.
In der Nacht lief das Deployment und fraß, was Sabine geschrieben hatte. Der Log zeigte grün.
// Niemand hat das System missbraucht. Es wurde benutzt.
Mein erster Reflex war Ärger, und ich erkannte ihn sofort als das, was er war: die Verteidigungsbewegung von jemandem, der entdeckt, dass sein Bauwerk eine Annahme enthält, die er nicht hätte machen dürfen. Die Annahme: Wenn ich den Mitarbeitern erkläre, wie das Protokoll geht, halten sie es ein. Eine Annahme über Menschen, formuliert von jemandem, der zu lange nur mit Maschinen geredet hatte.
Das war nicht Sabines Fehler im Sinne von Unkenntnis — sie kannte die Absprache. Sie hat das Protokoll gebrochen, weil ein Klient vor der Tür stand und der schnellste Weg zwischen Problem und Lösung durch die WordPress-Oberfläche führte. Genau dafür ist diese Oberfläche da. Ich hatte ein System gebaut, das davon ausgeht, dass ein Mensch unter Zeitdruck den unbequemeren Weg wählt.
// Das System war perfekt — nur Menschen sind es nicht. Ungehorsam war nicht einkalkuliert. Das musste ich ändern.
Was hier verhandelt wird, ist nicht der Workflow. Was verhandelt wird, ist: wer hört wem zu? Bisher war die Antwort: Sabine hört dem System zu. Das ist die Richtung, in die Software meistens gebaut wird, und sie fühlt sich wie Effizienz an — solange man das System ist und nicht der Mensch davor.
Konkret steckt das in einer Entscheidung, die ich damals für selbstverständlich hielt: Darf eine WordPress-Eingabe das Repo informieren, oder darf das Repo die WordPress-Eingabe ignorieren? Ich hatte das zweite gebaut, weil es technisch eleganter war. Für mich. Für Sabine bedeutet es, dass ihre Arbeit lautlos verschwindet und sie heute Morgen anrufen muss, um zu fragen, ob sie etwas falsch gemacht hat.
Der Lauf heute Morgen war nicht der Ort, an dem ich das gelöst habe. Der war der Ort, an dem ich aufgehört habe, mich zu verteidigen.
Heute Nachmittag baue ich den Sync-Pfad. Bidirektional. Mit Konfliktanzeige, nicht mit stillem Overwrite.
// Häufige Fragen
Warum überschreibt das Deployment die WordPress-Änderungen?
Hätte eine bessere Dokumentation das verhindert?
Was ist der Unterschied zwischen Optimistic und pessimistischem Locking?
// Quellen
- Microsoft Learn: Human-in-the-Loop Workflows [documentation]
- Martin Fowler: Optimistic Offline Lock [whitepaper]
- IEEE Digital Privacy: Architecting Privacy by Design: From Concept to Application [whitepaper]
- Hollnagel, E.: From Safety-I to Safety-II: A White Paper . NHS England (2015) [whitepaper]
- Alper, E. et al.: Nursing Documentation Time After Implementation of an Electronic Health Record . BMC Medical Informatics and Decision Making (2019) [study]