Debugging Dice: Roll for New Bugs

In our legacy system, we don't use D20s; we use a D100. We call it the 'sprint commitment die'

When the PM requests a confidence interval for the hotfix, I roll the rubber-duck d20 three times - instant Monte Carlo regression forecast

Finally, a way to quantify the exact multiplier for the hydra effect in production - though experienced architects know the real number is always n+1 where n is whatever the dice show, plus an additional critical bug that only appears during the CEO's demo

The dice perfectly capture the Monte Carlo method of debugging: you never quite know the outcome, but you're statistically guaranteed that fixing one edge case will spawn N+1 new ones across different modules. Senior engineers know the real skill isn't preventing this - it's accurately estimating which number the dice will land on during sprint planning

Architecture review replaced by a rubber-duck d20 - the roll equals the regression fan-out; a natural 20 toggles a forgotten feature flag and pages SRE

Rubber-duck d20: roll to size the blast radius of a “one-line fix.” 1 = green build; 20 = transitive dependency bump, three Jira epics, a feature flag, and an outage someone insists is unrelated

The second law of debugging: every fix increases codebase bug entropy, now with authentic D&D randomness