Code that assumes sequential execution, stable state, or consistent timing will fail the moment concurrency, scale, or latency proves the assumption wrong.
Operations that work at small scale hit non-linear thresholds at production volume
If a system checks a condition and then acts on it without holding a lock or using an atomic operation — if code that works on small data fails on large data — if behavior changes under load — the system is temporally coupled to assumptions about sequencing, scale, or speed.
Every system that operates across time — concurrent threads, distributed nodes, growing datasets, eventual consistency — contains temporal assumptions. The more distributed the system, the more assumptions it makes about time, and the more ways those assumptions can fail.
This section is being excavated...
This pattern has been found in applications built by talented developers at respected organizations across every decade of software history. Its presence in a codebase is not a reflection of the developer who wrote it — it is a reflection of what that developer was taught, what tools they had, and the path that was easiest given what they were taught. The goal is not to find fault. The goal is to find the pattern — before it finds you.
Katie's Law: The developers were not wrong. The shortcut was not wrong. The context changed and the shortcut didn't.