When software deliberately calculates nothing

The function that sometimes stays silent

A back office for property brokerage has a valuation function. It fetches market data for the location and takes the price per square metre as a range between the 25th and the 75th percentile. That range is multiplied by the living area. The result is a from-to figure a broker can take into a conversation.

If the living area is missing, or the value entered is implausible, the function returns nothing. No approximation. No extrapolation from the number of rooms. No figure with an asterisk and a footnote. An empty result and one sentence naming what is missing.

That is a decision, not an open item.

The obvious argument

Whoever builds something like this hears one argument first: a wrong number is worse than no number. In a valuation this is especially true. A number in the system looks like a result, regardless of what it rests on. It travels into a presentation, into an email, into a conversation with an owner who remembers it. Two weeks later nobody recalls that the living area was only guessed.

The argument is correct. It is also only half of it.

The actual reason

An estimated number ends the question. It fills the field, the property looks complete, and nobody has a reason to touch it again.

An empty result ends nothing. It creates a task. Someone has to obtain the living area, and it is not in the system. It is with the owner, in a declaration of division, in an old floor plan, sometimes only in a tape measure.

So someone makes a call. And in that call, more comes out than a square metre figure. That there was a conversion. That the basement is finished and appears in no document. That the owner actually wanted to sell in spring and then changed her mind.

The gap in the system creates a conversation that would otherwise not have taken place. That is the return, not the avoided wrong figure.

Leaving out is a design decision

Software is mostly talked about as if it consisted of what it can do. It consists just as much of what it does not offer. Every field that is not prefilled, every value that is not estimated, every convenience left out is a statement about what should happen next.

That is not a new insight, but it is rarely treated as a design tool. When building, almost everything pulls the other way. An empty field looks like a defect. A function that sometimes returns nothing looks like a bug. It takes explaining to leave it that way.

When it holds and when it does not

For a gap to steer behaviour rather than merely annoy, three things have to be right.

It has to be named. "No result" is an error. "The living area is missing" is a task. The difference is one sentence, and it decides everything that follows.

It has to be closable. Whoever cannot obtain the missing information faces a wall. Then the gap is only an obstacle, and people find a way around it.

There must be no convenient way out. A button labelled "Estimate living area" would be the norm after two weeks. The one colleague who uses it first is the beginning, and after that the rule is gone.

How the back office is built otherwise is described in the case study.