*
programming and human factors
by Jeff Atwood
*
From an audio interview with Ron Jeffries:
The reason the kitchen is a mess is not because the kitchen is poorly designed, it's because we didn't do the dishes after every meal.
Michael Feathers recently wrote an eerily similar entry about the professional chef's concept of working clean:
One other thing that I liked about the Pastry Chef's competition was the way that the chefs were judged. There was more to it than just the final judging. All during the preparation, judges walked from station to station with clipboards, making little notes. One of the criteria that they used was working clean. Imagine that.. working clean.. The judges were watching to make sure that the chefs rubbed clean every bowl and utensil immediately after use. If they didn't, well, they were marked off.
Micah Martin left a great comment that illustrates how integral "working clean" is to professionals in the restaurant industry:
In my college years I was a chef/line cook at a few restaurants. Indeed working clean is a common theme in the kitchen. The term I heard over and over was “Clean as you go!”. “Clean as you go!” wasn’t so much a suggestion, but rather a law. Those cooks who didn’t constantly clean would wind up in trouble. Their workspace would become so messy within a matter of an hour or two that the quality of food rapidly diminished. This problem would progress until the other cooks were forced to step in and clean up. This had a negative impact on the entire kitchen and Nobody was happy it happened. Interestingly, line cooks, even without college degrees, were extremely efficient as self-management. Those cook who didn’t work clean, were taunted, teased, and pushed around until they cleaned up, or quit.
For software developers, working clean means constant refactoring. If you don't stop occasionally-- frequently, actually-- to revisit and clean up the code you've already written, you're bound to end up with a big, sloppy ball of code. If you forget to regularly clean up behind yourself, things get smelly. Working clean means following your nose and addressing those nagging issues before they become catastrophic.
In addition to working clean, cooks also spend a lot of time thinking about mise en place, how their cooking stations are arranged for optimal work. Michael Feathers explains:
There's an section in [the book Kitchen Confidential] where he talks about what cooks do late at night after the customers have gone home. They generally do what many people after work, they go out for beers and sit around talking about work, but what do they talk about really? Tony says that the subject that always comes up is something called mise en place. Mise en place is a blanket term for how you set up your station.
Is your tub of butter at the eleven o'clock position or at the one o'clock? Do you have two paring knives, and do you keep them next to your cutting board or next to your garnish bin? When you spend the night churning out meals, these decisions make a difference. Everyone has their favorite theory about the proper miz. Tony says that many cooks get downright mystical about it. According Tony, you'd better run if you are caught messing with another cook's miz. Sharp knives have multiple uses, apparently.
The concept of mise en place should be familiar to software developers. It's why every member of the team has their development system set up identically. It's why we use a common set of development tools. It's why we take advantage of existing frameworks like nUnit and Log4Net instead of writing our own.
Good programmers should be borderline obsessive about their "miz". Our craft changes too rapidly for us to ever be completely satisifed with the way we're working today. There's always something better on the horizon.
Posted by Jeff Atwood View blog reactions
« Code Smells Are Recipes for Novices? »
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
Robert Cain on May 21, 2006 09:14 PMI 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 :)
Tim on May 21, 2006 11:33 PMAlso 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 ...
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 ...
Joe Grossberg on May 22, 2006 05:11 AMIt 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.
Kenneth on May 22, 2006 06:35 AMI 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.
matt on May 22, 2006 06:41 AMAgain, 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
Steve on May 22, 2006 10:07 AMWell 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. ;)
matt on May 22, 2006 10:21 AMSlight correction, it's probably "mise en place" (a setup, in French) instead of "mis en place".
trick on May 22, 2006 10:45 AMInteresting, 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..
Jeff Atwood on May 22, 2006 01:19 PM<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>
<p>The second one is the correct one in this context.</p>
Does anybody have any idea what dish is being made in that picture? It looks pretty good.
foobar on May 23, 2006 10:01 AMI think it's a brisket.
Jeff Atwood on May 23, 2006 11:28 AMI 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.
Marc on May 23, 2006 11:47 AMI 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 :)
foobar on May 24, 2006 08:59 AMThe "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).
Waterbreath on May 24, 2006 11:06 AMI 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...
Kyralessa on May 25, 2006 05:10 PMCooking Lessons for Designers:
http://www.adaptivepath.com/blog/wp-content/uploads/2007/07/ambidextrous_article.pdf
Jeff Atwood on September 4, 2007 03:08 PM| Content (c) 2008 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email