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.
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.
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.
"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."
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.
"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".
"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.
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'll have to check this book out!
Another good software example is having slack. If you're always busy, you may not be working on the right 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".
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.
I think Mise en place can mean different things to different people. The way I was taught it was to have everything "in place" before you start. Literally you gather all the ingredients in one place (on a metal tray) before you start cooking. This has three main benefits: 1) you make sure you have everything you need; 2) you don't forget to add anything as you go because at the end your tray should be empty; 3) you don't mess up timings by searching for something while you're cooking that you can't find; Thus I use Mise en place, but I don't chop everything at the start. I chop the onion and then start cooking it, and then chop the other ingredients. Chopping everything else upfront would make the process slower.
Similarly in software development I often save simple tasks for when I need mental relief from a hard task. Working on a simple task can often give you the space you need for your brain to solve the hard task it's working on in the background.
Doing all the simple tasks up front does not seem to me like a good approach to cooking or software development, but making sure you know what all the ingredients are and have them all ready, does.