Hauptgedanke

Eine Antwort zum Verhalten eines Produkts ist fast immer unvollständig. Kein Test deckt den gefragten Fall ab; das Repository enthält je nach Zustand eines Feature Flags zwei Verhaltensweisen; die Konfiguration genau dieses Kunden ist nicht zugänglich; die schriftliche Produktentscheidung nennt eine Regel, der der Code zu widersprechen scheint; die Support-Dokumentation nennt eine dritte.

Eine Antwort, die diese Zonen verschweigt, bleibt brauchbar, lesbar und stellenweise falsch — ohne dass irgendetwas sagt, an welchen Stellen. Wer sie bekommt, jemand im Support vor einem Kunden oder jemand aus dem Vertrieb im Termin, verwendet sie vollständig, auch dort, wo sie nicht trug. Das Risiko ist nicht kleiner geworden, es hat den Träger gewechselt: Es lag bei dem, der wusste, dass er nicht wusste, und liegt jetzt bei dem, der zu wissen glaubt.

Zu sagen, wo man nicht weiterkommt, gehört also zur Antwort und ist kein Eingeständnis von Schwäche. Ein seriöser Mensch macht es genauso — er benennt seinen Zweifel und sagt, wann getestet werden muss —, und nur so lässt sich das eigentliche Ziel erreichen: den Aufwand fürs Suchen senken, ohne die Nachvollziehbarkeit des Behaupteten zu verringern.

Warum das wichtig ist

Das legt ein Abnahmekriterium für ein automatisiertes Antwortsystem fest, das weder seine Geschwindigkeit noch seine Trefferquote betrifft: Kann es „Das kann ich nicht bestimmen“ hervorbringen? Ein System, das immer vollständig antwortet, ist gerade durch diese Vollständigkeit disqualifiziert.

Es gibt auch dem einen Wert, was wie ein Scheitern aussieht: Zu melden, dass ein PDR und der Code auseinandergehen oder dass kein Test einen Fall abdeckt, ist für sich eine Produktinformation, manchmal nützlicher als die erbetene Antwort.

Nuancen und Grenzen

Die Übung hat eine Schwelle. Eine Antwort, die jeden Satz mit einem Vorbehalt versieht, wird wieder unbrauchbar, und der Leser gewöhnt sich wieder an, selbst zu testen — die Kosten, die man beseitigen wollte, sind unvermindert zurück.

Und die Erklärung des Nichtwissens ist nicht verlässlicher als der Rest: Ein Modell kann selbstsicher behaupten, etwas nicht zu wissen, was es hätte feststellen können, und auch dieser Fehler fällt nicht auf.

Offene Fragen

• Wie prüft man, dass ein System seine tatsächlichen Wissenslücken meldet und nicht die, die sich leicht benennen lassen?