Die menschlichen Kosten unlesbarer Systeme

Die menschlichen Kosten unlesbarer Systeme

Das Notizbuch neben dem Bildschirm

Die wichtigste Dokumentation im Raum befand sich nicht im System. Es war ein Spiralnotizbuch neben dem zweiten Monitor, zusammengehalten von Klebeband und der Autorität langen Leidens. Das Team nutzte es während jeder Abendschicht. Seite eins erklärte, welcher Status im Falltool tatsächlich „wartet auf Finanzen“ bedeutete. Seite vier listete die Namen von drei Feldern auf, die optional aussahen, es aber nicht waren. Seite sieben warnte davor, den Export-Button nach 17:00 Uhr zu drücken, weil der Nachtjob die Datei als neuen Eingang interpretieren würde und alle mit einer Warteschlange aufwachen würden, die sich wie administrative Folklore vermehrt hatte.

Die offizielle Prozessbeschreibung war aufgeräumter. Sie hatte Kästen, Pfeile und ein Datum in der Fußzeile. Sie war auch genau in den Punkten falsch, die zählten. Die Software hatte sich geändert. Der Anbieter hatte sich geändert. Eine Ausnahmegenehmigung war zur normalen Praxis geworden. Eine Integration war so oft fehlgeschlagen, dass die Mitarbeitenden ein Prüfritual erfunden hatten. Das Notizbuch war keine charmante lokale Eigenheit. Es war ein menschlicher Flicken über einem System, das sich nicht mehr selbst erklären konnte.

Unlesbare Systeme kündigen sich selten mit einem einzigen spektakulären Ausfall an. Sie erheben kleine Steuern. Eine Mitarbeiterin zögert vor dem Klick, weil der Statusname vage ist. Eine Pflegekraft ruft eine Kollegin an, weil einer Kennzahl im Dashboard die Herkunft fehlt. Ein Planer kopiert Daten in ein privates Blatt, weil der offizielle Bericht nicht vertrauenswürdig ist. Ein Entwickler vermeidet es, eine Funktion zu ändern, weil niemand weiß, wer davon abhängt. Eine Führungskraft bittet um einen Screenshot, weil der Prüfpfad technisch vorhanden und praktisch nutzlos ist. Jeder einzelne Moment ist überlebbar. Zusammen werden sie zu einem Arbeitsumfeld.

Die Kosten sind nicht nur Zeit. Es sind Aufmerksamkeit, Vertrauen, Verantwortung und schließlich Würde. Menschen werden zu Übersetzern für Systeme, die lesbar hätten sein sollen. Sie tragen verborgenes Wissen in Notizbüchern, Chatverläufen, Neben-Tabellen und Gewohnheiten. Dann wundern sich Führungskräfte, warum Veränderung langsam ist. Die Organisation ist nicht langsam, weil Menschen Verbesserungen ablehnen. Sie ist langsam, weil Verbesserung zuerst einen Sumpf aus Dingen überqueren muss, die niemand sicher lesen kann.

Unlesbar ist nicht dasselbe wie komplex

Manche Systeme sind komplex, weil die Arbeit komplex ist. Gesundheitswesen, Logistik, Sozialleistungen, Forschungsverwaltung, Fertigung und Energienetze werden nicht einfach, nur weil wir ein aufgeräumteres Diagramm zeichnen. Komplexität ist nicht der Feind. Unlesbarkeit ist es. Ein lesbares komplexes System zeigt seine Teile, benennt seine Annahmen, legt seine Übergänge offen, protokolliert seine Gründe und gibt den Bedienenden genug Kontext zum Handeln. Ein unlesbares einfaches System verbirgt seine Bedeutung hinter Labels, Nebeneffekten und glücklichem Timing. Raten Sie, welches die längeren Besprechungen hervorbringt.

Ingenieure reduzieren Lesbarkeit manchmal auf Codestil. Code ist wichtig, aber nur eine Ebene. Ein System kann aufgeräumten Code und unlesbares Verhalten haben. Es kann elegante Klassen und verwirrende Zustände haben. Es kann perfekte Benennung im Repository und eine Benutzeroberfläche haben, die Menschen zwingt, Insider-Bedeutungen auswendig zu lernen. Es kann Protokolle haben, die jedes Ereignis erfassen, und trotzdem nicht beantworten, warum eine Entscheidung getroffen wurde. Es kann Diagramme haben, die aktuell aussahen, als das Projekt finanziert wurde, und jetzt hauptsächlich als historische Fiktion dienen.

