Working Clean
I like to watch cooking shows on TV. I'm not the most adventurous eater, but I get a vicarious thrill out of watching people make things I would probably never try.
The other day I ended up watching a Pastry Chefs' Competition and it was mesmerizing. In these competitions, the chefs make huge sculptures out of melted sugar. They blow and twist the sugar like glass and dress it up with all sorts of decorations. Right before final judging they have to lift their delicate Rube Goldberg-esque sculptures off their work tables and carry them over to the judging table. Often they don't make it without a train wreck.. shattered sugar fins and gangly shapes everywhere. I haven't been reduced to hunting through the guide for Pastry Chefs' shows just to see the crashes, but it's tempting. I guess it is like watching auto racing, but knowing that no one will be hurt.
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.
I've never worked in a professional kitchen, but I can see where working clean would be very important. If you wipe down a knife right after you use it, it's there, poised and ready for whatever you need to use it for next.
There's a great book out called Kitchen Confidential out by a chef named Tony Bourdain. In it, he describes what he calls the culinary underbelly of the restaurant business. Some of it is kind of scary, but some of it is kind of interesting.. you get a sense of what it is really like to be a line cook in a restaurant, and surprise surprise, it's nothing like what you might see on Emeril.
There's an section in the book 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 mis en place. Mis 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.
I hate to draw comparisons between work in different professions, because often they miss, but I do think that we need these two concepts in software development: working clean and mis en place. Working clean, well there's a lot to say about that. We throw the term refactoring around a lot in the industry, but there's more to working clean than just refactoring. There's all of the micro work we do when we edit, and there's also the issue of what we do between editing sessions: what the code should look like over here before we stop and edit over there, for instance.
I think mis en place applies to us too, but not in a very straightforward way. If we wanted to form a direct analogy we'd say that our miz is our tools setup.. what our keyboard mappings are, what Eclipse plugins we use. But, I think that misses the point.. Cooks, well, the things they make go out the swinging doors; they seldom come back. In software development, most of our work happens in the context of code we've written before. To me, that means that our existing code is our mis en place and the way that it is structured really matters.
Personally, I think these things are part of the craft, and they are worthy of fevered discussion at the end of the day. I hope it happens on your team.
!commentForm
Wow! This blog entry takes me back. 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.
I like your comparison Michael. The software industry could learn a few things from line cooks.
“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.
I like your comparison Michael. The software industry could learn a few things from line cooks.
Great blog entry by the way.
Project taxonomy, and repository structure is another mis en place that is important, and could break a project if not done correctly. I also would like to point out the importance of cleanliness of your workspace. I am no clean freak by a mile, but when it gets really bad around my workspace, I notice the quality of code suffers.
Danno
Project taxonomy, and repository structure is another mis en place that is important, and could break a project if not done correctly. I also would like to point out the importance of cleanliness of your workspace. I am no clean freak by a mile, but when it gets really bad around my workspace, I notice the quality of code suffers.
Danno
It's a little weird; I read Kitchen Confidential just this weekend, and almost posted on the same topic.
One of the stories he told that really struck me was where one of the chefs he worked under would keep an eye on his cooks. If somebody's miz was getting sloppy and the guy was getting behind, the chef would come up, get their attention, and say something like, "A mess out hear means [tapping his forehead] a mess in here. Clean it up!"
I think that's very true for code, and one of the biggest benefits to merciless refactoring: by keeping the code clean, you have room in your head for the things that matter.
The thing that I wonder about is why our industry doesn't have that ethic.. we need it vitally, and sure some of the thoughts have been out there, but you definitely don't walk into the average team room and see and hear people act the way that Micah describes above. I guess the "why" doesn't matter, we just need to start doing it. - mcf
One of the stories he told that really struck me was where one of the chefs he worked under would keep an eye on his cooks. If somebody's miz was getting sloppy and the guy was getting behind, the chef would come up, get their attention, and say something like, "A mess out hear means [tapping his forehead] a mess in here. Clean it up!"
I think that's very true for code, and one of the biggest benefits to merciless refactoring: by keeping the code clean, you have room in your head for the things that matter.
The thing that I wonder about is why our industry doesn't have that ethic.. we need it vitally, and sure some of the thoughts have been out there, but you definitely don't walk into the average team room and see and hear people act the way that Micah describes above. I guess the "why" doesn't matter, we just need to start doing it. - mcf
I like the analogy. So cooks can accumulate "technical debt" too!
One of the things along these lines that I had my XP team do is we all set up our project directories identically on our PCs, and we installed all the tools with the exact same options turned on. The benefit it gave was that if one of us got a DLL corrupted, we could just copy it from one of the others rather than spend all day reinstalling "the universe". That problem did happen a few times and our strategy worked. Identical tool setups also made it easier for us to help each other. We were under huge time pressure, and so traded off the idea of individualizing our tool configurations for the ability to troubleshoot tool issues by comparison with each other's PC.
One of the things along these lines that I had my XP team do is we all set up our project directories identically on our PCs, and we installed all the tools with the exact same options turned on. The benefit it gave was that if one of us got a DLL corrupted, we could just copy it from one of the others rather than spend all day reinstalling "the universe". That problem did happen a few times and our strategy worked. Identical tool setups also made it easier for us to help each other. We were under huge time pressure, and so traded off the idea of individualizing our tool configurations for the ability to troubleshoot tool issues by comparison with each other's PC.
Great post!
I'm a very visual person so I've always done my best to make the visual layout of my code track the logic so that bug avoidance and fixing could be accomplished by visual pattern-matching. If the indented lines of code don't match up right, there's probably an error like a missing or misplaced bracket. If names don't line up, maybe I misspelled something. For example:
DataGet[?]
DataPut[?]
FileOpen[?]
FileClose[?]
(works better with a fixed-length font)
How we organize our tools as well as our code has a major effect on the correctness and reliability of our code.
I'm a very visual person so I've always done my best to make the visual layout of my code track the logic so that bug avoidance and fixing could be accomplished by visual pattern-matching. If the indented lines of code don't match up right, there's probably an error like a missing or misplaced bracket. If names don't line up, maybe I misspelled something. For example:
DataGet[?]
DataPut[?]
FileOpen[?]
FileClose[?]
(works better with a fixed-length font)
How we organize our tools as well as our code has a major effect on the correctness and reliability of our code.
Similarities to software development can be found in all kinds of crafts and professions. I think it would benefit the industry greatly to look at how other groups deal with similar issues. We tend to be too self reflective. One of my best friends was a cabinet maker. They made really high end custom furniture. I don't know anything about carpentry, but we could spend hours talking about issues at work. We were always amazed at how similar they were.
"I guess the 'why' doesn't matter, we just need to start doing it."
I think the "why" matters quite a bit. You can't fix a corrupt government by replacing the politicians. You have to fix the system so that it doesn't encourage corruption in the long term.
Sorry, what were we talking about again? Oh, yeah, coding! :)
I think the "why" matters quite a bit. You can't fix a corrupt government by replacing the politicians. You have to fix the system so that it doesn't encourage corruption in the long term.
Sorry, what were we talking about again? Oh, yeah, coding! :)
Add Child Page to WorkingClean