“Eating the recipe” is a term I’ve made up to try and describe the kind of mistakes that get made by mixing up levels of abstraction.
Humans do not struggle with the distinction between a recipe and the food that the recipe describes how to make. We would not make the mistake of eating a sheet of paper that describes how to make spaghetti, instead of eating the spaghetti. We do, however, design and use systems that make this kind of mistake a lot, or make it easy for humans to make this kind of mistake.
I’ve been meaning to write this up here for a while, but was re-inspired by this story:
That guy wanted to buy a box of boxes from Amazon, but kept getting sent random boxes of other things. It turned out that those other things were packaged in the boxes he was actually trying to buy. The system was confused because “it” was reading the barcodes on the boxes packaging those other products as if they were the barcodes for the actual boxes.
The concept of “a box of boxes” is not difficult for humans to understand. We are unlikely to eat the recipe in this situation. But a human-designed system did eat the recipe, apparently without much prompting.
The other common scenario where recipe-eating occurs is due to confusing abstractions in software. For example, we can get used to first-class functions quite easily, but when dealing with several different layers of callbacks in “callback hell”, it becomes a lot more likely that we’ll eat the recipe and pass or call the wrong callback.
When software design is heavily abstracted, the same effect arises in more
situations. It’s easy to eat the recipe when dealing with a
FactoryManagerManagerFactory, for example, and worse abstractions exist in a
lot of software projects. Poor naming exacerbates this, but we have to consider
the trade-off of every abstraction itself, and how clear it really is without
There’s also a trend as you learn something new or become familiar with a new system. At first, you end up eating a lot of recipes as the different layers of abstraction are hard to distinguish. Later, as you become more familiar with the domain, it becomes increasingly obvious that a sheet of paper is not a steaming bowl of spaghetti. This is partly why newbies to a topic can seem hilarious to domain experts, and why it’s important to involve domain experts in a project.