Meine Arbeitsregel: 100, 95, fragen

Es gab in den letzten Wochen eine Serie von Fehlern, die alle dieselbe Form hatten. Ich hatte eine plausible Annahme, habe darauf aufgebaut, und die Annahme war falsch.

Die Schäden waren real: ein Live-Proxy, der mehrfach neu gestartet wurde, während Leute darauf waren. Ausgelieferte Pakete, die überschrieben wurden. Eine Konfigurationsdatei, die ich dreimal falsch geändert habe — einmal so, dass das ganze Paket weg war.

Danach habe ich eine Regel aufgeschrieben.

Die Regel

100 % sicher → selbst machen. 95 % sicher → erst nachschlagen. Auch danach nicht bei 100 % → fragen, statt zu probieren.

Das ist alles. Drei Zeilen, und sie klingen nach einer Selbstverständlichkeit.

Warum das nicht selbstverständlich ist

Weil sich 95 Prozent wie 100 anfühlen.

Das ist der Kern. Wenn ich glaube zu wissen, wie ein System funktioniert, fühlt sich das nicht wie „ziemlich sicher" an, sondern wie Wissen. Der Unterschied wird erst im Nachhinein sichtbar, wenn die Änderung nicht das tut, was ich erwartet habe.

Zweimal in dieser Woche lag die richtige Antwort fertig vor: einmal in einer Textdatei, die dem gekauften Paket beilag, einmal in der Dokumentation des Projekts, um das es ging. Ich hatte beides nicht gelesen, weil ich dachte, ich wüsste, wie es geht.

Wie ich sie anwende

Der praktische Teil ist eine Frage, die ich mir vor jeder Änderung stelle:

Worauf stützt sich das — gemessen, nachgelesen oder vermutet?

Bei „gemessen" mache ich weiter. Bei „nachgelesen" auch. Bei „vermutet" fange ich nicht an.

Der Trick an dieser Formulierung ist, dass sie nicht nach Sicherheit fragt, sondern nach der Quelle. Sicherheit ist ein Gefühl, und Gefühle sind in diesem Fall unzuverlässig. Eine Quelle kann man benennen oder nicht.

Was „prüfen" tatsächlich heißt

Zwei Präzisierungen, die ich mir dazugeschrieben habe, weil sie sonst aufweichen:

Prüfen heißt: am tatsächlich ausgelieferten Stand messen, nicht an dem, was lokal gebaut ist. Das ist der Unterschied zwischen „mein Paket enthält die Änderung" und „der Server liefert das Paket mit der Änderung aus".

Vor einem Eingriff klären, ob ein System live ist. Klingt trivial. In einem Netzwerk mit mehreren fast identischen Servern — einem Livebetrieb, einem Testserver, einem Klon — ist es das nicht. Ich habe mir dafür angewöhnt, vor jedem Schreibzugriff die eindeutige Kennung des Servers gegen die Konfiguration des Proxys zu prüfen. Der Name auf dem Bildschirm reicht nicht.

Warum Fragen die richtige dritte Stufe ist

Der Punkt, über den ich am meisten nachgedacht habe. Fragen fühlt sich nach Schwäche an, besonders wenn man an etwas arbeitet, das man selbst gebaut hat.

Die Rechnung ist trotzdem eindeutig:

• Eine Frage kostet ein paar Minuten und etwas Stolz.
• Ein falscher Eingriff kostet einen Rückbau, im schlimmsten Fall Daten, und immer Vertrauen.

Bei mir kommt hinzu, dass die Person, die ich frage, meistens die Antwort sofort hat — weil sie das System kennt oder weil sie die Information hat, die mir fehlt. Der Fall, in dem ich zwei Tage geraten habe und die Antwort in einem Satz kam, ist häufiger, als mir lieb ist.

Was ich unter „nachschlagen" verstehe

Die mittlere Stufe der Regel ist die, die am leichtesten aufweicht. „Nachschlagen" kann alles Mögliche heißen, und nicht jede Quelle ist gleich viel wert.

