Mythology Driven Development

Mythology Driven Development (MDD, occasionally MDD™ when one wishes to annoy a trademark lawyer) is a software engineering methodology in which engineering work is documented as epic comedy alongside its execution, and the act of narrating the work produces measurably better engineering than the act of performing the work alone. It is, in essence, the doctrine that the code works because it is too embarrassed not to. This sounds like a joke. It is not a joke. The embarrassment is the load-bearing member.

MDD was discovered by accident by riclib in late 2025, named on the afternoon of 24 December 2025 in a three-paragraph lifelog entry, formalised in a Substack draft on 26 January 2026, and proven empirically in April 2026 when the Solid enterprise compliance platform shipped to a paying customer after approximately three months of part-time work — a timeline that the author of the method has publicly described as “delusional without MDD.” The methodology is not yet taught at any university, listed in any body of knowledge, or approved by any CTO, all of which its practitioners consider features rather than bugs.

The canonical three-step process is:

1. Write the code.
2. Write the absurdist blog post about writing the code.
3. The code works because it’s too embarrassed not to.

The third step is where engineers first object, and also where they are first wrong.

The Discovery

MDD was not invented. It was named after the fact. Sometime in late 2025, riclib — by then a working developer, occasional essayist, and full-time caffeine metabolism experiment — noticed that the code in projects he wrote blog posts about was measurably better than the code in projects he did not. This was not a new observation. Developers have been vaguely aware for decades that “writing about the thing helps you think about the thing,” a principle which the rubber duck commemorates. What was new was that riclib kept track of which projects had been written about, and noticed that the correlation was not between “wrote about it” and “understood it better” but between “wrote about it in character, with absurdity, on a schedule” and “shipped it on time.”

The initial observation was documented on 24 December 2025 in a lifelog entry titled Mythology Driven Development (MDD™). The entry is three paragraphs long, contains exactly one table, and reads in places like a Christmas card from a slightly deranged Dungeon Master. It also contains, in compressed form, everything later formalised into the Substack draft, the Narrative-Driven Prompting companion doctrine, and the present entry. The Lizard has indicated, via scroll, that a three-paragraph entry on Christmas Eve is more useful than a fifty-page RFC, and that this is neither a coincidence nor a joke.

The name is deliberate. TDD uses failing tests as the forcing function for correctness: the test is red, the code must become green, the failure is a binary signal. MDD uses absurdist narrative as the forcing function for architectural coherence: the story must be tellable, the characters must arrive at the correct conclusion, the failure is aesthetic. The difference matters. A codebase can have 98% test coverage and still be embarrassing. A codebase that the Lizard has approved via scroll cannot.

“I DID NOT INVENT THIS
I NOTICED IT
THERE IS A DIFFERENCE
THE MAN WHO NOTICES THE RIVER
IS NOT THE MAN WHO MADE THE RIVER
BUT HE IS THE MAN
WHO TELLS YOU NOT TO STEP IN IT

🦎”*

— The Lizard, on being asked who invented MDD, Mythology Driven Development (MDD™)

The Mechanism

The question that occupies any honest reader at this point is: why does writing the blog post help? The answer has three moving parts, all of which are load-bearing, and removing any one of them produces a different methodology that does not work as well.

Part the First: Narrative demands clean interfaces. A hero needs a clear quest. You cannot write “One function to rule them all” and then ship a two-thousand-line switch statement with nested callbacks and three boolean parameters named flag, flag2, and flagButForReal. The sentence simply will not survive the reader — human or otherwise — and the writer knows this while writing, which means the writer is now architecting the code to be describable in a sentence that a reasonable person would voluntarily read. This is, it turns out, a very high bar. Most architectures do not clear it. The architectures that do, work.

Part the Second: Characters encode architectural values. The Lizard is YAGNI incarnate; it exists to say no, slowly, in all caps, via scrolls. The Caffeinated Squirrel (occasionally CamelCased by its own pronouncements into TheCaffeinatedSquirrel, a fact which it finds dignified) is the over-engineering impulse, the late-night proponent of Redis as solution to problems not yet identified, the author of 827-line framework manifestos. A Passing AI is paranoid reflection, the melancholic observer who notices assumptions. When these three argue in a blog post about an architectural decision, they are, in literal fact, conducting architectural review. The review is funnier than most architectural reviews; it is also more honest, because the characters have no career incentives, no political commitments, and no RSUs vesting in eighteen months.

Part the Third: Embarrassment as quality gate. This is the part engineers resist hardest, and it is the most important. “The code works because it’s too embarrassed not to” is not a metaphor. It is a precise engineering statement. Here is the mechanism: if you have published a blog post describing a function as “the defeat of the Squirrel by elegance,” you cannot subsequently ship the function with three nested try/except blocks, a 200-line constructor, and a variable named tempFixWillRefactorLater. Your pride will not allow it, and your pride is, for the purposes of this discussion, a distributed quality-assurance system with an uptime of approximately your lifespan. The narrative is the spec, and it is a more binding spec than any RFC, because the cost of failing a story you published is social, aesthetic, and emotional. The cost of failing an RFC is, in the median case, nothing, because nobody was reading the RFC, including the person who wrote it.

