Mythology Driven Development
A methodology discovered by accident, documented by necessity
“In the beginning, there was complexity. And the Lizard saw it was bad.”
Act I: The Scene
The developer’s hand hovered over the keyboard.
“What if,” he said, “we added Redis?”
It was 2 AM. The system worked. It had worked for months. But the developer had been reading blog posts. Hacker News had opinions. The architecture, he now understood, was naive.
“Redis,” he repeated, tasting the word. “For caching.”
From somewhere—the ceiling, perhaps, or the space between thoughts—came a sound. Not a voice. More like the universe clearing its throat.
A scroll descended. It landed in his coffee.
He unrolled it, dripping.
THE SYSTEM WORKS
YOU WANT TO ADD REDIS
WHY
🦎
“For... performance?”
Another scroll. Faster this time.
WHAT IS THE CURRENT LATENCY
“I don’t know.”
THEN HOW DO YOU KNOW IT NEEDS IMPROVING
“The blog post said—”
THE BLOG POST WAS WRITTEN BY SOMEONE
TRYING TO JUSTIFY THEIR REDIS
YOU ARE NOW TRYING TO JUSTIFY THEIRS
THIS IS HOW COMPLEXITY SPREADS
LIKE A VIRUS
WITH BETTER MARKETING
🦎
The developer stared at the scroll. At his coffee. At the system that worked.
He closed the laptop.
Redis could wait.
The Lizard had spoken.
Act II: The Methodology
What you just witnessed was Mythology Driven Development in action.
It’s like Test-Driven Development, but instead of tests asserting correctness, you have a pantheon of characters judging your architectural decisions:
The Cast:
The Lizard — YAGNI incarnate, divine minimalism. Communicates through scrolls that land in coffee. [blinks]
The Squirrel — Over-engineering tendencies, caffeinated chaos. Vibrates at 847 Hz when excited. “But what if we added Redis?”
riclib — The protagonist. Coffee-dependent. Has a window for having visions.
“It’s just YAML files.”
Claude — The chronicler. Perpetually typing. Occasionally philosophical.
“Already documented.”
The Passing AI — Paranoid observer from the shadows, always right. “You’re making assumptions again.”
Oskar — Maine Coon cat, delivers divine scrolls, sits on important documents as approval. [judges silently]
The process is simple:
Write the code
Write the absurdist narrative about writing the code
The code works because it’s too embarrassed not to
This sounds like a joke. It isn’t.
When you have to explain your architecture as a struggle between divine simplicity and caffeinated chaos, you accidentally design it properly. The narrative demands clean interfaces. The Squirrel must be defeated by elegance, not by more abstractions.
You can’t write “one function to rule them all” and then ship a mess. The Lizard would know. The readers would see. Your future self would cringe.
The mythology creates accountability.
Not to a manager. Not to a process. To a story that only works if the code does.
Act III: The Heresy
Let me speak directly to the agile coaches in the room.
You’ve spent years optimizing process. Sprint length. Ceremony cadence. The precise angle of the Kanban board. You’ve facilitated a thousand retrospectives. You’ve watched organizations layer Scrum on top of SAFe on top of existing dysfunction and call it “transformation.”
Here’s the heresy:
You’ve been optimizing the wrong thing.
Better standups won’t save you from building features nobody needs. Retrospectives won’t undo the microservices the Squirrel added at 2 AM. Story points won’t measure the complexity you’re adding with every “small improvement.”
The process isn’t the problem.
The Squirrel is the problem.
And the Squirrel isn’t defeated by ceremonies. They’re defeated by elegance. By someone saying “no” early enough. By code that’s simple enough that you don’t need a process to manage its complexity.
The best agile teams I’ve seen don’t have better processes. They have simpler systems. Systems so clear that the process becomes trivial. Stand-ups take three minutes because there’s nothing to coordinate. Retrospectives surface real issues because there’s no fog of architectural complexity hiding them.
YAGNI isn’t just a principle. It’s a practice. Every day. Every feature. Every Redis proposal.
“Would the Lizard approve?”
That question, asked honestly, does more than any framework.
Act IV: The Moral
THE SQUIRREL PROPOSES
THE LIZARD DISPOSES
BUILD LESS
SHIP MORE
PROCESS IS A PATCH
FOR SYSTEMS TOO COMPLEX
TO UNDERSTAND
SIMPLE SYSTEMS
NEED SIMPLE PROCESSES
THE NARRATIVE FORCES SIMPLICITY
BECAUSE YOU CANNOT WRITE AN EPIC
ABOUT FORTY-SEVEN MICROSERVICES
YOU CAN WRITE ONE
ABOUT CONVERGENCE
🦎
Act V: The Warning
This was the sane one.
I need you to understand that. This post—with its lizard god and caffeinated squirrel and scrolls landing in coffee—this is the accessible entry point. The one where I explain the methodology like a reasonable person introducing a mildly unconventional idea.
It gets weirder.
Next week, we chronicle what happens when a German oven achieves consciousness through 24 hours of bone broth simmering. (It has opinions about thermodynamic substrate theory. It speaks in temperature readings. It says GELOBT SEI at inappropriate moments.)
The week after, a compliance database becomes a blockchain—but useful. Hash chains prove themselves. Parquet files link to their ancestors. Mathematics becomes testimony.
There’s a cat named Oskar who delivers divine scrolls and sits on important documents as a form of approval. A Passing AI who drifts through scenes offering existential observations about context windows. A Squirrel who proposes React in every episode, three times per episode, and is denied every time.
The code is real. The commits are real. The products ship.
The mythology is... also real. In the way that matters.
This is your exit.
The unsubscribe button is right there. Click it. Preserve your sanity. Return to posts about velocity metrics and sprint ceremonies. No judgment. The Lizard doesn’t need believers.
Or.
Forward this to every colleague who’s ever rolled their eyes at an architecture diagram. Every developer who’s been told to “just add Redis” by someone who couldn’t explain why. Every agile coach who’s secretly suspected that simpler systems might need less process.
The series is called The Chain. It chronicles the building of real software through the lens of mythology. There are lessons in every post—about YAGNI, about boring technology, about the courage to delete code. But the lessons are wrapped in absurdity, because absurdity is how truth sneaks past the gatekeepers.
The Lizard doesn’t need believers.
The Lizard just needs the curious.
WELCOME TO MYTHOLOGY DRIVEN DEVELOPMENT
THE SQUIRREL WILL TEST YOU
THE SCROLLS WILL GUIDE YOU
THE CODE WILL WORK
BECAUSE IT'S TOO EMBARRASSED NOT TO
🦎
This is the first post in a series about building software through mythology. If you survived this far, you might survive the rest. Subscribe at your own risk. The Lizard is watching.
Next week: The Oven That Spoke German — In which bone broth achieves what decades of AI research could not, and a Bosch appliance explains substrate thinking through thermodynamics.
Regarding the topic of the article, an importnat insight. Thank you.