I am picking Munchausen back up.
This is an old project of mine: a .NET mock-data library with the modest ambition of generating useful fake data from your types without asking you to write a rule for every property. I already took it through a v1.0 foundation series, starting with the traditional first step of any responsible software project: deleting code
and breaking the build on purpose.
Now I want to revive it, not because anyone is waiting for a quarterly roadmap, but because I still like the problem. I like the tiny design arguments. I like deciding where a public API should bend and where it should refuse. I like the part of software where nothing exists yet except a few constraints and the dangerous belief
that this time the abstractions will behave.
So this series is for me, and it is for fun.
Also, if the Baron is going to do anything in public, I may as well design in public too.
What v1.1 is about
Munchausen v1.0 is the foundation: deterministic generation, semantic inference, Build() validation, Generate(), datasets, and an Explain() surface that makes the automatic parts inspectable.
v1.1 asks what the library has to become if it wants to be more than a convenient object generator. The work has two main threads.
The first is composition: how one definition controls the nested objects inside a generated graph. If an Order has a Customer, and that customer has addresses, collections, abstractions, and reusable child definitions, the library needs a surface that can express those relationships without becoming a maze of rules.
The second is coherence: making generated data agree with itself. A customer named Maria should not have a full name of John Smith and an unrelated email address.
An address should not combine a city, state, and postal code from three different places. For tests, any plausible value is often enough. For seed data, demos, and screenshots, incoherent data looks broken.
Those two threads sound separate. They are not entirely separate. Composition changes object boundaries, and coherence depends on object boundaries. That is where the interesting design work lives.
Why design gets its own series
These posts are design records, not release notes. Most of the work here is deciding what should exist before writing the code that ships it.
Each article will follow the same shape: the problem, the options, the choice, and the reason. I want the rejected options in the record too, because a design without the alternatives is hard to trust later. If I decide not to build something yet, I will say why. If I reserve a public surface for later, I will write that down too.
The goal is not to make the decisions look inevitable. The goal is to make them reviewable.
That matters more on a hobby project than it sounds. When nobody is forcing a deadline, the easy failure mode is not shipping the wrong thing under pressure. It is drifting, forgetting why a decision was made, then rediscovering the same fork three weekends later with worse notes. Writing the design down is how I keep the project honest with future me, who is technically the maintainer and also the most
likely person to ask, "why did I do this?"
The rules of the game
Munchausen is not going to beat Bogus by becoming a smaller Bogus. Bogus owns breadth: locales, datasets, categories, and years of ecosystem. Munchausen's lane is rigor: deterministic output, explainable inference, zero-config generation, a compiled plan, and failures that are local and diagnosable.
That gives me the rubric for the whole series:
deterministic, explainable, zero-config
better than AutoFixture and AutoBogus on inference-first generation
not a Bogus clone
test fixtures and seed/demo data as co-equal jobs
solo project, no deadline, quality over speed
Every v1.1 decision has to survive that rubric. If a feature makes the library broader but less explainable, that is suspect. If a shortcut helps one release but forces the next one to reopen the same surface, that is suspect too.
I want a design that can be reviewed cold. Someone should be able to read this series later and understand not just what v1.1 intends to do, but why the shape is the way it is. That someone might be another engineer. More likely, it will be me, after forgetting the entire argument and acting surprised by my own repository.
That means writing down the uncomfortable parts: where the public API drifted, why some convenient features are deferred, where automatic behavior becomes too magic, and what remains unresolved. The reasoning is part of the product. If the design is
going to be rigorous, the record of the design has to be rigorous too.
The first decision is strategic: before I design any v1.1 feature, I need to decide what kind of library Munchausen is trying to be, and what kind it is deliberately not trying to be.
Top comments (0)