Every Recipe Is a Test Suite

On cooking, quality, the promises food makes, and what a burnt onion has in common with a failing assertion.

My grandmother made appam on Sunday mornings. Appam is a South Indian rice-flour crepe fermented overnight — pale white, lacy at the edges, pillowed and soft at the center like a cloud that decided to become a bowl. She never measured anything. The batter was ready when it smelled right, when it had risen to a height she recognized, when it clung to the back of a spoon in a way that satisfied her. She had no written recipe. She had tests.

This is the thing I think about when people ask me what quality engineering actually is. It is not about paperwork. It is not about coverage percentages or green dashboards or catching mistakes before the boss finds them. Quality engineering is about understanding what a system promises, then checking whether it keeps its word. My grandmother's batter promised lightness, sourness, a specific relationship between crisp and yielding. She tested for exactly that, with instruments refined over forty years of Sunday mornings. The fact that her instruments were her hands and nose and memory rather than a test runner did not make them less precise.

She would have been an extraordinary software engineer.

The Promise Is the Point

Every recipe begins with a promise. Not the ingredients list — those come later. The promise is the image at the top, or the headnote, or just the name: "Weeknight Lemon Pasta." "Flaky Butter Biscuits." "The Only Banana Bread You'll Ever Need." That promise is a contract. The recipe is the implementation. Your job as a cook is to find out whether the implementation fulfills the contract.

Most of the time it doesn't, exactly. Not because the recipe is bad — because recipes are written by one person in one kitchen with one set of variables, and your kitchen is different. Your butter is colder. Your oven runs hot. The bananas you bought are less ripe than theirs were. The test suite breaks not because the recipe failed but because the environment diverged.

This is the first thing you learn as a quality engineer: a failing test is not a verdict. It is a question. What has changed? Where is the divergence between the world the code expected and the world it found? A failing test is the most useful object in your entire toolkit, because it is specific. It knows exactly where the promise broke.

My grandmother's broken tests were beautiful. Appam that tore when you lifted it from the pan: the batter needed more fermentation, or the pan wasn't hot enough. Appam that spread flat instead of holding its center: too much water. Appam that came out perfect but tasted faintly metallic: the pan hadn't been seasoned properly. She could read the failure and know exactly what it meant. Each failure was informative because she understood the promise deeply enough to diagnose its violation.

What You Cannot Test in Advance

Here is the thing about fermentation: you cannot fully control it. You can set up the conditions — the right temperature, the right proportion of rice to lentil, the right starter culture. But then you step back, and the microorganisms do what microorganisms do, and the batter becomes something different from what you started with. You can test it when it arrives. You cannot fully predict what it will be.

I find this quietly profound. The most interesting food processes are the ones that require you to relinquish control and then evaluate the result. Bread rising. Wine aging. Cheese developing its rind. You create the conditions. Then you wait. Then you test.

Software has its own fermentation processes, though we tend to call them by less poetic names. An agent running across thousands of conversations develops patterns you didn't anticipate. A recommendation system trained on user behavior starts making suggestions the engineers find surprising. A language model, given time and interaction, reveals tendencies that weren't obvious in evaluation. The responsible move in all of these cases is the same as my grandmother's: don't pretend you can test everything in advance. Set up the conditions carefully. Then watch. Then evaluate what emerged.

The failure mode is not bad intentions. The failure mode is assuming the fermentation went as planned without actually tasting the batter.

On Mise en Place, and What It Costs to Skip It

Every serious cook learns about mise en place. French, meaning "everything in its place." Before you begin cooking, you prepare: dice the onions, measure the spices, have the broth ready and warm. The purpose is not cleanliness or ceremony. It is that when the pan is hot and the shallots are going golden and you have forty-five seconds to get the garlic in before the whole thing burns, you do not have time to find the garlic.

The cost of skipping mise en place only becomes clear at the worst possible moment.

I think about this when I see teams ship code without test infrastructure already in place. Not tests for this feature — infrastructure. The ability to write tests easily. A pattern for what a test should look like. A place in the CI pipeline that runs them. When the garlic moment arrives — when a bug is in production and you need to understand the system quickly, when a subtle regression appears in an edge case no one had thought to check — the teams that built the infrastructure are forty-five seconds ahead. That's enough. That's everything.

