Eine neue Schnittstelle sollte sich verhalten wie die bestehenden. Die Vorgabe lautete: wie im Bestand.
Vier Stunden Fehlersuche später standen drei Abweichungen fest. Die neue Schnittstelle lieferte Listen in einer anderen Verpackung als die alten. Sie speicherte Kennungen in einem anderen Format. Und beim Übersetzen der Daten für die Oberfläche fehlten Felder.
Jede der drei Fragen war im Bestand einheitlich gelöst. Als Regel aufgeschrieben war keine.
„Wie im Bestand“ ist keine Regel#
Die Regeln steckten als Gewohnheit im Code. Wer sie einhalten sollte, musste sie erraten. Wer von Anfang an dabei war, errät meistens richtig. Ein neuer Kollege oder ein KI-Agent orientiert sich an dem, was er im Code vorfindet.
Der naheliegende Ausweg lautet: die Regeln aus dem Code ablesen. Man zählt, was häufig ist, und schreibt es auf. Dagegen sprechen drei Gründe.
Der Code zeigt, was ist, und nicht, was sein soll. Eine meiner Regeln ist ausdrücklich eine Übergangsregel: Schnittstellen liefern die Kennung eines Datensatzes unter zwei Namen, einem alten und einem neuen. Das gilt nur, bis die Oberfläche umgestellt ist. Im Bestand steht diese Form überall. Wer Regeln aus der Häufigkeit ableitet, macht aus dem Übergang einen Dauerzustand.
Eine abgeschriebene Regel kann nicht verletzt sein. Wer hinterher aufschreibt, was herausgekommen ist, hat nicht geprüft, sondern umbenannt. Die Festlegung muss älter sein als das, was an ihr gemessen wird. Das ist derselbe Grundsatz wie beim erlaubten Raum.
Der Code kennt keine Gründe. Ohne Grund lässt sich eine Regel weder verteidigen noch streichen.
Der Code liefert trotzdem zwei Dinge. Er liefert Belege, also wie oft eine Regel eingehalten und wie oft sie verletzt wird. Und er liefert Kandidaten: ein Muster, das überall gleich ist und noch nirgends als Regel steht.
Eine Regel hat vier Felder#
| Feld | Frage |
|---|---|
| Regel | Was gilt? Genau ein Satz. |
| Grund | Welcher Vorfall oder welche Vorschrift steht dahinter? |
| Prüfung | Wer stellt fest, ob die Vorschrift eingehalten ist? Ein Programm oder ein Mensch mit Namen. |
| Geltung | Für Neues gilt sie sofort. Ab wann gilt sie für den Bestand? |
Das dritte Feld entscheidet, ob die Regel etwas wert ist.
Fünf Regeln aus meiner Entwicklung, mit Grund und wie sie sich prüfen lassen:
| Regel | Grund | Prüfbar durch |
|---|---|---|
| Listen kommen immer in derselben Verpackung zurück. | Der Vorfall vom Anfang. | Test der Schnittstelle gegen die echte Datenbank (Ich habe in Development und Production auf jedem Rechner die gleiche Konfiguration) |
| Vor der Freigabe laufen Typprüfung und build. | Der build findet Fehler, welche die Typprüfung durchlässt. | Schritt im Ablauf der Freigabe |
| Jeder Text der Oberfläche liegt in allen sechs Sprachen vor. | Eine der Sprachen wurde wiederholt vergessen. | Vergleich der Sprachdateien |
| Zu welchem Kunden eine Anfrage gehört, kommt nur aus dem Anmeldenachweis und nie aus der Anfrage selbst. | Tenant Isolation. | Statischer Prüfer |
| Hilfsfunktionen, welche einen Ladevorgang benutzen, sind eigenständige Funktionen und bekommen ihre Daten übergeben. | 8. Oktober 2026: Endlosschleife beim Bildaufbau. | Statischer Prüfer oder Durchsicht durch einen Menschen |
Die Prüfung muss das Richtige prüfen#
Eine Prüfung, die grün zeigt, kann wertlos sein.
Bei mir meldete eine Typprüfung „bestanden“. Sie war gegen einen veralteten Zwischenstand gelaufen. Gegen den aktuellen Stand ergab dieselbe Prüfung fünf Fehler.
Dasselbe gilt für Tests gegen eine nachgebaute Datenbank. Ein solcher Test prüft den Nachbau. Die Abweichungen vom Anfang fallen nur auf, wenn die echte Schnittstelle gegen die echte Datenbank läuft.
Ein Ursprung, mehrere Ausgaben#
Regeln stehen schnell an vier Stellen: im Handbuch für Menschen, in der Regeldatei für den Agenten, in den Einstellungen des Prüfers und im Nachweis für den Kunden. Vier Stellen ergeben mit der Zeit vier Fassungen.
Der Widerspruch aus dem ersten Beitrag ist so entstanden: Zwei Stellen sagten Verschiedenes über dieselbe Frage.
Abhilfe ist eine einzige Liste mit den vier Feldern (Datenkonsistenz). Sie ist der Ursprung. Das Handbuch, die Regeldatei und der Nachweis werden aus ihr erzeugt. Aus genau diesem Grund habe ich am 31. Juli 2026 entschieden, kein weiteres eigenes Regeldokument neben den vorhandenen anzulegen.
Was mit dem Bestand geschieht#
Ohne das Feld „Geltung“ gibt es zwei schlechte Ausgänge. Entweder fasst niemand den Bestand an, oder jemand will alles auf einmal angleichen.
Meine Regel dafür: Fasse ich eine Datei ohnehin an und kostet die Angleichung weniger als 30 Prozent des Aufwands, der ohnehin fällig ist, dann geschieht sie im selben Zug. Kostet sie mehr, wird sie ein eigener Auftrag.
So mache ich das#
So entwickle ich OTSM:
- Seit dem 21. August 2026 läuft vor jeder Übernahme einer Änderung ein statischer Prüfer mit meinen eigenen Regeln. Derselbe Prüfer läuft noch zusätzlich einmal auf dem Server, bei jedem Stand, der dort ankommt.
- Die Typprüfung läuft vor jeder Übernahme. Bei Änderungen an der Oberfläche läuft zusätzlich der vollständige build vor jeder Freigabe.
- Tests von Schnittstellen laufen gegen eine echte Datenbank, nicht gegen einen Nachbau.
- Die Obergrenze für die Größe einer Datei liegt bei 300 Zeilen.
- Ein eigener Test vor der Korrektur ist Pflicht bei Sicherheitsfehlern, bei Datenverlust und bei Fehlern, die nach einer Korrektur wiedergekommen sind. Für alles andere genügt die Sichtprüfung. Der Aufwand der Prüfung richtet sich nach der Schwere des Fehlers.
Der Test für Ihren Betrieb#
Dieser Abschnitt richtet sich an Sie, wenn Sie eine Softwareentwicklung verantworten, mit Menschen, mit KI-Agenten oder mit beiden.
Die Behauptung: Wenn dieselben Fehler wiederkehren, weil Regeln nur als Gewohnheit im Code oder als Text ohne Prüfung bestehen, dann senkt die Liste mit vier Feldern die Zahl der Regelverstöße, die erst nach der Übernahme auffallen.
- Die Liste anlegen. Nehmen Sie die zehn Regeln, die in Ihren Durchsichten am häufigsten angemahnt werden.
- Je Regel den Grund eintragen. Findet sich keiner, streichen Sie die Regel.
- Je Regel eine Prüfung oder einen Namen eintragen.
- Je Regel die Geltung für den Bestand festlegen.
Gemessen wird an zwei Größen:
- Messgröße 1: Anteil der Regeln, die eine Prüfung oder einen Namen tragen. Zielwert 100 Prozent nach zwei Wochen. Das ist Schreibarbeit.
- Messgröße 2: Zahl der Verstöße gegen diese Regeln, die erst nach der Übernahme gefunden werden, also in der Durchsicht, im Test oder beim Kunden.
- Ausgangswert: die letzten acht Wochen aus Ihrer Fehlerliste.
- Zielwert (mein Vorschlag): Halbierung in den folgenden acht Wochen.
- Abbruchkriterium: Erreicht Messgröße 1 die 100 Prozent und sinkt Messgröße 2 nicht, dann sind die wiederkehrenden Fehler keine Verstöße gegen Ihre Regeln. Es fehlen die Regeln zu den Fehlern, die tatsächlich auftreten. Nehmen Sie dann die letzten zehn Fehler und fragen Sie je Fehler: Welche Regel hätte ihn verhindert, und steht sie in der Liste?
Der Preis, wenn Sie nichts tun: Jeder neue Kollege und jeder Agent lernt die Regeln aus dem Code. Er lernt das Häufige, auch das, was Sie abschaffen wollten.
Wo die Methode aufhört#
Regeln prüfen die Form. Ob die Lösung fachlich stimmt, sagt keine von ihnen.
Jede Prüfung kostet Pflege. Deshalb gibt es das Feld „Grund“. Eine Regel, deren Grund weggefallen ist, wird gestrichen.
Die Liste enthält nur, was jemand aufgeschrieben hat. Die nächste Regel entsteht aus dem nächsten Vorfall.