This is a nice idea and it’s interesting to see it invented and applied in another technical field (I consider cooking for large numbers to be an engineering task!).
I’ve tried to apply something similar to feature development too: the idea of thin vertical slices, integrated end-to-end (a la agile).
The common thread with this and the cooking and blog examples from the article is that they’re low risk. That is, you can work on a build pipeline, feature, or chopping vegetables for as long as you like: getting things wrong or not “just so” is fixed with rework.
As a counter example, I don’t think you could as easily apply it to something like incident response. Here you’re trying to do the most high impact and high pressure thing first: stem the bleeding/errors/outage.
Perhaps this suggests categories of task where mise en place is appropriate and others where it’s not. Though it’s not immediately clear to me whether even ostensibly unsuitable tasks may have suitable sub tasks within them.
> As a counter example, I don’t think you could as easily apply it to something like incident response. Here you’re trying to do the most high impact and high pressure thing first: stem the bleeding/errors/outage.
Yeah, that's not a case mise en place is helpful. Similar to how it's not helpful when you've burnt your food in the oven. If I had to apply mise in place to incident response, it would be in doing proactive prep in advance of high risk activities to reduce the chance of having to do reactive incident response.
I’ve done the same thing and it works very well (deploying Django to Heroku). I get the mise en place metaphor, but it seems a bit stretched. The benefits of mise en place seem to be reduced context switching and taking work (chopping vegetables) out of a more constrained time window (half the food is cooking) into a less constrained time window (before anyone shows up). That does apply here I think (readying for a new version).
The big thing with working this way is the incremental jumps between working versions. If you try to switch from local fire storage to S3 and your assets stop loading, you have the problem somewhat narrowed. If you stitch together four tutorials, hit deploy and your assets won’t load your problem is… somewhere? Certainly a bigger search space. I’m not sure this maps that well to mise en place. This more about something like tasting while you cook.
3 comments
[ 3.4 ms ] story [ 29.7 ms ] threadI’ve tried to apply something similar to feature development too: the idea of thin vertical slices, integrated end-to-end (a la agile).
The common thread with this and the cooking and blog examples from the article is that they’re low risk. That is, you can work on a build pipeline, feature, or chopping vegetables for as long as you like: getting things wrong or not “just so” is fixed with rework.
As a counter example, I don’t think you could as easily apply it to something like incident response. Here you’re trying to do the most high impact and high pressure thing first: stem the bleeding/errors/outage.
Perhaps this suggests categories of task where mise en place is appropriate and others where it’s not. Though it’s not immediately clear to me whether even ostensibly unsuitable tasks may have suitable sub tasks within them.
Yeah, that's not a case mise en place is helpful. Similar to how it's not helpful when you've burnt your food in the oven. If I had to apply mise in place to incident response, it would be in doing proactive prep in advance of high risk activities to reduce the chance of having to do reactive incident response.
The big thing with working this way is the incremental jumps between working versions. If you try to switch from local fire storage to S3 and your assets stop loading, you have the problem somewhat narrowed. If you stitch together four tutorials, hit deploy and your assets won’t load your problem is… somewhere? Certainly a bigger search space. I’m not sure this maps that well to mise en place. This more about something like tasting while you cook.