Satire
Nobody Was Supposed to Be Using That Field
It was deprecated. It returned null. Twelve teams depended on the null.
The platform team has been marking a response field as deprecated for eighteen months. It returns null. The documentation says it will be removed. They remove it on a Friday afternoon deploy. Hyrum's Law was not in the release notes.
What Actually Happens
Twelve downstream services break within the hour. Three of them were using the null return as a sentinel value for a business condition — specifically, if field == null to determine whether a record was in a pending state. This was never documented. It was never intended. It had been working this way for three years.
The on-call rotation spans four time zones. The rollback takes forty minutes because the deployment pipeline has a mandatory bake period that cannot be bypassed.
In the post-mortem, the platform team's lead notes: "They should have read the deprecation notice." This is technically accurate.
“You deprecated it. They depended on it. That's the law, not a surprise.”
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
Deprecate by monitoring, not by announcing. Before removing anything, instrument what clients actually call — including fields they check for null. The contract is what clients observe, not what you document. If you cannot determine which behaviours are being depended on, you cannot safely remove anything. Retire behaviour by making it unreachable, not by writing a notice and hoping.
This scenario illustrates Hyrum's Law. 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