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.

So where am I going with this analogy?

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.

As programmers, we are often not involved until long after the requirements are fairly set in stone... So what can we do to counteract the "dream kitchen scenario"?

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.

By all means, build the best stove, refrigerator and sink that you can... but build them with the assembly line in mind and your customers will probably end up a lot more satisfied.