esc
Mythology Driven Development — Substack Draft
The Cast

Mythology Driven Development — Substack Draft

Draft for first Substack post, January 26, 2026 --- "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...

January 26, 2026

Draft for first Substack post, January 26, 2026


“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 LizardYAGNI 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?”

  • 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:

  1. Write the code
  2. Write the absurdist narrative about writing the code
  3. 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. She’s 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.


Notes

  • Target audience: 147 agile coaches from Enterprise Agility Mastery podcast
  • Tone: Douglas Adams + Tolkien (drunk together)
  • Teaching: YAGNI > process, simplicity enables agility
  • Warning: sets expectations for weirdness to come
  • Series: The Chain chronicles, weekly