The quest for one simple Analogy or metaphor to describe software and its development continues after several decades. I believe you need multiple analogies to define different aspects about software development. Also taking one analogy to extreme or reading between lines will cause more harm than good.

Following analogies try to explain Software Development (some right and some plain stupid)

• David Gries says writing software is a science (1981)
• Donald Knuth says it’s an art (1998)
• Watts Humphrey says it’s a process (1989)
• Kent Beck say it’s like driving a car (2000)
• Alistair Cockburn says it’s a game (2002) or like Rock Climbing
• Eric Raymond says it’s like a bazaar (2000)
• Andy Hunt and Dave Thomas say it’s like gardening
• Paul Heckel says it’s like filming Snow White and the Seven Dwarfs (1994)
• Fred Brooks says that it’s like farming, hunting werewolves or drowning with dinosaurs in a tar pit (1995)
• Steve McConnell says its like Construction: The whole notation of software architecture, blue prints and modeling comes from here.
• I believe Software Development is like Trekking/Hiking
• Driving on Indian Roads Reminds me of the way I do Software Development
• I also like the Cooking analogy.
• Some people say its like Craft/Martial Arts (more on learning aspects)
• Others say its like Book Writing/Composition/Poetry
• I like Stand up comedy analogy. Software development has an improvisational aspect
• Software as oyster farming. I’m really interested from the system accretion aspect. Accretion is closely related to “incremental”, “adaptive”, and “evolutionary”
• And then of course we have the manufacturing analogy. Lean Manufacturing is more meaningful than assembly line manufacturing. 
• I also like the Painting analogy. Demonstrates iterative and incremental thinking very well.

Why do some authors call their tutorials as Cook books?

Its a collection of guidelines (recipes) to use the software. Very similar to cookbooks or recipe books.

Cooking has been used a metaphor/analogy for software development for many decades now. Some people have even compared Developers to Chefs, [poor] Analysts to Waiters and so on.

I find a very close resemblance between the way I cook food and the way I build software.

• Both an very much an iterative and incremental process. Big bang approaches don’t work.
• Very heavy focus on feedback and testing (tasting, smelling, feeling the texture, etc) early on and continuously throughout. We don’t cook the whole meal and then check it. The whole cooking process if very feedback driven.
• Like Software, each meal has many edible food items (features) in it. Each food item has basic ingredients (that fills your stomach)[skeleton; must-have-part of the feature], ingredients that give the taste, color & meaning to the food and ingredients that decorates the food [esthetics]. We prioritize and thin slice to get early feedback and to take baby steps.
• Like in software, fresh ingredients [new feature ideas] are more healthy and sustainable.
• Cooking is an art. You get better at it by practicing it. There are no crash courses that can make you a master cook.
• Cooking has some fundamental underlying principles that can be applied to different styles of cooking and to different cuisines. Similarly in software we have different schools of thoughts and different frameworks/technologies where those fundamental principles can be applied.
• We have lots of recipe books for cooking. 2 different cooks can take the same recipe and come up with quite different food (taste, odor, color, texture, appeal, etc). A good cook (someone with quality experience) knows how to take a recipe and make wonderful food out of it. Other get caught up in the recipe. They miss the whole point of cooking and enjoying food.
• Efficiency can vary drastically between a good cook and a bad cook. A good cook can deliver tasty food up to 10 times faster than a lousy cook.
• Cooking needs passion and risk taking attitude. A passionate cook, willing to try something new, can get very creative with cooking. Can deliver great results with limited resources. Someone lacking the passion will not deliver any edible food, even if they are give all the resources in the world.
• Cooking has a creative, experimental side to it. Mixing different styles of cooking can leading to wonderful results.
• Cooking is a constant learning and exploratory process. This is what adds all the fun to cooking. Not cooking the same old stuff by reading the manual.
• In cooking, there are guidelines no rules. One with discipline and one who has internalized the guidelines can cook far better than the one stuck with the rules and processes.
• “Many cooks spoil the broth”. You can’t violate Mythical Man Month.

Also if we broaden the analogy to Restaurant business, we can see some other interesting aspects.

On the Protest project when I was building the “integration with Ant” feature, I adopted the same thin slice principle. Following are the thin slices I came up with:

• Create an Ant task which can call Protest, it simply returns the tests in the same order as given to it. (Essentially was a copy of the JUnit Ant task)
• Add support for a voter (happened to be Dependency Voter), so that we can actually prioritize the tests based on the dependency algorithm. At this point we went ahead and released this task
• Add support for multiple voters. By now we had created 3 different voters and we wanted to use all the voters
• Provide a way to specify weightage for each voter. Some voters should be able to influence the prioritized list of test more than the others
• Once we have a prioritized list of tests, provide a way to specify what top percentage of that list should be executed. This provides the user tighter control over how much feedback they need depending on the type of change they have just made
• And so on…

Now we could have sat and first designed how the Ant task should look and later wrote the task and then integrated with Protest. But the problem with this approach is:

• We won’t have anything functional and usable until we finish all the tasks. Too scary from a feedback standpoint
• We won’t be able to test anything for real until we finish all the tasks. There is a huge risk involved in this approach
• Essentially we are building an inventory with each of those tasks that are not used immediately. Turn around time for a feature is high
• It requires a lot of upfront thinking, which I’m not generally good at. At least we’ll have to think through all the input each voter would need and so on. Right now we don’t even have all the voters in place and this forces us to think about them now or introduces an unwanted dependency now.
• Lots of people argue that the evolutionary approach will be less efficient (more expensive and time consuming) because it gives an impression of thrashing and rework. In my experience, the big upfront design leads to more rework generally. It creates an illusion of streamlined process but in reality, it is actually lot more work and also leads to a rigid and over-engineered design
• We can also add all the disadvantages of big upfront design here

I hope this example demonstrates the technique of thin slicing and its advantages over its alternatives.

On the ProTest project, instead of using the Election metaphor, we had also considered using the ‘Google Search Engine’ Metaphor.

Each Test is like a web page on the internet with the content we are searching for. The ProTest Search Engine would go through all the test and give a TestRank (page rank) based on various relevance algorithms (strategies). Finally our search engine would do a rank aggregation and present the tests in a prioritized order.

If we went down the Google’s search engine metaphor, we would have ended up with a highly parallel/distributed test ranking algorithms. We would have also cached the tests and associated data.

As you can see, this design would be very different from what we have now by using the Election metaphor. System Metaphors are really powerful and helpful, if used well.