Hauptgedanke

Wenn eine Prüfung nur von der Oberfläche durchgesetzt wird — eine Rabattobergrenze, die im Eingabeformular geprüft wird und sonst nirgends —, sind nur zwei Lesarten möglich, und beide sind Abweichungen.

Entweder ist es eine echte Fachregel am falschen Ort: Sie gehört dorthin, wo die Regeln leben, und dass sie in der Oberfläche steht, ist ein Entwurfsmangel, über den abzuwägen ist. Oder sie lässt sich umgehen — über einen Dateiimport, über die Schnittstelle, die das Produkt externen Entwicklern anbietet —, und dann ist es ein Fehler mit Sicherheitsrisiko: Was die Oberfläche verbietet, erlaubt ein anderer Weg.

Der umgekehrte Fall wird genauso behandelt. Eine Regel, die der Kern des Codes durchsetzt, die die Oberfläche aber nicht abbildet, erzeugt eine unverständliche Ablehnung: Der Nutzer sieht seine Aktion zurückgewiesen, ohne zu sehen, was er falsch gemacht hat.

Warum das wichtig ist

Damit wird das Lesen der Oberflächen — sonst ans Ende verbannt, wenn es überhaupt stattfindet — zu einer ergiebigen Quelle für Abweichungen. Die Ausbeute ist hoch, weil die Frage kein Urteil verlangt: Man muss nur feststellen, dass eine Regel auf der Serverseite kein Gegenstück hat.

Es liefert auch ein Argument dafür, dieses Lesen nicht zu überspringen, wenn die Zeit knapp wird: Es ist der Teil des Produkts, der pro investierter Stunde am meisten einbringt.

Nuancen und Grenzen

„Fast immer“: Eine Eingabehilfe ohne jede fachliche Tragweite — ein vorgeschlagenes Datumsformat, ein ausgeblendetes Feld, damit die Oberfläche übersichtlicher wird — ist keine Regel und wird auch keine Abweichung.

Die Umgehung setzt voraus, dass ein anderer Weg tatsächlich offen ist. Bei einem Produkt ohne Import und ohne externe Schnittstelle bleibt nur der erste Fall übrig — die falsch platzierte Fachregel.

Offene Fragen

• Was wird aus der Eingabeprüfung, wenn die Regel auf die Serverseite verlagert ist: eine bewusst hingenommene Doppelung zugunsten des Komforts, oder die Quelle einer künftigen Divergenz?