Three Confident Assumptions a Real Run Broke in One Day

The mock-up put the picture on the right side of the notification, with a small icon in the card's top line. On my actual phone the picture sits on the left, the top line has no icon, and the little one-colour badge only shows up on the lock screen. I had picked a design from a drawing of a screen that does not exist.

That was the smallest of three things I believed this week that turned out to be untested. The other two were in the database, where being wrong costs more.

A security log, and the sentence "no role can change this"

My journaling app has a handful of account settings that matter for security, the kind where a quiet change would be a real problem. They have been guarded for months. What I did not have was a record of changes to them, so if a guard ever failed I would have had no way to know.

So I built a log. Most of the design work was deciding what to leave out of it. It records which setting changed, when, and which part of the system changed it. It holds no IP address, because I could not name a question I would need one to answer and it is one more piece of personal data to protect. An account's lines are deleted with the account, and what stays behind is a single line saying that a deletion happened, with no account attached. Nothing in the app can read the log or write to it directly, including the server's own master key. And if a line cannot be written, the change itself does not go through. I would rather block a legitimate change for a minute than allow an unrecorded one.

While building it I went back to an older design note about one of those guarded settings. The note said no role could clear it. I tried it on a local copy of the database with the most powerful role there is, the one that owns the tables.

It could. That role can switch ordinary rules off for its own session, with a single setting and no change to the structure of the database, and then do what the rule forbids. I found no sign anyone had ever done it in production. But "no role" in that note had meant "none of the roles I thought to test," and I had read it for months as a fact.

The guards and the log now fire regardless of that setting. I also wrote down what I still cannot see, which is narrower than before and not zero.

One of the vendor's four statements ran fine and did nothing

The second one came from a planned change at my database host. Later this month they are tightening the defaults for every project, so that new tables and functions start closed instead of open to the public-facing roles. Their documentation gives four statements you can run early to get the same result.

I had filed this as housekeeping. Run the four statements, tick the box.

I ran them first on a local copy built from my production settings, then created a new function and called it as a logged-out visitor. The call went through. Three of the four statements did what the page said, and the one for functions changed nothing on a database set up the way mine is. It had run without an error and reported success.

I wrote my own version of that statement, proved it on the copy with the same logged-out call, and that is what went to production. The part that stays with me is how the failure presented. There was no error to catch, only a success message on a statement that had no effect, and the only way to see it was to try the thing the fix was supposed to prevent.

Back to the notification

The phone was the low-stakes version of the same mistake, and it is the one I would have defended. I had two rounds of numbered mock-ups. I had a real reason for the final design, because the phone draws that small badge from the image's outline in a single colour, so the coloured logo I first asked for would have shown up as a plain dot. That reasoning was correct. The picture of where everything would sit was not.

What saved the decision is that the mock-up was never the test. The test was a real push to the real phone, and I looked at it on the lock screen and in the notification shade before shipping. The choices held up. The drawing had only been good for telling the options apart.

I notice I trust my own artifacts more than other people's. A vendor's page gets a skeptical read. A note I wrote in June, or a mock-up I approved an hour ago, gets treated as something I already know.

Mental Models

"Every role" means every role someone tested. Ask what the most powerful account can switch off, and whether switching it off leaves a trace.

Success is a message about the statement, and the result is something else. A fix that runs clean has told you it was valid. Whether it worked is a separate check, and the check is to attempt the thing it should now prevent.

Use a drawing to choose and a real run to confirm. A mock-up of someone else's screen can separate option two from option five. It cannot tell you what the screen will show.