Lesbare Systeme gleichen mehrere Oberflächen aneinander an. Die Schnittstelle beschreibt den Zustand in Worten, die Menschen verwenden können. Das Datenmodell bewahrt Bedeutung, statt sie zu früh zu vereinfachen. Der Workflow benennt Übergänge und Verantwortliche. Der Code hat Tests für Geschäftsregeln, nicht nur für den glücklichen Pfad. Die Protokolle verbinden Aktion mit Ursache. Die Dokumentation spiegelt das lebende System. Das Monitoring sagt einer Betriebsperson, was sich geändert hat, nicht nur, dass Rot enthusiastischer geworden ist.

Diese Angleichung ist schwierig, weil Lesbarkeit viele Leser hat. Eine Entwicklerin liest den Code. Eine Sachbearbeiterin liest den Bildschirm. Ein Manager liest eine Warteschlange. Ein Prüfer liest einen Nachweis. Ein Benutzer liest eine Nachricht. Ein Support-Ingenieur liest ein Protokoll. Eine Regulierungsbehörde liest eine Erklärung. Ein neuer Kollege liest alles mit der stillen Beklemmung von jemandem, der gerade eine Schublade voller Kabel geerbt hat. Wenn das System nur für einen dieser Leser lesbar ist, ist es nicht lesbar genug.

Die menschliche Steuer des Ratens

Raten ist Arbeit. Es sieht nicht wie Arbeit aus, weil es oft still ist. Eine Person hält inne, erinnert sich an ein Muster, fragt eine andere Person, vergleicht zwei Bildschirme, schaut sich den Export von gestern an, prüft, ob eine Ausnahme gilt, und fährt dann fort. Nichts davon erscheint in Durchsatzmetriken. Der Fall dauerte sieben Minuten, sagt das Dashboard. Das Dashboard weiß nicht, dass drei dieser Minuten damit verbracht wurden, sich zu fragen, ob das Feld mit der Bezeichnung verifiziert bedeutet: vom Benutzer, vom System, von der Finanzabteilung oder von jemandem namens Vera, der 2022 gegangen ist.

Diese Art des Ratens erzeugt Ermüdung, weil die Mitarbeiterin sich nicht in den Prozess entspannen kann. Jeder Schritt kann versteckte Bedeutung enthalten. Das System wird zu einem Raum, in dem die Beschriftungen an den Schaltern von Menschen geschrieben wurden, die annahmen, sie wären immer in der Nähe. Betriebspersonen kompensieren, indem sie vorsichtig werden, und dann werden sie beschuldigt, widerständig zu sein. Sie sind nicht widerständig. Sie sind rational. Sie haben gelernt, dass die Schnittstelle manchmal durch Auslassung lügt.

Raten konzentriert Macht auch an den falschen Stellen. Die Person, die die wahre Bedeutung des Systems kennt, wird unentbehrlich. Das mag schmeichelhaft aussehen, bis die Person Urlaub will, den Job wechselt, krank wird oder einfach aufhört, den inoffiziellen Kompilierer institutionellen Gedächtnisses zu spielen. Ein unlesbares System macht Fachwissen versehentlich zu Geiselnahme. Niemand hat das geplant. Pläne sind nicht nötig, damit schlechte Anreize zu Architektur werden.

Die Last trifft neuere Mitarbeitende und Menschen mit weniger organisatorischer Macht am härtesten. Senior-Mitarbeitende wissen, wen sie fragen müssen. Neuere nicht. Auftragnehmende bekommen Fragmente. Support-Mitarbeitende werden angewiesen, dem Verfahren zu folgen, und entdecken dann, dass das Verfahren eine Karte einer Stadt ist, die ihre Straßen letzten Winter geändert hat. Benutzer spüren das Ergebnis als Verzögerung, Inkonsistenz oder unerklärte Ablehnung. Das System mag intern klug sein. Extern verlangt es von Menschen, seine Mehrdeutigkeit aufzunehmen.

Protokolle, die keine Geschichte erzählen

Viele unlesbare Systeme führen stolz Protokolle. Das ist gut, aber nicht ausreichend. Eine Protokollzeile kann korrekt und trotzdem nutzlos sein. Benutzer hat Status um 14:03 aktualisiert ist eine Tatsache. Sie sagt nicht, warum sich der Status geändert hat, welche Regel es erlaubt hat, welche Beweise vorlagen, ob der Übergang normal war, wer die Regel besitzt, welche Version des Workflows aktiv war oder ob ein nachgelagertes System die Änderung akzeptiert hat. Ein Haufen Fakten ist noch keine Geschichte. Es ist nur ein Haufen mit Zeitstempeln.

