Satire
This Config Flag Makes No Sense. We Removed It.
The flag was unexplained. The cleanup PR was approved. The invoices were wrong for three days.
A new engineer inherits a codebase with a config flag: ENABLE_LEGACY_DATE_OFFSET=true. Nobody in the current team can explain it. It is added to a cleanup sprint. Chesterton's Fence is not in the PR checklist.
What Actually Happens
The PR is reviewed and approved by two engineers. Neither can explain the flag. This is treated as sufficient justification for removal. "If nobody knows what it does, we probably don't need it" is written in the PR comments. The PR is merged.
Three days after deploy, the support team reports that all delivery date estimates for customers in UTC+8 are displaying one day early. Investigation traces the issue to an off-by-one error in a third-party logistics API introduced in 2019. The flag was compensating for it. The commit that added the flag has one comment: "workaround for vendor date bug, pending their fix." The vendor never fixed it.
The flag is restored. The cleanup PR is linked in the incident report.
“The thing you did not understand was load-bearing. It usually is.”
DivineForge Advisory
Recognise this pattern in your organisation? I help teams cut through the governance, make the right technical calls, and actually ship.
Let's talk architecture →How a Builder Should Respond
Read the git blame before removing anything you cannot explain. If code has survived years with no obvious purpose, assume it has a non-obvious one. Find the commit that added it. Find the ticket or comment that explains it. Find the system it touches. Remove only what you fully understand. "Nobody knows what it does" is a reason to investigate, not a reason to delete.
This scenario illustrates Chesterton's Fence. See all 13 laws →
Stay in the loop
New satire drops when the enterprise does something worth documenting. No spam — just the next article.
20 articles about enterprise dysfunction. None of it billable. Buy me a coffee.
Buy me a coffee