Today's entry, provided by Jeff Moore, is entitled What We Can Learn about Software Development from a Failing Restaurant.
- Jeff Moore
- Jeff Moore is a columnist for php|architect who has been working with PHP for seven years and programming for two or three times that long, depending upon how you count.
- West Branch, Michigan
I like to cook. I especially like to cook for the holidays. Four or five times a year, I get to go hog wild and spend most of a day just cooking. (This Christmas, the menu is shaping up to be roast pork loin with cranberry apple sauce, roasted Brussels sprouts, scalloped potatoes, and a yam dish of some sort with maple syrup.) People sometimes tell me that I should cook professionally, but I'm really not that good at it. I just smile and say that I wouldn't want to ruin my enjoyment by making a job out of it. You see, I've never really worked in the food industry. There's not even a "do you want fries with that" in my past. I do have one guilty pleasure: a way to live vicariously in the restaurant trade.
You may have shared my indulgence. It's called reality TV. I like to watch shows that are not specifically about the preparation of food, but rather the restaurant business in general. I first got hooked on a show called The Restaurant. Then, I discovered Gordon Ramsay's Kitchen Nightmares, the British version followed by the American one. Don't forget the Canadian Restaurant Makeover. My TiVo doesn't. Drama and show business aside, I think there are things that we as programmers can learn from these shows. I'd like to focus on Gordon Ramsay's show.
The premise of each show is similar. There is a restaurant that is in trouble, and it needs to be fixed. Surprisingly, although each restaurant is different, each has problems that share similar patterns, and the same solutions are applied. (Watching these shows reminds me quite a bit of MBA case studies.)
The first segment of these shows is usually a review of the menu. Gordon Ramsay is a natural performer, with a face that was born to show disgust. He winces at strange flavor combinations, picks apart the dishes, and waves his hand up and down complicated menus lamenting the lack of focus.
This seems to be a common problem for restaurant owners. They don't want to leave any possibility unexploited. The menu expands to include any dish that anyone has ever asked for. The customers are overwhelmed by variety. The kitchen can't maintain quality across the array of choices. The restaurant is unremarkable because it does not excel at any one thing.
We can see this at work in the software industry. Have you ever worked on a bloated project? Have you worked on a project where no core feature stood out for its value, and where the feature list was all over the map? I have.
Many of these restaurant owners have a vision about the kind of restaurant they want to run. But, that vision doesn't always match what the customers in their community want. They open a fine dining restaurant in a working class neighborhood, or when they can barely cook without the help of prepackaged food and a microwave.
Sometimes, the restaurant staff has a hard time reconciling their vision with reality. The cognitive dissonance makes for good television. The chefs' assessment of their own food may not have any basis in reality. For the owners, hard times and failure breeds a conservative reluctance to change. They don't want to alienate that last meager customer base they have. Ramsay sometimes has to resort to extraordinary measures to realign the stake holders' conception of the restaurant, the menu, and themselves.
Ramsay uses a variety of techniques. If the chef produces foul tasting food, Ramsay blindfolds him and makes him taste it. If the chef thinks people like the lousy food, Ramsay takes the dish on the street and does taste comparisons. If the owner has no idea why his restaurant is empty, Ramsay goes out into the community and asks people why they don't go there. Anyone familiar with the principles of agile development should recognize the power of introducing feedback into the process.
This part of the show that interests me the most. The owner's vision has to be aligned with the community's needs. The menu has to be aligned with the staff's ability. Software projects require the same goal alignment.
Many of these establishments have suffered an overall decline in standards. Ramsay sets out to instill a pride in one's work among the staff. If the kitchen is messy, he makes them clean it. If there is bad or rotten food, he gets rid of it. If something isn't right, he makes them do it over again. Low standards beget lower standards. Along the same lines, I think sloppy code encourages more sloppy code. Ramsay says the food represents the cooks. Your code represents you. Take pride in your work.
Sometimes, the cook just wants to get the food done, and doesn't care what the customer thinks of it. In one episode, a chef drops a chicken wing on the floor and then tosses it in the fryer and intends to serves it. The grease cleans it, he claims! Have you witnessed the software equivalent of serving chicken wings off the floor? This attitude stems from a lack of empathy with the customer. Do you make fun of your users? Do you care what they think? Gordon Ramsay cares.
There are two versions of Ramsay's show. I prefer the British version, mostly because of the follow-up visit that shows whether the changes have stuck. The American version also includes an Oprah-inspired giveaway; the restaurant gets a new stove or new dishes. To me, this only confounds the social aspects of the show that I find so interesting.
Others have written about this show from a software development viewpoint. Watch the show yourself to see what you can get out of it.