If you design or build systems, you’re already standing in the cheapest place to prevent a failure: the design, before anything ships.
Two-minute read
One check this week
Nothing you do here is saved or sent
Your check: not done yetYour check: done
What’s true
The light measured the handle. Not the latch.
Before United Flight 811, the flight Stuart survived, a Pan Am 747 had already landed in 1987 with its cargo door open. Its cockpit warning light was off, which told the crew the door was secure. That light was wired to the door’s handle and its relief doors, not to the latch cams that actually held the door shut, so it could say “secure” while the door was unlatched.
The systems you build have signals like that too: tests that pass, health checks that report OK, dashboards that stay green. Each one is only as trustworthy as the thing it is wired to. The work is finding out what each signal actually measures and, when it isn’t measuring the thing that matters, designing the real check into the system from the start.
One check this week
Trace one green light.
Pick one signal your team relies on to tell you things are fine: a health check, an alert, a passing test.
Follow it back to its source and ask what it actually measures. Is it watching something nearby, like the handle on that cargo door, or the thing that matters, like the latch?
If it’s watching the handle, add one check that looks directly at the latch, the condition you actually care about, and ship it this week.
Failures rarely announce themselves. More often they hide behind a signal that looked fine because it was measuring something next to the problem, not the problem itself.
Takes about an afternoon
In Stuart’s words
“If security is not readily available within a product — indeed, if it is not heavily automated, conveniently packaged, and endemic to the architecture — it will not be used.”
