From an audio interview with Ron Jeffries:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/05/programmers-and-chefs.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/05/programmers-and-chefs.html
I like the concept of mis en place, and try like the dickens to implement correct refactorings when I can.
However, we’ve all been there. The doomsday project. Two weeks to write a six week project. You work long hours seven days a week to get it all done. Once a piece of code works, you go on and don’t look back.
Of course the boss promises you time for clean up afterward, but then there’s always some hot new project, and phase 2 never seems to roll around.
So how do you balance mis en place with the real world problem of tight deadlines?
Robert
I took the comments about mis en place differently, that it’s the same reason every developer has his/her own way of laying Visual Studio windows out on the screen, different font sizes/colours etc.
Regardless of wherther the font is black Courier New on white (butter at 11 O’Clock), or dark grey Lucida Console on light grey (butter at 1 O’Clock), anyone messing with a developers personal setup better be running far and fast when found out 
Interesting, according to the French to English online translator…
http://dictionary.reference.com/translate/text.html
“mis en place” == setup
“mise en place” == installation
Obviously far too subtle a difference for an online translator to be helpful…
p"mis en place" is the fact that something has been set up, “mise en place” is the act of setting it up or the setup./p
pThe second one is the correct one in this context./p
Yeah, I’m with Tim.
If I don’t have my .emacs copied to that particular server, it feels like working with one hand tied behind my back.
Great analogy, though. I’m an avid cook and avid developer, and feel there are some real similarities between the two. And don’t get me started on cooking Design Patterns …
It just goes to show how similar, logical practices apply to many different professions.
It also illustrates that we are all individuals who see things slightly different than the guy or gal next to us. We all process differently, react differently, and find different solutions to varying problems. It’s why there’s more than one car on the lot, more than one operating system, more than one programming language.
You can take the high road, you can take the low road, you can even make your own road, but in the end the goal is to get to the finish. It’s a wonderful thing, really.
I really like the idea of working clean but to me it means something a little different. It’s not so much about refactoring as it is about understanding and fixing issues right away.
I went to one of our satellite offices and sat in on a demo with one of the higher ups who is also a programmer. He was showing us the next version of a product he was working on. Every time he opened a new screen or tried something different another bug would rear its ugly head. These things were blatantly obvious and I got a really bad taste in my mouth from the whole experience. The guy kept going back and saying things like “I guess that’s why we call it Beta. I have that one on a list to be fixed.”. It made me sick. I would NEVER code like that. When I find a problem I fix it. Sure, I may write something down on a list and get to it in an hour. But this guy had clearly forgotten about these issues otherwise they wouldn’t still be there. I can’t imagine giving a demo of something that I actually knew was going to blow up in my face.
But that’s the way that many programmers work. They are all over the place and don’t keep the “task” clean. Because of this practice, they end up forgetting about bugs they have found and the whole program is a complete mess.
Also, keep in mind that I’m talking about development of new functionality and bugs that you introduce during that effort. I’m not talking about fixing someone else’s bugs after the fact. Those can’t always be fixed right away.
Again, back to the real world experience. It usually happens that bugs and messy code are often not as important as getting out 75 features in the time it takes to do 10. Sure I curse outlook everytime it crashes, but I understand that some psycho said it had to be done in 10 weeks instead of 100. I agree with the demoing part though, I’ve never demoed something before finding the “happy path”.
I started as a tester, and the simple fact is that I found A LOT more bugs than were ever adressed. Fixing that obscure bug from v1.0 is usually pushed down the list, so it’s just another entry in the bug database when you’re triaging v5.0.
Most management I’ve run into says that it’s not a bug until a customer discovers it. Depressing, but customer A won’t buy your product until it has feature Y and customers B-W never see that bug that bothers you every day. And lets not forget those deadly “Can’t reproduce” bugs. As if something bad only happening once is ok.
That’s not to say that an individual developer shouldn’t do their damndest to stay ahead of the curve. But that one time you manage to hack together that wicked feature in record time (as the entire known world will collapse if it’s not done by Apr 3) it’s usually hard to convince anyone you need time to make things right. I was intrigued by Jeremy Miller’s discussion about presenting code debt as an opportunity cost.
http://codebetter.com/blogs/jeremy.miller/archive/2005/10/31/134054.aspx
Well in the case of the demo it was more than just bugs. The guy was working an lots of different functionality at the same time and never had the chance of having a clean system that could be used as a demo. I just don’t work that way. Although I am very capable of multitasking I usually concentrate on the task at hand and get it to a workable state before moving on to something else. If nothing else, I make sure that I mark the code as incomplete and ensure that it doesn’t blow up if it is built or even executed. The guy doing the demo had started and never finished about 10 things, was aware of bugs in software that was still in development but weren’t fixed, and had forgetten which pieces of software worked and which didn’t. Now that’s what I call a “dirty kitchen”. But he’s not the only programmer I’ve ever seen who worked that way. And it’s certainly no wonder all of our customers are constantly complaining about the quality of that product.
And as I said before, fixing bugs in someone else’s code or in a production system is a completely different issue. I realize that it isn’t feasible to fix all bugs. I’m talking about bugs in your own code during development of new functionality. If you just got done programming a method to calcuate X and found a bug during unit testing, wouldn’t you just fix it? Or would you move on to something else knowing that the bug was still there? I personally would fix it before moving on. But then again, I’m known for delivering high quality code. 
Slight correction, it’s probably “mise en place” (a setup, in French) instead of “mis en place”.
Also reminds me of Kaizen (a href="http://en.wikipedia.org/wiki/Kaizen:"http://en.wikipedia.org/wiki/Kaizen:/a
continual improvement, using in manufacturing, particularly Toyota) which includes cleaning up the workspace: the "5S"s include seiri (tidiness) and seiso (orderliness) (a href="http://en.wikipedia.org/wiki/5S)."http://en.wikipedia.org/wiki/5S)./a In offices, this includes throwing away paper that’s not used, storing paper that is used neatly and systematically, etc …
Does anybody have any idea what dish is being made in that picture? It looks pretty good.
I think it’s a brisket.
I agree that there are parallels to softare but not sure it’s refactoring. Refactoring would be like making a dish, then figuring out how to make it faster, with less fat, etc. and the same taste. “Clean as you go” is more about keeping your bug count down, unit tests passing, etc. because you’ll never catch up if you don’t.
I know it’s a brisket (or a flank steak) :). I’m wondering what the actual recipe is. Come on Jeff, don’t leave me hanging like a piece of meat
The “place” portion of the expression is simple. It means “place” in English. Same letters, same meaning, different pronunciation.
Mis and mise derive from the one word. They are both conjugations of the verb “mettre”, meaning “to put” or “to set”.
“Mis” is simply the past participle of “mettre”. So “mis en place” means literally “set into place”. Or more simply, “setup”. English is actually a little more confusing here, as the conjuations for “put” and “set” in the past and the imperative are identical.
“Mise”, is literally almost the exact same thing. It is the past participle of “mettre”, but the feminine version. One might use it if the thing one were “setting” were feminine in the French language, such as a table. However, it has come to take on another meaning French, particularly as a noun referring to “the setting of something”. Hence “la mise en place de X” means “the setting in place of X”, more conveniently rendered in English as “the installation of X”.
While in English “setup” and “installation” are only marginally different in literal meaning, they do have different social connotations. The word “installation” (“mise en place”) has connotations with things technical, general, and impersonal. The word “setup” (“mis en place”) brings to mind things like customization and personalization.
So I would argue that for those of us who consider code to be, like cuisine, an art form, “mis en place” is probably the more appropriate term.
Though it really only matters in print, as both expressions are pronounced exactly the same in French: “meez-ahn-plahs” (approximately… the “n” is actually just hinted at, not spoken, and the “ah” has a very nasal quality).
I find the analogy extremely fitting. It reminds me of why we always wash the ice cream scoop right after we use it: because then the ice cream pretty much comes right off. But let that sucker dry for a few hours, and then try washing the ice cream off…
It’s the same way with coding; if you keep the code clean from the outset, and refactor as you go along, the refactoring really doesn’t take much more effort than you’d’ve expended anyway. But hack out a whole bunch of ugly code as fast as you can for weeks, and then try to refactor…
Cooking Lessons for Designers:
http://www.adaptivepath.com/blog/wp-content/uploads/2007/07/ambidextrous_article.pdf