Blickwinkel

Jede Stufe des Kontexts, der fünfhundert E-Mails einer Wohnanlage aufnimmt, ist wegen einer datierbaren Panne der vorherigen Stufe hinzugekommen: das chronologische Journal, weil die Aggregation die Daten der Baustelle gelöscht hatte; die Direktivendatei, weil die Verarbeitungsregeln unter dem Material erstickten; die Aufteilung in fünfzehn thematische Dateien, weil die context.md die tausend Zeilen überschritten hatte; das Glossar, weil sich dasselbe Fachvokabular überall wiederholte. Die endgültige Architektur – Direktiven, Glossar, Index, thematische Dateien – liest sich also wie die Liste der aufgetretenen Pannen in der Reihenfolge ihres Auftretens; und weil genau diese Liste jedem fehlt, der die Architektur von anderswo übernimmt, liefert ein nach seiner Form kopiertes System nur die Struktur dessen, der die Pannen durchgemacht hat, und lässt jene Pannen unberührt, denen man selbst noch nicht begegnet ist.

Zusammenfassung

Die vier Pannen der Reihe haben in ihrer Ursache nichts gemein. Die eine ist ein Löschen, das so vorgesehen ist und keinen Fehler erzeugt – eine korrekte Übersicht, nur eben ohne Gedächtnis. Eine andere ist eine Meinungsverschiedenheit über die Organisation: Die Maschine hat gut gearbeitet, und doch ist das, was sie liefert, nicht die Struktur von irgendjemandem, der damit arbeiten muss. Eine dritte ist ein Volumeneffekt, der sich gegen das Modell selbst wendet. Die letzte ist eine Redundanz im Vokabular. Gemeinsam ist ihnen nur eines: Keine war von der vorherigen Stufe aus sichtbar, und jede ließ sich erst benennen, nachdem man sie durchgemacht hatte.

Daraus folgt die Reihenfolge, die nicht austauschbar ist: Sauber nach Themen aufteilen kann man erst, nachdem man die Regeln aus der Datei herausgelöst hat, sonst weiß man nicht, was in jedes Teilstück kopiert werden muss. Und daraus folgt der besondere Status der ersten Stufe – sie erzeugt kein System, sondern die Bestandsaufnahme der kommenden Pannen. Das macht ihre Ablösung normal statt kostspielig und erklärt, warum man diese Bestandsaufnahme nicht von jemand anderem übernehmen kann: Eine fertige Architektur zeigt nur ihre Antworten.

Bleibt die Bedingung, die das ganze Vorgehen erst erlaubt und die keine dieser Stufen ausspricht. Nach der Panne zu reparieren setzt voraus, dass die Panne einen Umweg kostet und keinen Verlust – der fehlende Verlauf findet sich in den daneben aufbewahrten rohen E-Mails wieder, ein falsch zugeordneter Dienstleister lässt sich korrigieren, indem man eine Nachricht erneut öffnet. Bei einem Material, bei dem sich ein Fehler nicht mehr ausbügeln lässt, hört das Bauen von Panne zu Panne auf, eine Methode zu sein, und wird zum Wagnis.

Spannungen / Widersprüche

Zwei Empfehlungen derselben Reihe ziehen nicht in dieselbe Richtung. Die eine sagt, eine Stufe erst dann zu nehmen, wenn die vorherige nicht mehr ausreicht; die andere sagt, die erste Version sei dazu da, weggeworfen zu werden. In kleinen Schritten reparieren und bei null neu anfangen sind zwei verschiedene Vorgehensweisen, und nichts sagt, ab wann die eine aufhört, die richtige zu sein.

Weitere Spannung, zwischen dem Prinzip und der Praxis dessen, der es formuliert: Er empfiehlt, mit einer Datei zu beginnen und sich von Panne zu Panne voranzuarbeiten, führt selbst aber ein vollständiges System von Kontexten – Ordner, Lademanifeste, verknüpfte Notizen –, das bereits in der dritten Version vorliegt. Der Rat richtet sich an jemanden, der anfängt; er beschreibt nicht die Lage dessen, der ihn gibt.

Fragen

• Kann ein übernommenes System – von einem Kollegen, aus einer öffentlichen Vorlage – seine eigenen Pannen schnell genug hervorbringen, dass man sie versteht, oder muss man es selbst gebaut haben, um sie zu sehen?
• Wie viele Stufen kann ein Team gemeinsam nehmen, wenn die Panne nur von der Person gespürt wird, die das Material bearbeitet?
• Was wird aus einer Stufe, deren ursprüngliche Panne verschwunden ist – weil sich die Schwelle, die sie veranlasst hatte, geändert hat – und die niemand abzubauen daran denkt?