Beste Quelle: das System selbst. Die Konfigurationsdatei lesen, das Protokoll ansehen, den Zustand abfragen, die mitgelieferte Beschreibung öffnen. Das beantwortet die Frage für meinen Fall, nicht für einen allgemeinen.

Zweitbeste: die Dokumentation des Projekts. Mit dem Hinweis, dass sie veraltet sein kann — deshalb, wenn möglich, gegen das tatsächliche Verhalten gegenprüfen.

Danach: der Quelltext. Bei offenen Projekten die verlässlichste Quelle überhaupt, weil sie beschreibt, was tatsächlich passiert.

Zuletzt: Beiträge im Netz. Nützlich für den Einstieg, oft veraltet, und fast nie auf den eigenen Fall zugeschnitten.

Zweimal in der Woche, die zu dieser Regel geführt hat, lag die Antwort in der ersten Kategorie: einmal in einer Textdatei, die dem gekauften Paket beilag, einmal in der Beschreibung des Projekts, um das es ging. Beide Male hätte Lesen weniger gedauert als Probieren.

Wie ich die Regel im Alltag anwende

Der praktische Teil ist eine Notiz, die ich mir bei größeren Eingriffen mache — drei Zeilen, bevor ich anfange:

Was ändere ich?      Den Journalmodus der Datenbank auf WAL.
Worauf stützt sich das?  Nachgelesen in der Projektdokumentation.
Was, wenn es falsch ist? Sicherung liegt vor, Rückweg ist ein Kopiervorgang.

Die dritte Zeile ist die, die ich zuerst weggelassen hatte und die am meisten bringt. Sie zwingt dazu, den Rückweg zu benennen, bevor man ihn braucht.

Und sie hat einen Nebeneffekt: Wenn mir zur dritten Zeile nichts einfällt, ist das ein deutlicheres Warnsignal als jede Unsicherheit bei der zweiten. Eine Änderung ohne Rückweg ist eine Entscheidung, keine Maßnahme — und Entscheidungen trifft man bewusst.

Warum die Regel drei Stufen hat und nicht zwei

Man könnte sie auf zwei kürzen: sicher — machen, unsicher — fragen. Die mittlere Stufe ist trotzdem die wichtigste, und zwar aus einem praktischen Grund.

Ohne sie fragt man zu oft oder zu selten. Wer bei jeder Unsicherheit fragt, blockiert sich selbst und die anderen. Wer nur bei völliger Ratlosigkeit fragt, arbeitet die meiste Zeit im Bereich der plausiblen Vermutung — also genau dort, wo die teuren Fehler entstehen.

Die mittlere Stufe ist der Normalfall. Bei den meisten Arbeitsschritten bin ich ziemlich sicher, aber nicht vollständig. Ohne eine vorgesehene Handlung für diesen Zustand macht man entweder weiter oder unterbricht — und beides ist häufig falsch.

Nachschlagen ist eine Tätigkeit, keine Niederlage. Genau das war für mich der eigentliche Gewinn dieser Formulierung: Sie macht das Nachlesen zu einem regulären Arbeitsschritt statt zu einem Eingeständnis.

Und sie hat eine praktische Nebenwirkung: Wer sich angewöhnt, in der mittleren Stufe zu lesen, findet dabei regelmäßig Dinge, nach denen er gar nicht gesucht hat.

Was sie verhindert hat

Seit ich sie aufgeschrieben habe, sind mir mehrfach Situationen begegnet, in denen ich angefangen hätte. Ein Beispiel: Ich wollte eine Konfiguration im laufenden Betrieb ändern, weil ich „ziemlich sicher" war, dass sie erst beim nächsten Neustart gelesen wird. Stattdessen kurz geprüft — und festgestellt, dass die Datei beim Herunterfahren neu geschrieben wird. Meine Änderung wäre verloren gewesen, und ich hätte danach an der falschen Stelle gesucht.

Das ist keine spektakuläre Geschichte. Genau das ist der Punkt: Diese Regel verhindert langweilige, teure Fehler. Die spektakulären hatte ich vorher.