Wenn Software absichtlich nichts ausrechnet

Die Funktion, die manchmal schweigt

In einem Backoffice für Immobilienvermittlung gibt es eine Bewertungsfunktion. Sie holt Marktdaten für die Lage, nimmt daraus den Quadratmeterpreis als Spanne zwischen dem 25. und dem 75. Perzentil und rechnet ihn gegen die Wohnfläche. Heraus kommt eine Von-bis-Angabe, mit der ein Makler in ein Gespräch gehen kann.

Fehlt die Wohnfläche, oder ist der eingetragene Wert unplausibel, liefert die Funktion nichts. Keinen Näherungswert. Keine Hochrechnung aus der Zimmerzahl. Keine Zahl mit Sternchen und Fußnote. Ein leeres Ergebnis und ein Satz, der benennt, welche Angabe fehlt.

Das ist eine Entscheidung, keine offene Baustelle.

Das naheliegende Argument

Wer so etwas baut, bekommt zuerst das eine Argument: Eine falsche Zahl ist schlimmer als keine. In einer Bewertung stimmt das besonders. Eine Zahl im System sieht aus wie ein Ergebnis, unabhängig davon, worauf sie beruht. Sie wandert in eine Präsentation, in eine E-Mail, in ein Gespräch mit einem Eigentümer, der sie sich merkt. Zwei Wochen später weiß niemand mehr, dass die Wohnfläche nur geraten war.

Das Argument ist richtig. Es ist aber nur die Hälfte.

Der eigentliche Grund

Eine geschätzte Zahl beendet die Frage. Sie füllt das Feld, das Objekt ist vollständig, und niemand hat mehr einen Anlass, sich damit zu befassen.

Ein leeres Ergebnis beendet nichts. Es erzeugt eine Aufgabe. Jemand muss die Wohnfläche besorgen, und die liegt nicht im System. Sie liegt beim Eigentümer, in einer Teilungserklärung, in einem alten Grundriss, manchmal nur in einem Maßband.

Also ruft jemand an. Und in diesem Anruf kommt regelmäßig mehr heraus als eine Quadratmeterzahl. Dass umgebaut wurde. Dass der Keller ausgebaut ist und in keiner Unterlage steht. Dass die Eigentümerin eigentlich schon im Frühjahr verkaufen wollte und es sich anders überlegt hat.

Die Lücke im System erzeugt ein Gespräch, das sonst nicht stattgefunden hätte. Das ist der Ertrag, nicht die vermiedene Falschangabe.

Weglassen ist eine Entwurfsentscheidung

Über Software wird meistens so gesprochen, als bestünde sie aus dem, was sie kann. Sie besteht genauso aus dem, was sie nicht anbietet. Jedes Feld, das nicht vorausgefüllt wird, jeder Wert, der nicht geschätzt wird, jede Bequemlichkeit, die man weglässt, ist eine Aussage darüber, was als Nächstes passieren soll.

Das ist keine besonders neue Einsicht, aber sie wird selten als Entwurfsmittel behandelt. Beim Bauen zieht fast alles in die andere Richtung. Ein leeres Feld sieht nach Mangel aus. Eine Funktion, die manchmal nichts liefert, sieht nach Fehler aus. Es kostet Erklärung, das so zu lassen.

Wann es trägt und wann nicht

Damit eine Lücke Verhalten steuert statt nur zu ärgern, müssen drei Dinge stimmen.

Sie muss benannt sein. „Kein Ergebnis" ist ein Fehler. „Die Wohnfläche fehlt" ist eine Aufgabe. Der Unterschied liegt in einem Satz und entscheidet über alles Weitere.

Sie muss schließbar sein. Wer die fehlende Angabe nicht beschaffen kann, steht vor einer Wand. Dann ist die Lücke nur ein Hindernis, und die Leute suchen sich einen Weg daran vorbei.

Es darf keinen bequemen Ausweg geben. Ein Knopf mit der Aufschrift „Wohnfläche schätzen" wäre nach zwei Wochen der Normalfall. Der eine Kollege, der ihn zuerst benutzt, ist der Anfang, und danach ist die Regel weg.

Wie das Backoffice im Übrigen aufgebaut ist, steht in der Fallbeschreibung.