This systems-first guide reframes recurring tech failures into seven data-driven rules forged from hundreds of postmortems and real-world incident analysis. Structured, satirical, and deeply grounded—this is Clean Code for grownups.

A humorous sketch of software chaos: bug armies, panicked devs, and one very determined heretic.

I. First Rule of Code Club: We Talk About The Code

Silence breeds bugs, tech debt, and 2 AM outages. If the code is unreadable, if a test fails mysteriously, if a hack summoneth Lovecraftian horrors—speak up. If thou knoweth not what thou doest, ask. If the code gods are confused, ask. No meeting is required, for we are not barbarians. A comment, a begrudging Teams message, even a passive-aggressive “TODO” shall suffice. Just talk about it—lest the problem be buried, only to rise again when prod goeth down.

II. Second Law of Codonamics: Like the Universe, Code Tends Toward Disorder

The Second Law of Codonamics states that the entropy of a codebase—like that of the universe—only increases with time. That which is not refactored shall rot, and that which is not readable shall be rewritten in despair. Keep functions short, complexity low, and names clear, lest your future self curse your past decisions when a colleague demandeth, “What in God’s name is temp2?” If thou leavest behind a riddle wrapped in an enigma encased in a recursive lambda, thou art not clever—thou art a future escalation. The wisest wield AI serfs—tireless, uncomplaining toilers—to untangle knots, enforce consistency, and purge the sins of spaghetti past. Though the battle against entropy can never be won, fight we must—for with refactoring as our sword and readability as our shield, code may yet defy the creeping hand of death.

III. “If the User Can’t Use It, It Doesn’t Work”¹

A feature unseen is a feature unused. A feature unclear is a feature broken. If a button giveth no feedback, they shall click it twice—and twice shall they be charged. If an error message explaineth nothing, they shall invent their own truth. And if thou dost bury key actions in a labyrinth of modals, dropdowns, and mystery meat navigation, they shall abandon thee. Clarity is the difference between function and failure. Accessibility is not an afterthought—it is the key.

IV. Trust is a Lie, and Fraud is Eternal

Secrets committed shall be discovered—not by thee, but by an adversary, a vendor, or an auditor with a clipboard and a thirst for accountability. There is no “just for testing”; there is only regret. Validation is thy shield, skepticism thy sword. Trust client-side validation, and thou shalt know fraud. Prices shall shift, discounts shall appear from the void, transactions shall complete at the fraudster’s command. Trust an API to return today what it returned yesterday, and thou shalt know ruin. Guard the gates, lest SQL injections, XSS, and unbounded inputs pour through unchecked. Fraudsters are relentless, and their cunning infinite. Transactions shall be replayed, rewards shall multiply, bots shall breach thy rate limits, and finance shall not be pleased. If a discount check is in one service but the redemption in another, they shall find the gap. If a transaction may be reversed but the benefit remaineth, it shall be exploited. And the auditors will strike down upon thee with great scrutiny and furious security mandates; and you will wish thou hadst been more cynical.

V. Thou Shalt Not Be Deaf to Failures, Nor Hide Them From Others

A failure unseen is a failure unfixed. If it is not logged, it never happened—until it happens again, worse. If it is logged but cannot be traced, it is noise. If it alerts no one, it is a tree falling in an empty forest—heard only in the next postmortem. Thou shalt fail fast, loudly, and visibly—for silent failures bring ruin. Thou shalt log well, lest thou debug in darkness. And beware the Forgotten Logs of the Damned—for where no traces exist, fraudsters thrive, data rots, and incidents multiply unseen. Beware also the Curse of Misconfiguration. That which worketh in dev may betray thee in prod—a feature flag misset, a variable forgotten, a config unchecked. Guard against it, lest thou relearn in prod what thou shouldst have tested in staging.

VI. If It’s Not Explained, It Can’t Be Tested — and It Will Fail in Production

Untested code is not code—it is a rumour with a deploy script. But if no one knows what the code is meant to do, then tests are but ceremonial. QA shall nod gravely at plans built on vibes. Developers shall beam at green builds that prove only that something runs somewhere. And when it fails—silently, elegantly, and at scale—it shall glide through QA like a greased weasel, only to explode in production with all the dignity of a clown car on fire. Thus do the developers blame the testers, the testers blame the spec, and the spec—being blank—blames no one at all. That which is not written cannot be reviewed. That which is not reviewed cannot be tested. And that which is not tested shall most assuredly go live.

VII. The Code Is More What You’d Call Guidelines Than Actual Rules

A rule unbreakable is a rule too rigid. Engineering is trade-offs, risk, and judgment calls. Thou shalt follow the rules—unless thou knowest them well enough to break them wisely. A fragile process enforces compliance; a strong one enforces understanding. If thou must break a rule, break it boldly—but leave a comment so the next developer knoweth what thou didst and why. For there is nothing more cursed than a terrible decision made without reason, justification, or an escape plan. Rules exist for a reason, but if thou must stray from the righteous path, let there be a map for those who follow.

Author’s Note: The System Behind the Satire

This guide may read like folklore, but it’s built on data. The “Heretic’s Guide” emerged not from a whim, but from a comprehensive, incident-level risk analysis framework I’ve been developing and applying across complex environments. Each rule in this guide is a narrative crystallisation of real-world patterns—systemic failure modes that appear again and again in different guises, across different teams, tools, and timelines.

Beneath the humour lies structure:

• Each incident analysed through a consistent schema: affected component, issue type, recurrence, primary cause.
• Root cause tracing across layers—not just technical, but organisational: skills gaps, unclear ownership, risk treatment failures, structural overburden.
• Mapped controls against frameworks like ISO 27001 and SOC 2—flagging where mitigation strategies existed but silently failed.
• Scored outcomes for impact, predictability, and cost categories.
• Categorised corrective actions refined over time and applied across contexts.

It’s a synthesis of top-down standards and bottom-up insight. But insight alone rarely shifts culture. That’s why this guide exists: to communicate in a way that cuts through dashboards and governance PDFs. Every rule here is grounded in structured analysis—but reframed as cultural wisdom, the kind people might actually remember.

1. Susan Dray, usability and UX pioneer, as quoted in various human-computer interaction and design texts. ↩︎