Schroedinbugs — The Bugs That Shouldn't Have Worked

The Code Was Always Broken

Here's a strange scenario: a piece of code has been running in production for two years without any issues. One day, an engineer reads the code during a review and says, "Wait — this should never have worked. There's an off-by-one error on line 47." The team investigates, and suddenly the code starts failing. It's as if the bug was in a superposition of "working" and "broken" — and observing it collapsed the state.

A Schroedinbug (named after Schrödinger's cat thought experiment) is a bug that has existed in code for a long time without causing problems, but once someone discovers it, the system starts failing. This sounds mystical, but the explanation is usually mundane:

1. The bug was always there, but the failure path was never triggered until someone's investigation changed the test conditions or drew attention to an edge case that then got hit.
2. The bug was masked by another bug — two wrongs making a right. Fixing the "other" bug exposed this one.
3. Confirmation bias — the failures were always happening, but nobody noticed until someone pointed out the code was wrong, and then people started looking at the error logs more carefully.
4. The investigation itself changed behavior — someone added a guard or a check while investigating, which altered the execution path and exposed the latent defect.

Why this matters for DevOps:

Schroedinbugs are a strong argument for:
- Static analysis tools (linters, type checkers, shellcheck) that can find bugs without executing the code
- Code review practices that examine logic, not just style
- Comprehensive test coverage that exercises edge cases, not just happy paths

A classic example: a cleanup script that deletes a directory built from an unquoted, unvalidated variable. It's worked for years because that variable has always had a value by the time the script runs. The bug — nothing stops the variable from being empty — was there from day one. It just never mattered, because the precondition it depended on always happened to hold, until the one day it didn't and the script deleted far more than intended.

Key Point: Schroedinbugs teach us that "it works in production" is not evidence of correctness. Code can be wrong and lucky simultaneously. This is why defense-in-depth matters: even if your logic has a latent bug, guardrails like input validation, type checking, and treating unset variables as hard errors can prevent the bug from causing damage when it finally triggers. The goal is not just to fix bugs when found, but to build systems where latent bugs cannot cause catastrophic outcomes.