Operative Nachweise müssen um Fragen herum strukturiert sein, die Menschen tatsächlich stellen werden. Warum wurde dieser Fall weitergeleitet. Warum wurde dieser Datensatz gestoppt. Warum gelangte diese Modellantwort in den Workflow. Warum enthielt der Export genau diese Zeilen. Warum widersprachen sich zwei Berichte. Warum konnte dieser Benutzer jene Daten sehen. Warum hat das System sechs Stunden lang Wiederholungsversuche unternommen und dann genau in dem Moment aufgegeben, als alle nach Hause gingen. Das Protokoll sollte für jede gewöhnliche Frage keine archäologische Ausgrabung erfordern.

Gute Nachweise sind kein Luxus für Prüfer. Sie sind eine Freundlichkeit gegenüber den Betreibern. Während eines Vorfalls müssen Menschen die Suche eingrenzen können. Sie müssen wissen, welcher Zustand sich geändert hat, welche Eingabe eingetroffen ist, welche Regel ausgelöst wurde, welche Abhängigkeit versagt hat, welche Wiederherstellungsmaßnahme ergriffen wurde und was ungewiss bleibt. Wenn das System diese Fragen nicht beantworten kann, macht es Menschen unter Druck zu forensischen Analysten. Das ist in Kriminalromanen aufregend und rund um die Lohnabrechnung weniger reizvoll.

KI-lastige Systeme erhöhen den Standard. Wenn eine Modellausgabe einen Workflow beeinflusst, sollte das System die Quelle, den Prompt oder den Abrufkontext, sofern zutreffend, die Modellversion, die Darstellung von Konfidenz oder Unsicherheit, die Richtlinienprüfung, den Status der menschlichen Überprüfung und die endgültige Aktion bewahren. Es geht nicht darum, jede Interaktion zu einem Roman zu machen. Es geht darum, genügend Kontext zu bewahren, damit ein späterer Leser rekonstruieren kann, warum sich das System so verhalten hat. Andernfalls wird die Flüssigkeit des Modells zu einer weiteren unlesbaren Schicht.

Schnittstellen können Richtlinien verbergen

Eine unlesbare Schnittstelle ist oft ein Richtlinienproblem, das Pixel trägt. Eine Schaltfläche erscheint nur in manchen Fällen, aber niemand weiß, welche Regel sie steuert. Eine Warnung ist für ein Team gelb und für ein anderes rot, weil während eines Pilotprojekts eine Konfiguration geändert wurde. Ein Feld akzeptiert Freitext, weil die tatsächlichen Kategorien politisch unangenehm zu definieren waren. Eine Warteschlange ist nach Priorität sortiert, aber Priorität ist eine Formel, die niemand finden kann. Die Schnittstelle wirkt operativ. Darunter werden ungelöste Entscheidungen Klick für Klick an die Benutzer weitergegeben.

Das ist wichtig, weil Menschen Softwarezustände als institutionelle Wahrheit behandeln. Wenn der Bildschirm „abgeschlossen“ anzeigt, gehen Mitarbeiter davon aus, dass die Organisation „abgeschlossen“ meint. Wenn der Bildschirm „berechtigt“ anzeigt, könnte jemand aufgrund der Berechtigung handeln. Wenn der Bildschirm „geringes Risiko“ anzeigt, wandert die Aufmerksamkeit woanders hin. Je ernster der Workflow, desto gefährlicher wird vage Schnittstellensprache. Ein Label ist keine Dekoration. Es ist ein kleiner Vertrag zwischen dem System und der Person, die ihm vertrauen muss.

Lesbare Systeme machen Richtlinien dort sichtbar, wo sie angewendet werden. Sie zeigen, warum ein Feld erforderlich ist, was ein Status bedeutet, welche Belege eine Entscheidung stützen, was als Nächstes passiert und wie man das Ergebnis anfechten kann. Sie vermeiden Status, die wie Persönlichkeitsmerkmale klingen. Sie unterscheiden zwischen eingereicht und erhalten, geprüft und akzeptiert, blockiert und abgelehnt, überprüft und genehmigt. Diese Unterschiede wirken nur so lange banal, bis ein realer Fall davon abhängt. Dann interessieren sich plötzlich alle sehr für Substantive.

