John Reynolds's Blog

Kitchens and Fast Food Factories

Recently I've begun thinking that a Kitchen vs. Fast Food Factory analogy might teach us a bit about writing better software...

I'm always looking for good analogies: A good analogy is worth 1000 pictures (and since a picture is worth 1000 words, analogies must be worth a million words).

Kitchens and Fast Food Factories (like MacDonald's) are places where meals are prepared. Both contain all of the tools and ingredients needed to prepare meals, and both provide the space necessary to prepare meals. They share a lot in common, but they are also fundamentally different.

Kitchens support the ad-hoc creation of meals. A well stocked Kitchen enables a chef to prepare almost any meal. The only limits are the skills of the chef and the available ingredients. The quality of the meal is very dependent on the skill of the chef.

Fast Food Factories support the structured creation of meals. Each Fast Food Factory is optimized to produce specific meals, quickly, and in great quantities. The quality of the meal prepared in a Fast Food Factory has little to do with the skill of the operators. Meal quality is controlled by the quality of the ingredients and the process by which they are assembled.

I haven't done any surveys, but I suspect that people who really like to cook would rather do so in a Kitchen than in a Fast Food Factory.

Software comes in all sizes, shapes and flavors (so to speak)... Some software is "Kitchen-ish" and some is "Fast Food Factory-ish". Think Microsoft Office vs. Turbo Tax. Ad-Hoc creation vs. guidance through a Structured Process.

When gathering requirements from potential users, be very wary of the "dream kitchen scenario". People will often describe "dream kitchens" rather than the "fast food factory" that their business really needs. They will describe software with powerful features that can be used in any combination. They will describe software that is flexible enough to be used for all of the scenarios that they have experienced. Metaphorically speaking, they will describe the kind of stove, refrigerator and sink that they want, and they'll probably be very explicit about what these appliances should look like (brushed stainless steel, of course). Lost in all of these details may be the fact that they only cook burgers, and if they don't cook burgers faster than the competition they will go out of business.

I'd suggest that, regardless of requirements, most of us can get a good idea of what role the software will play in the business. If the software is destined to play a major role in an important business process (as most software is), then architect your software (as much as possible) to function as components within a larger process (that is likely to change). Back to the Fast Food Factory... there are many specialized components, but the interfaces are designed for movement. Each component accepts output from a previous component, and passes results on to a later component. Components themselves may be black boxes, but the connections between the components are highly visible. Traffic between components can be monitored, and if necessary rerouted should a change in process be necessary.

Comments

• Except in the real world you aren't called upon to retool a McDonald's into a gourmet sushi restaurant in three days, a brunch emporium in two, and back to a gourmet sushi restaurant in another three days. You also don't have people in a fast food restaurant who swap out the stoves and ovens on a weekly basis because the brand names are neater looking or have more books written about them. :-)

  Posted by: ljnelson on January 15, 2007 at 09:26 AM

• Good analogy, although a good chef could still prepare food within the McDonald's context ... it is the combination of 3 things: chef, ingredients and preparation area (including not only appliances but distribution).

  I believe that analogies based on cars and/or buildings tend to be the best to engage non-technical people (custom cars vs generic, custom build platforms shared across brands vs bespoke, room distribution, the electricity-water-heating-design layers, for federated architectures you can use shopping malls). Cars and buildings are ubiquitious ... although everyone has a kitchen, not everyone cooks, and believe it or not, more (business) people seem to understand the difference between a ferrari and a ford than between a burger and stroganoff !

  Posted by: joshcruz on January 16, 2007 at 07:30 AM

• Josh,I think the problem with the "Ford vs. Ferrari" analogy is that there is no process involved. In general, software is used to build and process things. In a kitchen, you build and process things. In a car.... not so much.

  -JohnR

  Posted by: johnreynolds on January 16, 2007 at 08:35 AM

• I like the kitchen vs. fast food analogy. Thanks.

  Posted by: tompalmer on January 16, 2007 at 08:42 AM

• Fast Food life cycle is short , It not worth Fast Food Factory concept in Software.

  Posted by: devobject on January 16, 2007 at 11:17 AM

• "Fast Food life cycle is short "Perhaps, but the life cycle of a Fast Food Factory is not short. MacDonald's, for example, has been perfecting their factory since the 1950's. The continuos improvement of their factories is responsible in large part for their success... They have continuously tuned their processes to produce extremely consistent product at extrememly high volume.
  -JohnR

  Posted by: johnreynolds on January 16, 2007 at 11:23 AM

This work is licensed under a Creative Commons License.