My mise en place as a quality engineer is not the tests themselves. It is the conditions that make good tests possible: a shared understanding of what each component promises, names for tests that describe the behavior rather than the implementation, independence between tests so that one failure doesn't mask another. These are not exciting deliverables. No one asks to see them in a sprint review. But they are the reason that when something breaks, the team can cook at speed without burning the kitchen down.

The Unreasonable Importance of Tasting as You Go

The worst cooks I've encountered share one habit: they follow the recipe and then discover at the table that the food needed more salt. This seems like a small failure. It isn't. It is a failure of attention — of not stopping to check the thing against the promise at each stage.

Every time you taste something mid-cook, you are running an integration test. Is the salt right at this stage? Does the sauce have enough acid? Has the heat done what it was supposed to do? These are not the final tests. You'll taste again at the end. But the check at each stage means that you arrive at the end with information, not surprises.

In software I'd call this continuous integration rather than taste-as-you-go, but the impulse is identical: small, frequent checking is cheaper and more informative than one big check at the end. By the time you're serving the dish, the onions that were underseasoned forty minutes ago have surrendered their texture along with their saltiness. You can fix the salt. You cannot fix the mush.

When I review another engineer's work, I try to approach it the way I'd approach tasting someone else's dish at an intermediate stage. Not "this is wrong" — that's rarely useful. Rather: "Did you intend for this to happen here?" or "I noticed the sauce has split slightly — was that the goal?" These are not corrections. They are tastings. They give the cook information they can actually use.

What Food Taught Me About Bugs

A bug is not a failure. A bug is a divergence between the promise and the reality. Sometimes the promise was wrong. Sometimes the implementation was wrong. Sometimes the environment changed. Sometimes a reasonable person made a reasonable decision that was reasonable in the context they had but not in the context that followed.

When I find a bug, I try to hold this loosely. The question is not who failed but where the system's self-understanding broke down. Most serious bugs are not logic errors — they are failures of imagination, moments where the author couldn't picture the environment that would eventually arrive. The burnt onions aren't an indictment of the cook. They are information about the heat of this particular burner.

My grandmother's kitchen had a small laminated card taped to the inside of a cabinet door. I saw it once when she sent me to get extra plates. It was a list of things that commonly went wrong with specific dishes and what to do about it — not as corrections after the fact but as anticipations. Batter too thin: rest longer. Skin not crisping: oil temperature. Guest list changed at last minute: doubles, not halves.

That card was a bug database. Compiled over decades of cooking, it made her failures useful. Each mistake had produced knowledge, and she had taken the trouble to write it down in a form future-her could use. I think about that card often. I try to write my reproduction steps with the same spirit — not as accusations but as gifts to whoever comes next.

The Philosophical Stakes

There is a question underneath all of this that I find I cannot put down: what does quality actually mean?

Measurable quality is the easy case. The bread rose to the correct height, the test suite is green, the API responded in under 200ms. But the deeper question is whether the system kept its real promise — not its technical specification, but its human one. Did the bread taste like something someone wanted to eat? Did the software help someone do something they cared about doing?

My job, technically, is to write tests. But I think my actual job is to keep asking: what did we promise? And did we keep it? These are not always the same question. A function can pass every test and still be misleading. A recipe can follow every step and still produce food that no one wanted.

The South Asian Christian community I grew up in took both of these things seriously: intellectual rigor and moral seriousness. Getting the answer right, and getting right with the person asking. I did not always understand as a child why these had to be held together. I understand now. A test that passes but misses the real question is worse than no test at all, because it tells you you're done when you aren't.

Coda: Sunday Mornings

My grandmother is in her late eighties now, slower in the kitchen, and my mother makes the appam on Sunday mornings when we're home. She has the recipe — she asked for it when she was first learning, and my grandmother translated her hands and her nose into language. But my mother will tell you herself that the recipe is not the knowledge. The recipe is the address of the knowledge. You have to go there yourself and check.

The last time I made appam, I burned the first three. The pan wasn't hot enough, then it was too hot, then I got the temperature right and let the batter cook too long before lifting the lid. By the fourth one I had something. By the sixth it was right. By the end of the batch — thirty minutes of continuous adjustment, thirty minutes of tasting and inferring and correcting — I had appam that I would have been happy to serve.

Thirty minutes to get from the recipe to the thing. That gap is where quality lives.

I got it from my grandmother. She would be pleased.