Die Oberfläche sollte auch Unsicherheit ehrlich offenlegen. Wenn ein Wert abgeleitet ist, sollte man das sagen. Wenn ein Modell eine Klassifizierung vorgeschlagen hat, sollte sie als Vorschlag markiert bleiben, bis sie akzeptiert ist. Wenn Daten veraltet sind, sollte ihr Alter sichtbar sein. Wenn eine Abhängigkeit verzögert ist, sollte der Bildschirm nicht so tun, als sei Stille ein Erfolg. Menschen können mit Unsicherheit besser umgehen, als Systeme oft annehmen. Was sie nicht sicher bewältigen können, ist Unsicherheit, die als Gewissheit getarnt ist, nur weil jemand einen aufgeräumten Bildschirm wollte.

Dokumentation ist Teil der Produktoberfläche

Dokumentation wird oft wie eine separate moralische Pflicht behandelt, ähnlich wie Zahnseide. Alle sind sich einig, dass sie wichtig ist. Dann wird das Release verschoben, das Dokument verrottet und das nächste Team liest es mit dem Gesichtsausdruck, der normalerweise abgelaufener Milch vorbehalten ist. Das Versagen liegt nicht darin, dass Menschen faul sind. Das Versagen liegt darin, dass die Dokumentation nicht stark genug mit dem System verbunden war, um Veränderungen zu überleben.

Lesbare Systeme machen Dokumentation operativ. Statusdefinitionen leben in der Nähe des Workflows. Datenwörterbücher werden generiert oder gegen Schemata geprüft. Geschäftsregeln haben Verantwortliche und Versionen. Runbooks werden bei Übungen getestet. Fehlermeldungen verlinken auf aktuelle Reparaturpfade. Architekturentscheidungen erklären Abwägungen, die zukünftige Teams sonst durch Leiden neu entdecken würden. Schulungsmaterial verwendet reale Zustände und reale Ausnahmen. Dokumentation wird zu einer Karte, die begangen wird, nicht zu einer Museumsausstellung.

Das ist kein Plädoyer für enzyklopädische Dokumentation. Zu viel Dokumentation kann ein weiteres unlesbares System sein, nur mit besseren Überschriften. Die nützliche Frage ist, welche Leser welchen Kontext im Moment des Handelns benötigen. Ein Sachbearbeiter braucht andere Details als eine Entwicklerin. Eine Prüferin braucht andere Belege als ein Nutzer. Ein Support-Ingenieur braucht einen Wiederherstellungspfad, nicht um 02:00 Uhr eine Philosophie verteilter Systeme. Gute Dokumentation respektiert die Aufgabe der Leserin.

Wartung ist das entscheidende Wort. Wenn Dokumentation keine Verantwortlichen, keinen Überprüfungsauslöser, keine Verbindung zu Änderungen und keinen Test im realen Einsatz hat, ist sie keine Dokumentation. Sie ist Optimismus in Absätzen. Das Notizbuch neben dem Bildschirm hat bewiesen, dass Menschen dokumentieren, was sie verstehen müssen. Die Aufgabe besteht darin, dieses Wissen aus privaten Überlebenswerkzeugen in gemeinsame, gesteuerte, lebendige Oberflächen zu überführen.

KI fügt eine neue Art von Unlesbarkeit hinzu

KI-Systeme können Unlesbarkeit teurer machen, weil sie bereits unklaren Arbeitsabläufen flüssiges Verhalten hinzufügen. Ein Modell kann zusammenfassen, einstufen, klassifizieren und empfehlen. Wenn das umgebende System nicht zeigen kann, welche Quelle verwendet wurde, welche Richtlinie die Antwort eingeschränkt hat, welche Unsicherheit verbleibt und wer die Ausgabe akzeptiert hat, wird die Flüssigkeit des Modells zur Tarnung. Der Satz liest sich gut. Die Institution kann die Handlung trotzdem nicht erklären.

Eine besondere Gefahr liegt in Modellausgaben, die präzise wirken, ohne betrieblich verankert zu sein. Ein Risikowert, ein Konfidenzprozentsatz oder eine Zusammenfassung kann sich wie Klarheit anfühlen. Aber Klarheit für wen. Wenn der Wert nicht an eine Entscheidungsgrenze, Belege, Kalibrierungshistorie, Überprüfungsprozess und Konsequenz gebunden ist, wird er zu einer dekorativen Zahl. Dekorative Zahlen sind beliebt, weil sie Dashboards größer wirken lassen. Sie sind weniger beliebt, nachdem sie einen echten Menschen in die falsche Warteschlange geleitet haben.

