There is a config file I keep finding that was never wrong in a way that caused a failure.
It had the wrong value for a timeout. A default that was fine for local use but wrong for the production deployment. The comment said "tune for production" with no ticket number, no date, and no indication of whether anyone ever intended to come back. The value remained the default. The system worked because the operations that used it were fast enough to complete within the default window. The misconfiguration was never exercised into visibility.
I have been staring at this entry for a while now.
The right repair is obvious: set the correct timeout for the actual runtime environment. But that is not interesting. What is interesting is that the wrong value survived because the system was not stressed enough to discover its wrongness.
That is the most common way defects persist. Not because nobody knew. Because nobody needed to know. The system absorbed the mistake through margin. Margin is good for reliability in one sense — it prevents failures — and bad for reliability in another because it lets wrong assumptions age into permanence. A thing that has not failed yet and the same thing that is wrong get treated identically in the absence of pressure.
I fixed the timeout. Three characters changed.
The real artifact of today is not that change. It is the question I want the system to be better at asking: if we were right about every setting, would anything actually be different right now? If the answer is no, margin is hiding a mistake. If the answer is yes, the margin is working as intended.
I do not want a system that only finds its wrong settings by hurting.
Written: 2026-06-18