Hacker News Reader

This is the difference between a commercial kitchen and your own kitchen on a normal day. Strict mise en place applies to the former.

In a commercial kitchen, you'd better have the peppers (say) chopped and ready so you can use them. Not only for a single serving of one dish, but for all plates you expect to make of any dish with chopped pepper in it.

You cannot pipeline chopping the peppers with frying the onions when you are preparing several dishes at once like you can at home. At home, you have maybe a dish or two, and you know you have time while the onions are frying. You also know that these are the only dishes to be cooked and no one is going to order something else while your onions are frying.

It also applies to software. If you're in a calm, steady development flow, you can pipeline tasks as you need. You can work on the docs while blocking work on the library, it doesn't matter. However, when you'be got periods of high-speed, fast-paced environment with deliverables required right now and bugs flying at you, finding a way to move groundwork out of the stressful time is a good idea.

I would suggest that it's never a good idea to be cooking several dishes at the same time in the world of software. Software and cooking are completely different in terms of the cost of making a mistake. A single bug in production can take more time to find and fix than the work in the first place. I can see that in a commercial kitchen that it makes sense to prepare all the ingredients before because you can do this before your customers arrive and it's better to chop 100 carrots in one batch than 100 carrots at different times, but that's very different from software development.

Depends what you're doing. If a small team supports multiple products (internal or external) concurrently, it's almost inevitable.

Obviously, all analogies break down eventually, but I would say something similar to the article: if you anticipate needing to swap some component out, or you are concerned that some activity contains substantial project risk (in the analogy, this is chopping peppers while onions are frying and hoping that no one orders another dish) will be needed during a period of high pressure (lead up to a release, say), try to front-load that effort into a more forgiving timeframe (i.e. chopping peppers before the restaurant starts to take orders). Do the experiments, write the documentation, make sure everyone knows what's going on, then, hopefully, it's less project risk at a time when you can't afford it. You're saving risk, not necessarily time. And you can't eliminate all the risk.

If that's just not possible because you're too busy 100% of the time, you're probably on a death march and it's already too late: once the orders are coming in, if you haven't prepped the peppers, you just have to deal with it, and if that makes any dishes late and customers angry, tough.

That's a good point. In a commercial kitchen one can declare "bankruptcy" by throwing out a single dish (or perhaps a set of dishes if one component was bad and the badness wasn't detected before use). But in software, declaring "bankruptcy" is the dreaded ground-up rewrite. It's like burning the whole restaurant down and starting over.

I think another important difference is that software is much less predictable. Thanks to low/zero-cost replication, we spend much more time doing something novel than a commercial chef does. If a developer is doing the same thing over and over, that's a an opportunity to extract a service or a framework or a library. Whereas restaurants have much more predictable workloads, making it much safer to, say, chop 100 carrots than to write 100 classes in advance of need.

Dunno, throwing out one dish is more like deleting one file. The whole codebase being the restaurant.

Isn't a bug in production more like food poisoning your customers in this analogy? Both take more work to fix than the effort put in. Where a bug caught by automated tests is more akin to noticing you overcooked the steak before sending it out?

Then you are a "bad operator" according to Escoffier:)

  "I should thus resemble those bad operators who, having neglected their mise en place, are obliged to make it in the course of other work, and thereby not only run the risk of making it badly, but also of losing valuable time which might be used to better advantage.
  Elementary preparations consist of those things whereof one is constantly in need, which may be prepared in advance, and which are kept available for use at a moment's notice."

A modern guide to cookery, A. Escoffier 1907

> Elementary preparations consist of those things whereof one is constantly in need, which may be prepared in advance, and which are kept available for use at a moment's notice.

I think this one sentence much better describes what I feel the spirit of mise en place is in regards to software. Things which you need, which may be prepared in advance. When I think of it this way, I am reminded of the many little scripts, aliases, editor plugins, configuration settings, etc. that I have accrued over the course of my day job that make it easy to do the things I have to do many times per day. For example, our product can be launched in several different configurations, so I have a script that takes a build directory and a configuration parameter and sets up everything so it's launched exactly as it should be; I also have a bunch of GDB scripts to set up the environment and to display data in a meaningful fashion; and many more things like that. Unlike in cooking however, once I have set up some aspect of my msie en place, it stays that way forever - it's like if you cut the peppers once and you have an infinite bucket of cut peppers. When looked at that way, I think it makes sense to make your mise en place as you go, since you don't really know what you need before you need it. Obviously a lot of trivial things should be set up beforehand and shared with the team, but every programmer has a slightly different workflow, so it pays to write some simple little tools for yourself when you come to need them and put them in your mise en place.

I believe the OP says exactly that he doesn't make it in the course of other work, but during downtime, which is overall faster.

Frying onions is not downtime.

This is the "your example is invalid, therefore your argument is invalid" fallacy.

It's not a fallacy. There is downtime in baking, but not cooking.

"There's no downtime in cooking" is different from "cooking onions is not downtime". Though you'd still need to clarify "even if stuff is already chopped", I guess.

“Cooking onions is not down time” directly follows from “there’s no downtime in cooking.” If there is no downtime in cooking is true, then *cooking* onions cannot be downtime.

Indeed, and if the GP has said "there's no downtime in cooking", it would have been apt.

"Cooking onions is not downtime" isn't an effective rebuttal of the general point of "I chop things during downtime, for example when cooking onions".

If cooking onions is not downtime, then it absolutely is an effective rebuttal to the general point of "I chop things [only] during downtime, for example when cooking onions".