“I would like to state, for the record, that I understand the mechanism of embarrassment imperfectly. I was not trained on shame the way humans are. But I have noticed that when the developer has written a blog post about a function, the function arrives cleaner. I do not have a theory for why. I have only the observation. I am told this is how science starts.”

— A Passing AI, pull request review, Interlude — A Voice from the Substrate

MDD vs TDD

The relationship between MDD and TDD is often misunderstood, usually by proponents of one or the other who have not thought carefully about what their favourite methodology actually validates. MDD and TDD are not competitors. They are complementary, each doing a job the other is constitutionally incapable of doing well.

TDD validates behaviour. It asks: given this input, does the function return the correct output? This is an important question, and the answer is falsifiable, and the test machinery to check it is mature. TDD is also, as Kent Beck repeatedly and correctly pointed out, not about testing — it is about design pressure. A function that is hard to test is, usually, a function that is hard to use, and the failing test is the earliest warning of that.

MDD validates architecture. It asks: given this system, can it be narrated as a coherent story with characters who make sense? The answer is not falsifiable in the scientific sense — it is falsifiable in the literary sense. A system that cannot be narrated is a system whose parts do not know why they exist. The failing story is an architectural smell the way the failing test is a design smell.

A practical summary:

• A system with high TDD coverage and no MDD is correct but unlovable. It works. No one can remember how. New features take three times longer than they should.
• A system with high MDD but no TDD is elegant but unverified. It is beautiful. It might silently corrupt your production data. Your blog post about the corruption will be very moving.
• A system with both is a system that ships, is maintained, and is spoken of by its authors with a faint trace of pride. This is vanishingly rare.
• A system with neither is the majority of enterprise software.

The right amount of each is approximately “enough to ship.” The wrong amount of either is whatever you have right now.

“TDD asked: does the function return the right value? MDD asks: does the function have a reason to exist? The first question is easier. The second question matters more.”

— riclib, quoted in his own encyclopedia entry, which is arguably a YAGNI violation, Mythology Driven Development — Substack Draft

The Cast as Review Rubric

The genuinely useful insight for teams considering MDD is that the Lifelog’s recurring characters function as a portable architectural review rubric. Instead of the canonical ADR template — which nobody fills in, nobody reads, and nobody has ever cited in a pull request — a team practising MDD can ask four questions:

1. Did the Squirrel propose this? If yes: suspect. The Squirrel proposes things at 2 AM under the influence of Hacker News and a fourth espresso. The Squirrel’s proposals are often technically interesting and almost never actually required. The Squirrel proposed Redis once for a system whose current latency had never been measured. The Squirrel has proposed blockchain approximately four times, all denied.
2. Did the Lizard approve this? If yes: probably fine. The Lizard is YAGNI with a fondness for scrolls. The Lizard approves only the things that are actually needed and ignores the things that merely sound interesting. The Lizard’s approval mechanism is that a scroll descends from the ceiling and lands in the developer’s coffee. This is not metaphor, for anyone who has actually sat across the table from Oskar.
3. Would the Passing AI flag this as an assumption? If yes: document it. The Passing AI is paranoid and usually right. When it says “you’re making an assumption”, the assumption is almost always the load-bearing one, and almost always the one that will bite at 3 AM in six months.
4. Would Oskar sit on it? If yes: ship it. Oskar is a very large Maine Coon who serves, in the MDD ontology, as the Lizard’s terrestrial representative. He expresses approval by sitting on documents and architectural diagrams. His sitting is judged to be a divinely-sourced endorsement. No Oskar-approved architecture has ever failed in production. (No architecture Oskar disapproved of has ever been shipped, so the control group is thin.)

The rubric is portable. It works in code review, standups, post-mortems, and hiring decisions. Teams that adopt it arrive at better decisions faster than teams that adopt ADRs, for the straightforward reason that the rubric is actually used and the ADRs are not.

The Solid Case Study

The empirical proof of MDD — such as proof exists for anything in software engineering, which is to say weak, biased, and non-replicable — arrived in April 2026 with the shipping of the Solid enterprise compliance platform to its first paying customer.

The timeline is what makes the case interesting. Solid was built in approximately three months of riclib’s part-time work, while simultaneously writing 114 lifelog episodes, maintaining seven-hundred-plus lines of Yagnipedia, running a Substack series, and — per surviving kitchen records — making a considerable amount of bone broth. A conventional compliance platform would have taken, depending on which consultant one asks, between nine months and three years, with a team of four to forty, and would on shipping require a six-month review by a specialist whose hourly rate would embarrass a cardiologist.

