Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Mise En Place

buttondown.email

Post reply on HN
Print view View original

41–50 of 85 posts

Re: Software Mise En Place

#41

Post by douglee650 »

kaapipo wrote: post #6
elcapitan wrote: post #3

> You don’t start prepping one vegetable while another is already cooking. I actually do that all the time - different ingredients have different densities and different cooking times, so it makes total sense to start cooking the harder ones while cutting the softer ones (e.g. when making a Minestrone soup). Or you want an onion/garlic/tomato base to break down before inserting other ingredients that should only cook…

This so much. If I'm cooking at the end of a long workday, in my 2 m² kitchen, I won't give a fuck about mise en place

excellence is a habit; mise en place for at home utilitarian cooking is an approach, not a workflow

Re: Software Mise En Place

#42

Post by douglee650 »

karmeliet wrote: post #14

Mise en place is a useful mental model for everyday activities, but I don't think the author gave a good example in the post. I don't think intensity or difficulty is the key differentiator between preparation and the actual work. To me, it's mainly about separating tedious and repetitive tasks from the ones that require attention and creativity. Prep work means that you perform something that you have done many-many…

I mean, author also claims to "know more about my city’s best grocery stores than its best restaurants" … so there's that

Re: Software Mise En Place

#43

Post by gryn »

thanatos519 wrote: post #29

Is there a French term for "clean as you go" which is IMHO also an essential part of cooking (and baking)? I like to have the kitchen already clean by the time the food is ready. "Clean as you go" is apparently much harder with software. :)

- "au fur et à mesure"

- graduellement

- progressivement

- petit à petit

--------

side note: for some reason I find the use french words, terms, and expressions in English (and there are a lot, in a strict technical sense almost every french word is a valid English word) somewhat annoying because they usually diverge with time in ways that are important enough to change meaning but not enough for the sense to be inferred just from local context alone. given how prevalent anglicisms are in french this make for more confusing and verbose conversations.

--------

Ex: "mise en place" just mean setup, so image two french software engineers talking about software "setup", one that has in his mind the meaning/philosophy meant here and the other using the more generic meaning.

Re: Software Mise En Place

#44

Post by seanwilson »

> Just one problem with this: I’ve never used GitHub actions before. So I had to figure that out, along with setting up proper S3 credentials and getting my site to build. ...

> What does mise in place tell me? Separate the tasks. Find a way to prep just the action file, then just the credentials, then the idiosyncrasies of my projects. After that I can integrate the pipeline with the documentation proper.

The problem I find is that unless you've done something very similar before (and recently, because services and APIs are always in flux), what can happen is you complete a few tasks, then on a later task you find some gotcha that means your original approach isn't going to work, so you come up with a workaround which requires you to redo/change the earlier tasks. Development whack-a-mole.

So what I tend to do is take the riskiest task first, do just enough to convince myself it can be finished, then move on to the next task etc. and then iterate back around filling in the gaps until I'm done.

By the way, I recently did some GitHub Action automation and it was super frustrating. There's no official way to run/test this locally (there's https://github.com/nektos/act which doesn't replicate a lot of features) so you end up editing-saving-pushing-waiting-diagnosing (e.g. even just for basic syntax errors) in this painfully slow feedback loop until it eventually works and hope it doesn't break later. I'd rather just stick to the simplest single script I can come up with than use GitHub Action features because of this.

Re: Software Mise En Place

#45

Post by sparcpile »

langsoul-com wrote: post #18

Isn't this just waterfall? Prep the shit outa everything requirement and design wise, then make it in sequential fashion?

The author re-worded iterative development where you start with a skeleton and slowly build out. Their example was to build out a simple build pipeline with stub projects that are replaced over time.

The Practice of Programming(Kernighan and Pike 1999) https://www.cs.princeton.edu/~bwk/tpop.webpage/ goes into much better details of the iterative development that is actually being done by the author. If you know the overall design of your program, you build out the skeleton with everything stubbed out. As you iterate through development, those stubs are fleshed out into fully working components.

The analogy of mise-in-enplace works if you have a ready for reusable components (COTS, FOSS, or personal) that you quickly pull off the shelf and combine into the larger product. Mise means having everything ready to go; you have your set of reusable components and subsystems that you can quickly pull together to make a new product.

Re: Software Mise En Place

#46

Post by vinceguidry »

seanwilson wrote: post #44

> Just one problem with this: I’ve never used GitHub actions before. So I had to figure that out, along with setting up proper S3 credentials and getting my site to build. ... > What does mise in place tell me? Separate the tasks. Find a way to prep just the action file, then just the credentials, then the idiosyncrasies of my projects. After that I can integrate the pipeline with the documentation proper. The proble…

I didn't think there could be anything worse than Harness. Then I got asked to build and maintain GitHub Actions CI pipelines.

Never again.

Re: Software Mise En Place

#47

Post by chrisdbanks »

adhesive_wombat wrote: post #27
chrisdbanks wrote: post #15

For me, "Mise en place", has nothing to do with chopping everything beforehand and in fact that is completely different from how I cook and develop software. Chopping everything at the start seems like it takes longer. 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 (o…

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 wh…

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.

Re: Software Mise En Place

#48

Post by seanwilson »

vinceguidry wrote: post #46
seanwilson wrote: post #44

> Just one problem with this: I’ve never used GitHub actions before. So I had to figure that out, along with setting up proper S3 credentials and getting my site to build. ... > What does mise in place tell me? Separate the tasks. Find a way to prep just the action file, then just the credentials, then the idiosyncrasies of my projects. After that I can integrate the pipeline with the documentation proper. The proble…

I didn't think there could be anything worse than Harness. Then I got asked to build and maintain GitHub Actions CI pipelines. Never again.

I'm sure I got a GitHub Action syntax error for writing 'main' instead "main" for a conditional check that the local "act" tool didn't pick up, the development feedback loop was infuriating...

How are people able to piece together such complex GitHub Actions? Does GitHub have to deal with this internally as well or they just haven't gotten around to releasing dev tools yet?

Re: Software Mise En Place

#49

Post by adhesive_wombat »

chrisdbanks wrote: post #47
adhesive_wombat wrote: post #27

Earlier quoted context omitted.

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 wh…

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…

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.

Re: Software Mise En Place

#50

Post by simulate-me »

stavros wrote: post #37
willis936 wrote: post #35

Earlier quoted context omitted.

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.
Post reply on HN