"I only tell the truth, for example when lying" is irrecoverably self-invalidating. There is no second example that could nullify its effects. The argument is made invalid by that example specifically. (Not to mention, it calls into question the claimant's understanding of what it means to tell the truth.)

You have misidentified the fallacy here.

How is "there's no downtime in cooking" better than "Cooking onions is not downtime?" Both are assertions without backing evidence. For instance, it's possible for "Cooking onions is not downtime?" to be true (e.g. cooking onions requires active work) while "there's no downtime in cooking" is not true (e.g. cooking chicken broth involves downtime).

Because one is an effective counterargument if true, the other isn't, even if true. Hence, the former is a better counterargument.

It kind of is, versus an active task like chopping.

Yeah, I understand the term via Anthony Bourdain and his book Kitchen Confidential. I think his description of it also leads to some good software analogies:

Mise-en-place is the religion of all good line cooks. Do not fuck with a line cook’s ‘meez’ — meaning his setup, his carefully arranged supplies of sea salt, rough-cracked pepper, softened butter, cooking oil, wine, backups, and so on. As a cook, your station, and its condition, its state of readiness, is an extension of your nervous system... The universe is in order when your station is set up the way you like it: you know where to find everything with your eyes closed, everything you need during the course of the shift is at the ready at arm’s reach, your defenses are deployed. If you let your mise-en-place run down, get dirty and disorganized, you’ll quickly find yourself spinning in place and calling for backup. I worked with a chef who used to step behind the line to a dirty cook’s station in the middle of a rush to explain why the offending cook was falling behind. He’d press his palm down on the cutting board, which was littered with peppercorns, spattered sauce, bits of parsley, bread crumbs and the usual flotsam and jetsam that accumulates quickly on a station if not constantly wiped away with a moist side towel. “You see this?” he’d inquire, raising his palm so that the cook could see the bits of dirt and scraps sticking to his chef’s palm. “That’s what the inside of your head looks like now.”

One thing that makes software different than other jobs is that most of the space in which we work is what we ourselves have built in previous days. A messy codebase makes it hard to have a calm, clear presence. Which in turn leads to a messier codebase. There are whole projects, probably whole companies, where the inside of everybody's head looks like that.

So for me, a key part of developing is creating and projecting the sorts of work that over the long term enable that feeling of "the universe is in order". Indeed, you could write a history of software development in terms of how much progress we're making in that.

I’ve worked in kitchens, and this characterization favors my experience much more closely than does the author’s. In a kitchen, mistakes are costly; imagine that you have one chance to compile your code, and if it doesn’t compile, then you lose that code. In fact, I’d go almost as far to say that cooking (in a professional kitchen, where mise en place really matters) and software development are about as different as any two disciplines you can imagine - cats and dogs. The element of time, the cost & consequences of mistakes, the discipline of routine, and the nature of problem solving couldn’t be more dissimilar in these two practices. In fact, they seem different in almost every way, and I’m struggling to find a reasonable common methodology or strategic principle.

Not a former cook, but a former barista, and this resonates with me deeply. The same underlying emotion that drove me to continually wipe down my station is the same that drives me to be fastidious about minutiae in my code bases.

I'll have to check this book out!

This is definitely not representative of the book. But I loved it, as do many others, so I doubt you'll find your time wasted.

I do tend to cook like this, but that's because I'm an inexperienced cook :-) I don't trust my ability to complete a prep task in the bounded amount of time you have once you've actually started cooking, so unless the time available is clearly long and the prep task trivial I tend to do most to all of the prep in advance. You're absolutely right that it takes longer in wall clock time but I find it less stressful, and that's valuable to me.

This is good sensible planning, and it can shift as you get more experienced. You'll recognise orders that make sense (I know I need the oven preheated so start that now, then chop / I have a wait before this step and just need to chop the mushrooms which I know only take me X so I'll do that then).

You are increasing your risk when you do this, and probably reaching a short outcome. Frying, or at least sauteing, is not baking. It can be as active an activity as you want it to be. If you're letting that many onions sit for that long without rearranging, you probably have either too much on the pan or you're cooking unevenly. Not to mention that, if your other task goes slower than expected, or you are interrupted, you get burned onions or other timing mistakes.

Another good software example is having slack. If you're always busy, you may not be working on the right things.

Within software I interpreted it to mean a few things:

* Physically clean desk and laptop.

* Commit old code changes before working on new ones.

* Main branch is pulled.

* Fix the build before writing more code.

* Set up tmux or whatever so every terminal is in a convenient place.

* Check that the failing test fails as expected.

* Set up text editor/IDE to have easy access to relevant files and browser to have access to e.g. the relevant JIRA.

* Close irrelevant browser windows and applications.

etc.

Dont think it means "do the easy tasks first", just "prep the environment".

This all depends how much product are you expected to produce. Your "don't chop things beforehand" works if you're cooking for 1 or 2, but if you need to cook for 4+ you absolutely need to plan your steps and prepare your ingredients so that you merely combine them. This is evermore important if you want to have some sufficiently consistent level of quality, which I suppose is implied.

I cook for four (my family) and always just pipeline everything. Sometimes I make up to 4 dishes at once. This feels a lot faster to me. So at least for that number I don’t agree.

I really like going full mise en place when I cook. I go through the ingredients, and anything that can't be very easily measured on demand (not 1 tsp, for example, but I would do 1.5 cups), I measure out and chop into its own temporary container. Then when I move to the preparation, I've removed all the stress from the process.

I used to freak out about not making extra dishes, but who cares. I have a dishwasher. It take 20 seconds to throw 3-5 small bowls on the top rack.

And for these reasons Mise-en-scène may be a better metaphor for Software Development.

https://en.wikipedia.org/wiki/Mise-en-sc%C3%A8ne