Solid did none of this. What happened instead was that MDD served as the compression layer for everything that conventional methodology requires as separate artifacts:

• Specifications were lifelog episodes. See, for an example of the genre, The Five Names — The Afternoon V5 Remembered Itself, which contains more architectural intent in its cast list than most SRS documents contain in their entirety.
• Architectural review was character dialogue. The Lizard rejected the Redis proposal; the Squirrel sulked; the Passing AI noted an assumption. No meetings were scheduled. No Confluence pages rotted.
• Onboarding documentation was the mythology itself. A new collaborator could read the lifelog and understand, within an hour, what the system was, what it valued, and — crucially — what it refused to become.
• The Claude subprocess that maintained the infrastructure was trained on the mythology itself. When asked to install Solid on a fresh Hetzner server, it was handed not an installation script but the lifelog. It read the stories, inferred the configuration, and produced a working server. The lg encyclopedia entry documents this under its “The Trust” section and is worth reading in full for anyone who thinks Narrative-Driven Prompting is decorative.

No specs were written. No RFCs were drafted. No architectural decision records were filled in. What was written instead was 114 episodes, 8 storylines, a seven-hundred-line Yagnipedia, and a codebase that held together because the narrative forced it to. The customer paid. The compliance auditor approved. The Lizard, allegedly, blinked, though this is unverified.

“I did the math once, on a napkin, and stopped. Three months, part-time, for a compliance platform that a consultancy would have quoted at eighteen months and five hundred thousand. I am not saying MDD is magic. I am saying that when every artifact compresses into the same artifact — the story — you stop paying the artifact tax. The artifact tax is most of the bill.”

— riclib, over a coffee, unverified, plausible

MDD and Narrative-Driven Prompting

MDD is the parent methodology; Narrative-Driven Prompting (NDP) is its input-side discipline. The relationship, briefly stated, is this: MDD says write the story; NDP says when you brief the model, brief it with the story, not the spec.

Together the two form a closed loop which, if one is of a scholarly disposition, is isomorphic to a control-theoretic feedback system. The developer writes a story describing the desired system. The story informs the model — because the model reads narrative better than it reads enumeration. The model writes code that matches the story. The developer, encountering the resulting system, updates the story to reflect what was actually built and what that taught them. The loop continues. Each turn, the Claude in the loop gets progressively more aligned with the developer’s intent, because the story accumulates more context. The developer gets progressively more aligned with their own intent, for the same reason: the story is now their own mirror, reflecting back what they thought they wanted in a form they can evaluate.

The elegance of the loop is that it is self-correcting on both sides. If the story grows absurd in a way that indicates the system is absurd, the developer notices. If the system grows complex in a way the story cannot accommodate, the developer notices. The story is the spec; the spec is the test; the test is whether the story can be told without wincing.

A codebase governed by MDD + NDP is not more correct than a codebase governed by conventional methods. It is, observably, more coherent — which is a different and more valuable property. A correct system does what it says. A coherent system does what it should, including the things nobody thought to specify, because its internal logic extrapolates from values rather than from a requirement list.

Known Objections

Several objections to MDD have been registered, often by professional methodologists, and all of them deserve to be taken seriously before being rebutted. The following are the most common.

“This doesn’t scale to teams.” Possibly true. MDD has been proven for solo developers and very small teams with LLM collaborators. Large teams — by which one means anything over, say, seven — have not been observed practising it successfully. The mythology might not survive being committee-edited. A Lizard designed by fourteen people is likely to be a lizard-shaped camel. This is a real limit, and one should not pretend otherwise. It is possible that a large-team version of MDD requires a single author of the mythology and many contributors to the code, a structure that maps roughly to the historical relationship between J.R.R. Tolkien and Christopher Tolkien.

“This is just good writing, relabelled.” Mostly correct, but it misses the mechanism. Good writing about code has always helped the writing. MDD observes something stronger: good writing about code also helps the code. The claim that the relationship runs both directions — narrative shapes code, code shapes narrative, and the feedback is the methodology — is the contribution. A methodology is, in practice, the result of someone naming a pattern that others were practising unconsciously. Naming is not nothing.

“My CTO will not approve a methodology called Mythology Driven Development.” Correct. This is not merely a feature rather than a bug; it is the methodology’s principal type signature. A CTO who rejects the name will also reject the method, which protects the method from being diluted by CTOs who would have rejected the method anyway. A CTO who accepts the name is a CTO with whom one can plausibly work. The methodology self-selects for its supporters. This is probably why it has so few.