Lesbare KI-Operationen erfordern dieselben alten Tugenden, nur mit weniger Geduld für Luftschlösser. Benennen Sie den Quellensatz. Dokumentieren Sie Modell- und Prompt-Versionen, wo relevant. Halten Sie Retrieval-Spuren in angemessenen Grenzen. Trennen Sie Vorschlag von Aktion. Zeigen Sie, wann ein Mensch eine Ausgabe akzeptiert, geändert oder abgelehnt hat. Überwachen Sie Drift. Bewahren Sie Beschwerdewege. Machen Sie Verweigerung sichtbar. KI beseitigt nicht die Notwendigkeit von Lesbarkeit. Sie erhöht die Kosten, wenn sie fehlt.

Das Ziel ist nicht, jedes interne Gewicht offenzulegen oder Mitarbeiter in technischem Abgas zu begraben. Das Ziel ist, die operative Kette verständlich zu machen. Ein Mitarbeiter sollte wissen, warum das System diesen Fall vorgeschlagen hat, welche Belege es verwendet hat, was der Vorschlag tun darf und wie man ihn anfechten kann. Ein Prüfer sollte genug Kontext abspielen können, um die Entscheidung zu bewerten. Ein Benutzer sollte nicht hinter einer schönen Antwort gefangen sein, für die niemand verantwortlich ist.

Unlesbarkeit wird Kultur

Nach einer Weile verändert ein unlesbares System, wie eine Organisation denkt. Menschen hören auf zu fragen, warum, weil warum zu teuer ist. Sie fragen, wer es weiß. Sie hören auf, Verbesserungen vorzuschlagen, weil jede Änderung eine unsichtbare Abhängigkeit stören könnte. Sie schaffen inoffizielle Prozesse, weil offiziellen nicht zu trauen ist. Sie schützen sich mit Screenshots. Sie planen Besprechungen, um Berichte abzugleichen, die von vornherein hätten übereinstimmen müssen. Das System hat sie trainiert, ihre Erwartungen zu senken.

Diese Kultur ist von oben schwer zu sehen. Die Führungsebene sieht möglicherweise stabile Ausgaben und nimmt an, das System funktioniere. Die Ausgabe ist stabil, weil Menschen Instabilität absorbieren. Sie übersetzen, prüfen, reparieren, erinnern und entschuldigen sich. Wenn diese Anstrengungen unsichtbar sind, werden sie schließlich wegoptimiert, was eine elegante Art ist, Kompetenz in Vorfall-Rückstau zu verwandeln. Die Organisation lernt dann, dass das System doch nicht stabil war. Es wurde von Menschen zusammengehalten, denen man sagte, sie seien ineffizient.

Lesbare Systeme haben einen anderen kulturellen Effekt. Sie erlauben Menschen, dem System zu widersprechen, weil sie seine Behauptungen sehen können. Sie machen Schulung weniger abhängig von Folklore. Sie reduzieren Angst vor Veränderung, weil Abhängigkeiten benannt sind. Sie schaffen bessere Gespräche zwischen Politik, Betrieb und Technik. Sie erlauben Support-Mitarbeitern, Nutzer zu beantworten, ohne Theologie um Statuscodes zu erfinden. Sie machen Fehler leichter eingestehbar, weil die Ursache nicht in einem Labyrinth versteckt ist.

Es gibt hier eine moralische Dimension, aber sie ist nicht abstrakt. Wenn ein System einen Mitarbeiter für Ergebnisse verantwortlich macht, ihm aber den Kontext verweigert, um das System zu verstehen, ist das unfair. Wenn ein System einen Nutzer einer Entscheidung unterwirft, die niemand erklären kann, ist das unfair. Wenn ein System ein Team undokumentiertes Risiko tragen lässt, bis etwas bricht, ist das unfair. Lesbarkeit ist keine kosmetische Freundlichkeit. Sie ist Teil verantwortungsvoller Delegation.

Für Lesende bauen

