BE Teck Notes Back to be-teck.com

5 min read

A default is a decision somebody made once

Defaults are set in the abstract, by somebody not thinking about your case, and then apply for years without ever looking like a choice again.

Every configurable system has defaults, and every default is a decision.

It was made once, early, in the abstract, by somebody who was not thinking about the specific case it would eventually govern. It then applies to everything that falls into its category, for years, without being revisited — because nothing about it ever looks like a choice again. It looks like the way things are.

That property is what makes defaults the most under-examined part of any system.

How a default stops looking like a decision#

At the moment it is set, everybody involved knows it is a judgement call. There is often a discussion. Somebody says we can change it later.

Then time passes. The people who set it move on. New behaviour is built on top of it and inherits it. New cases are classified into the category it governs, by people who are thinking about the classification and not about what the classification implies.

And the default becomes invisible, in a specific way: it is not that people disagree with it, it is that they no longer see it. When something goes wrong, nobody looks there, because it does not present as a place where a decision lives.

What it looked like for us#

A document was sent for signature. It sat there. The person who had to sign did not know they had to sign it.

The request went out carrying a generic type — question — and types are mapped onto rows in a routing grid. Question had been mapped, sensibly enough, onto the row for comments. And the comment row's default delivery is a bulletin: held back until the next scheduled broadcast, ringing nothing, arriving as one line among a dozen others that also did not need doing right now.

So a document that was holding up a payment was delivered as chatter.

Every component in that chain did its job. The request was raised correctly. It was classified into a real category. That category was routed by a rule somebody had written down on purpose. Nothing failed. The design had simply never been asked what a signature request is, so it answered a different question and answered it well. The full account is filed as chatter.

The blanket rule and what it hides#

The second thing defaults do is more subtle and, in our experience, more dangerous: a blanket rule hides which places were depending on it.

We had a single line of styling that put the entire application into capital letters. It was doing what was asked. It was also, inevitably, capitalising things nobody had meant to capitalise — names, comments, error messages.

When we came to remove it, we found that 129 of the application's 138 table header cells carried no case rule of their own. For as long as the blanket existed they never needed one. So simply deleting the blanket would have quietly un-capitalised every column heading in the application — which the newly written rule says should be capitalised.

Every place that stopped declaring its own intention because a blanket was covering it becomes invisible, and stays invisible right up until the blanket comes off. Removing a default is a survey, not a deletion, and the survey is the whole job. That story is capitals are a contrast, not a volume.

Defaults that are actively harmful#

Some default choices are worse than others in a way worth naming.

A default that fails silently. Anything where the wrong outcome produces no error. A message delivered quietly rather than loudly. A field defaulting to zero rather than to unknown — we made a phone's step count nullable rather than zero precisely because no phone reported and the person did not move are different facts.

A default that is correct for the common case and catastrophic for the rare one. These are the hardest, because the default is right and the exception is what needs attention. A notification tier that is correct for comments and disastrous for signature requests is exactly this shape.

A default set for a system that no longer exists. Configuration outlives architecture. We had failure notices instructing people to fix things in a service we had retired months earlier, and they had been sending people to solve an impossible problem ever since.

Quiet is a feature#

An important corollary, because the reflex when a default is found to be wrong is to make everything louder.

Loudness is a resource with a fixed supply. An application that rings for everything is an application people mute, and a muted application delivers nothing at all. The bulletin tier in our own system is doing real work for the messages that genuinely belong to it — the mistake was never that quiet delivery exists, it was that a signature request had been classified into it.

So the fix is not escalation. It is to stop lying about what the message wants. Once a request says this asks somebody to act, the routing follows on its own and nobody has to argue about priority. That reasoning is in an alert that rings for everything.

How to audit your own#

Four questions, applied to any default worth the time.

  1. When was this set, and by whom, and for what case? If nobody knows, that is itself the finding.
  2. What is now classified into this category that was not when it was set? The category grew. The default did not.
  3. What happens when it is wrong? A default whose failure is loud is much safer than one whose failure is silence.
  4. What would break if it were removed? Not what would change — what would break. That question is the survey, and the answer is usually longer than expected.

The fourth is the one people skip, and it is the one that costs the regression.

The same four are worth asking of a system you are about to buy, where the defaults are somebody else's and you inherit every one of them — how to choose construction software.

The short version#

A default is a decision made once, in the abstract, that then applies for years without ever looking like a decision again.

The dangerous ones are the ones that are right for the common case, silent when wrong, and covering places that stopped declaring their own intention because the default was covering them.

Removing one is a survey. And when a default turns out to be wrong, the answer is usually to fix the classification rather than to turn up the volume.

Have a gap worth closing?

If something in your daily work is broken in a way everybody has stopped complaining about, that is exactly what we want to hear.

Write to hello@be-teck.com

More notes