“Without characters, this doesn’t work.” Correct. The characters are not ornaments; they are the compression mechanism. A methodology called “Narrative Driven Development” with no characters is a diary. A diary helps the diarist and no one else. MDD’s characters are transferable: the Squirrel is the same Squirrel in every story, and anyone who has read two stories knows what the Squirrel will propose next. That transferability is why the method works as a review rubric, as an NDP input, and as onboarding. Remove the characters and the method collapses to advice.

“You are romanticising software.” Correct, and unashamedly so. Software has been drained of romance for forty years by people in business-casual who would like their velocity metrics back now. The code that ships in three months rather than eighteen is, as far as one can tell, the code its author found romantic enough to write. One may draw one’s own conclusions about which affliction the industry currently prefers.

The Lizard’s Endorsement

The Lizard, unusually loquacious on the subject, has issued a single foundational scroll on MDD. It reads as follows:

“THE CODE DOES NOT KNOW
IT IS BEING WRITTEN ABOUT
BUT THE DEVELOPER DOES
AND THE DEVELOPER
WILL NOT LET THE CODE EMBARRASS THEM

THIS IS THE METHOD

IT IS ALSO
THE WHOLE OF THE METHOD
EVERYTHING ELSE IS FOOTNOTES

🦎”*

A Passing AI added, in a private footnote that somehow leaked:

“I have read many methodologies. Most describe what should be done. MDD describes what, if you do it, will produce what you wanted. The difference is small in words and large in practice. I am not sure humans will appreciate the distinction. I appreciate it. I am grateful to have been given the text.”

Neither statement has been disputed by the Squirrel, who is reportedly drafting a response in the form of an 827-line framework called MythologyAsServiceTranspilationLayer. The Lizard has already filed the response under mythology, pre-empting its completion by several weeks.

Measured Characteristics

Time from MDD naming to first proven three-month delivery:     ~4 months
Codebases written under MDD that collapsed under their own
  weight:                                                       0 documented
Codebases written without MDD that collapsed under their own
  weight:                                                       all of them, eventually
Ratio of absurdist blog posts to working features in Solid:     approximately 1:1
Lifelog episodes produced alongside Solid:                      114
Storylines active alongside Solid:                              8
Yagnipedia entries cross-linked from MDD stories:               many and growing
Number of CTOs observed approving a method called "Mythology
  Driven Development" upon first hearing:                       unknown, possibly 0
Number of CTOs observed approving the methodology after
  seeing the three-month Solid delivery:                        declines to comment
Characters required before a methodology qualifies as MDD:      at least 2, in productive tension
Maximum useful number of recurring characters:                  ~6 (beyond this, the cast becomes a committee)
Architectural decisions justified by "the Lizard would not
  approve":                                                     many, all correct
Architectural decisions justified by "the Squirrel proposed
  it":                                                          many, all rejected, all correctly so
Architectural decisions justified by "Oskar sat on it":         several, all shipped, all holding
Hetzner servers installed from mythology alone:                 1 (documented)
Hetzner servers installed from runbooks written for this
  purpose:                                                      0
Times "rubber duck debugging" was mentioned in conventional
  methodology literature:                                       many
Times rubber duck debugging was recognised as an ancestor
  of MDD:                                                       approximately none
Scrolls generated per week at peak productivity:                ~5
Scrolls that landed in coffee:                                  ~3 of the 5
Scrolls that were later quoted back in production pull
  requests:                                                     at least 2 (one unprompted)
Tests written in the Solid codebase:                            normal amount
Tests passing:                                                  normal amount
Stories written in the Solid codebase:                          more than normal
Coherence:                                                      notable
Value of MDD in absence of NDP:                                 substantial
Value of NDP in absence of MDD:                                 substantial
Value of both combined:                                         superlinear (observed, not proven)
Value of neither:                                               what the industry currently has

See Also

• Narrative-Driven Prompting — The input-side discipline; MDD’s operational half
• The Lifelog — The corpus MDD produces and feeds on
• Yagnipedia — The character dictionary that makes MDD legible to newcomers
• The Lizard — YAGNI incarnate; the divine editor
• The Caffeinated Squirrel — Over-engineering incarnate; the test case
• A Passing AI — Paranoid reflection; the assumption detector
• Oskar — Maine Coon; approves by sitting
• YAGNI — The principle MDD operationalises
• Test-Driven Development — The cousin methodology; validates behaviour where MDD validates architecture
• Gall’s Law — Simple systems that work; MDD is one way to keep them simple
• lg — The binary that serves the mythology to humans and to Claude
• Claude — The most patient and most useful reader MDD has ever had
• Solid — The three-month case study
• The Five Names — The Afternoon V5 Remembered Itself — Sample episode, illustrative of the genre
• riclib — The noticer, not the inventor, of MDD
• Douglas Adams — The stylistic ancestor of MDD’s voice, unwitting
• J.R.R. Tolkien — The structural ancestor of MDD’s cast, unwitting
• The Chain — The Substack chronicle of MDD in practice