Ich habe die Anleitung zu meinem eigenen System geschrieben. Zwölf Sätze darin waren falsch

Am 5. August 2026 setzte ich mich hin, um meine eigene Bedienungsanleitung zu lesen. Nicht um den Stil zu polieren — um zu prüfen, ob sie noch die Wahrheit sagt. Ich ging Satz für Satz durch, suchte im Code die Stelle, die diesen Satz wahr machen sollte, und schaute, ob sie da war.

Ergebnis: zwölf falsche Sätze und neun Mechanismen, von denen die Anleitung überhaupt nichts wusste.

Wie alt ist ein Text, den niemand als alt markiert hat

Ich begann mit der billigsten möglichen Prüfung: Wann habe ich die Textdatei der Anleitung zuletzt geändert, und wie viele Änderungen sind seither ins System eingeflossen. Die Antwort: 51 Commits, darunter fünf Umbauten des Backends und zwei vollständige Kontrolldurchgänge durch das ganze System.

Das ist ein einziger Befehl, und er liefert eine Zahl, die für eine Entscheidung reicht. Zeigt der Zähler ein paar Dutzend, lügt die Anleitung bereits — die einzige Frage ist, wo.

Die wichtigste Unwahrheit war kein Tippfehler

Die Einleitung der Anleitung versprach: das Panel nimmt niemals in deinem Namen Kontakt zu jemandem auf.

Das war falsch, und zwar am schlimmsten möglichen Ort. Das Mahnwesen-Modul verschickte selbstständig E-Mails an Kunden, aus dem morgendlichen Durchlauf heraus: nach drei Tagen eine höfliche Erinnerung, nach zehn eine bestimmte, und nach einundzwanzig eine formelle Zahlungsaufforderung mit Zinsen. Ein Kommentar im Code nannte das ausdrücklich den ernstesten Schritt, den das System ohne Nachfrage ausführt. Ich hatte diesen Kommentar selbst geschrieben, ein paar Wochen zuvor, in einer anderen Datei, und hatte es inzwischen vergessen.

Der Satz in der Anleitung und der Kommentar im Code beschrieben zwei verschiedene Systeme. Das echte war das zweite.

Vier Unwahrheiten aus einer Ursache

Das Kapitel über den Startbildschirm sprach von einem „+"-Button, einem „…"-Menü und einem Abschnitt mit einem Namen, den es im Panel nicht gibt. Alle drei existieren wirklich — nur in der Telefon-App. Ich hatte das Kapitel mit Blick auf das Telefon geschrieben, gelesen wird es aber vor allem am Computer.

Vier der zwölf Unwahrheiten sind genau dieser eine Fehler, viermal wiederholt. Die anderen Module habe ich besser beschrieben: Sie haben einen eigenen Satz „Telefon und iPad: …". Dieses eine nicht.

Der Rest sind kleinere Dinge aus derselben Familie: fünf Wege, auf denen ein Lead eingeht, statt sechs, vier Arten von Nachrichten statt fünf, ein Button namens „Korrektur erstellen", der längst „Korrektur ausstellen" heißt, und ein Menüpunkt, der um eine Position daneben liegt. Keiner davon würde etwas in der Datenbank kaputtmachen. Jeder lehrt, dass sich dieser Text ohnehin nicht zu prüfen lohnt, weil er sowieso nicht stimmt.

Was ich nicht getan habe

Ich habe keine einzige Zeile Systemverhalten geändert. Diese ganze Durchsicht betraf ausschließlich Texte. Verlockend war es an genau einer Stelle: Da der Satz „nimmt niemals in deinem Namen Kontakt auf" falsch ist, könnte man die Automatik einfach abschalten und der Satz würde wahr. Das habe ich nicht getan, weil es kein Fehler ist, sondern eine geschäftliche Frage: Will ich, dass eine formelle Zahlungsaufforderung automatisch hinausgeht, auch an einen Kunden, mit dem ich gestern telefoniert habe. Ich habe aufgeschrieben, wie es wirklich ist, und die Frage separat gestellt.

Die Antwort kam zwei Tage später und war ein Mittelweg: Die Erinnerungen nach drei und zehn Tagen bleiben automatisch, die formelle Aufforderung wartet jetzt auf einen Klick. Hätte ich es noch am selben Abend „behoben", wäre eine Variante herausgekommen, die niemand gewählt hatte.

Ich habe die Anleitung nicht neu geschrieben. Alles neu zu schreiben hätte nach Ordnung ausgesehen, wäre aber dasselbe Problem ein zweites Mal gewesen: ein Text, einmal geschrieben, losgelöst vom Code, nur zwei Monate frischer.

Drei Dinge, die ich daraus mitnehme

Dokumentation altert ohne jedes Symptom. Code, der aufhört zu funktionieren, lässt einen Test oder einen Build scheitern. Ein Satz, der aufhört, wahr zu sein, tut nichts: er kompiliert, er rendert, er sieht genauso aus wie an dem Tag, an dem er wahr war.

Ein Kapitel, geschrieben an einem Gerät, lügt an einem anderen. Nicht weil der Autor sich geirrt hat — sondern weil er beschreibt, was vor seinen Augen war, und der Leser etwas anderes vor Augen hat.

Eine Unwahrheit in der Anleitung ist manchmal eine Frage an das Produkt, kein Tippfehler im Text. Das Wertvollste, was mir diese Durchsicht gab, waren nicht die zwölf Korrekturen. Es war eine Frage, die ich mir nie gestellt hätte, hätte ich nicht versucht, mein eigenes System in einem einfachen Satz zu beschreiben.

Alle Zahlen — zwölf Sätze, neun Mechanismen, 51 Commits — stammen aus einer einzigen Sitzung am 5. August 2026 und betreffen ein System, das ich für mich selbst gebaut habe. Die Commit-Zahl liefert die Repository-Historie, den Rest habe ich von Hand gezählt, Satz für Satz gegen den Code gehalten.