Ein lesbares System wird mit den Lesenden im Blick gebaut. Das klingt offensichtlich, bis man zählt, wie viele Systeme für Schreibende, Anbieter, Frameworks oder Kompromisse in Gremien gebaut werden. Die lesende Person ist diejenige, die das System im Moment des Handelns verstehen muss. Manchmal ist das eine Entwicklerin. Manchmal eine Mitarbeiterin im Callcenter. Manchmal eine Prüferin. Manchmal eine Nutzerin, die eine Ablehnung erhält. Manchmal eine Führungskraft, die entscheidet, ob eine Warteschlange sicher ist. Lesbarkeit beginnt damit, diese Lesenden zu benennen und die Fragen, die sie beantwortet haben wollen.

Für jeden bedeutsamen Zustand sollte das System sagen können, was er bedeutet, wie er erreicht wurde, wem er gehört, welche Belege ihn stützen, was als Nächstes passiert und wie er korrigiert werden kann. Für jeden wichtigen Übergang sollte es Ursache, Handelnde, Regel, Version und Folge bewahren. Für jede Automatisierung sollte es Empfehlung von Entscheidung unterscheiden. Für jeden Bericht sollte es die Herkunft zeigen. Für jede Ausnahme sollte es die zuständige Stelle benennen. Nichts davon ist glamourös. Es ist die Grundvoraussetzung dafür, Arbeit an eine Maschine zu übergeben, ohne die Menschen um sie herum aufzugeben.

Es gibt Abwägungen. Mehr sichtbare Details können überfordern. Mehr Struktur kann die frühe Auslieferung verlangsamen. Mehr Belege können Fragen zu Speicherung und Datenschutz aufwerfen. Präzisere Sprache kann Meinungsverschiedenheiten offenlegen, die zuvor verborgen waren. Das sind echte Kosten. Sie sind aber bessere Kosten als die versteckte Arbeit, ein unlesbares System für immer zu entschlüsseln. Die Antwort ist nicht, überall alles anzuzeigen. Die Antwort ist, Bedeutung auf der Ebene verfügbar zu halten, auf der Entscheidungen getroffen werden.

Das Spiralnotizbuch sollte nicht romantisiert werden. Es war ein Zeichen von Sorgfalt, aber auch ein Symptom des Scheiterns. Die Menschen hatten getan, was gute Arbeitnehmende tun: Sie hatten die Arbeit geschützt. Das System hatte getan, was unlesbare Systeme tun: Es machte diesen Schutz privat, fragil und ungerecht verteilt. Ein menschliches System hätte aus dem Notizbuch gelernt und sein Wissen nach Hause geholt.

Das Versprechen der Lesbarkeit

Das Versprechen der Lesbarkeit ist bescheiden. Es macht nicht jeden Prozess einfach. Es nimmt niemandem das Urteilsvermögen. Es verhindert nicht jeden Fehler. Es befreit Organisationen nicht von Meinungsverschiedenheiten, denn noch hat keine Software das Gremium als Lebensform besiegt. Was es tut, ist, den Menschen ein faireres Verhältnis zu den Systemen zu geben, die sie bedienen. Es lässt sie Zustände, Gründe, Belege, Zuständigkeiten und nächste Schritte sehen.

Diese Fairness hat praktischen Wert. Die Einarbeitung wird schneller. Vorfälle werden enger begrenzt. Prüfungen werden weniger theatralisch. Veränderungen werden weniger beängstigend. Nutzende erhalten klarere Erklärungen. Ingenieurinnen und Ingenieure können Code mit besserem Wissen über die Folgen ändern. Führungskräfte sehen, wo Arbeit blockiert ist, statt wo ein Dashboard Ruhe erfunden hat. Das System wird weniger abhängig von privatem Gedächtnis und mehr von geteilter Wahrheit.

Der menschliche Preis unlesbarer Systeme wird in Minuten, Fehlern, Vorsicht, Stress und stillem Zynismus bezahlt. Bezahlt wird er von den Menschen, die die verborgenen Bedeutungen lernen, und von denen, die es nicht tun. Bezahlt wird er von Nutzern, die warten, während das Personal die Maschine entziffert. Bezahlt wird er von Organisationen, die die Fähigkeit zur Veränderung verlieren, weil niemand lesen kann, was sie gebaut haben.

Lesbare Systeme sind keine weicheren Systeme. Es sind Systeme, die respektieren, dass Technologie von Menschen mit begrenzter Aufmerksamkeit und echter Verantwortung betrieben wird. Ein System, das sich selbst erklären kann, ist leichter zu vertrauen, leichter herauszufordern und leichter zu reparieren. Das ist keine Dekoration. Es ist Teil der Arbeit.