~/blog $ git show 2026-09-29
A Default Is a Decision You Stopped Making
· 5 min read · Victor Benavides
--craft--architectureA venue told me their event was not showing up on the public site. That was the whole report, and it was accurate.
The event existed. It was active, the venue was active, and the fee for it had been waived down to zero on an invoice that had processed correctly. Everything I would normally suspect was in order.
It was one boolean, set a month earlier, for a reason that had stopped being true.
It looked like money
My first instinct was billing, because the venue was on a waiver and waivers are new. A zero invoice is the kind of thing that can leave a record half written, and a venue that never pays is a venue that never trips any of the checks you built around paying.
So I looked there first and found nothing wrong. The invoice was waived and closed. The account was active with a timestamp. The event was live.
This happens often enough that I should expect it by now. The newest and least trusted part of a system attracts suspicion regardless of whether it is involved, and the actual culprit is usually older and more boring. Billing was innocent and had been the whole time.
It was a flag from August
Every event of this type gets created as private. Not by configuration, not by choice. The value is written into the create path directly.
That was a deliberate decision, and when it was made it was the right one. At the time, events of this kind were not meant to be publicly listed at all. Access was by badge, the audience was invited, and a public listing would have been wrong. Somebody wrote a short comment next to it explaining exactly that, which is how I know the reasoning rather than guessing at it.
Then the product changed. These events grew a public agenda, a public page, and a revenue model that depends on people finding them. Every part of that assumed the events would be visible.
The reasoning behind the default expired. The default did not.
Nothing tells you when a reason dies
This is the part I keep turning over, because I cannot think of a mechanism that would have caught it.
The comment was accurate when written. No test failed, because the behaviour was intentional and the tests encoded the intention. No alert fired, because nothing was broken in any sense a machine can measure. The system did exactly what it had been told, and what it had been told was correct in August and wrong in September.
A default is a decision that keeps being applied long after anyone is thinking about it. That is the entire point of a default, and it is also the failure mode. Every one of them carries an assumption about the world, and the world does not send a notification when it moves.
The part that made it worse
Even knowing the value was wrong, the venue could not have fixed it.
The create path wrote the flag unconditionally. The edit path did not carry the field at all, so there was no request anyone could make that would change it. One writer, one value, no second opinion anywhere in the product.
That is worth separating from the original decision, because it is a different mistake. Choosing a default is a judgement, and judgements can age badly. Providing no way to override it is a design choice that removes the ability to recover from your own judgement. A setting users cannot change is not a default. It is a law.
The fix was in two parts. The stored value had to be corrected directly for the event that was already live, and then the product needed the control that should have existed from the start: a visible checkbox, unticked, on both the create and the edit screens.
What I take from it
I do not think the answer is fewer defaults. Defaults are how software stays usable, and asking a venue to decide everything at creation time would be worse than this bug.
What I want instead is a trigger. When the model of a product changes in a big way, and ours did when these events became public things with public pages, the work is not finished at the new feature. Somewhere in the codebase are the values that encoded the old model, still being applied by code that has no idea the world moved.
They will not announce themselves. They do not fail. They keep doing precisely what you asked, and the only signal you get is a customer telling you something is missing.