What 'honest software' means in practice

We describe what we make as honest software. It is a phrase we like. It is also a phrase that risks meaning nothing, because almost nobody describes their software as dishonest.

So we have tried to be specific about what the standard actually is. Three tests. If a tool we are working on cannot pass them, we treat that as a problem to solve, not a tradeoff to accept.

The first test: will it tell me when it does not know.

A surprising amount of software is built around the premise that confidence is the same as helpfulness. The system gives you an answer. The answer is presented at the same volume whether the system is sure or not. You learn the difference only when you are wrong, and by then the cost of trusting the answer has already been paid.

A tool passes this test when uncertainty is part of the output, not a footnote under it. When the tool says "I think this is the answer, and here is why I am less sure than usual," it is being honest. When it presents a guess as a finding, it is not.

The second test: will it explain its reasoning when I ask.

Black-box tools are a cost we have come to underweight. The cost is that the user cannot tell when the tool is wrong, cannot tell when it is right for the wrong reason, and cannot learn anything from using it. They are reduced to trusting or not trusting, with no third option.

A tool passes this test when the path from input to output is visible on request. Not necessarily by default, since most outputs do not need explanation. But always, on demand, in language the user can follow.

The third test: will it help me less when I am wrong, and more when I am unsure.

This one is harder to specify. The shape of it is something like: a good tool resists confirming a confident user who has misread the situation, and offers more support to a user who is hesitating because they are missing information. A tool that does the opposite, that flatters confident users and abandons hesitant ones, has a structural problem that no amount of UI polish will fix.

The reason this test matters is that most software interactions happen in the middle of someone's day, and that someone is rarely operating with full context. Their state is partial. The tool either helps them improve that state or pretends it is not their problem.

These are the tests. They are not exhaustive. They are not always easy to pass. But they are specific, and specifics are what separate a stated value from a real one.

When we say honest software, this is the standard we mean.