Agile India.

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.

In the Second Edition of the eXtreme Programming Explained, Kent Beck writes:

“Software development has been steered wrong by the word ‘requirement’ defined in the dictionary as something mandatory or obligatory. The word carries a connotation of absolutism and permanence - inhibitors to embracing change. And, the word ‘requirement’ is just plain wrong.”

On his blog, Jeff Patton tries to explain why using the word requirement is plain wrong:

• When faced with challenges or in pursuit of a goal we decide on a course of action
• The software we eventually build is the compounding of a great number of decisions
• “Requirement” is a label we put on our decisions
• Decisions and requirements build on each other
• Giving requirements stops collaboration
• Asking for requirements avoids responsibility
• Requirements come from outside, not inside
• Stop using that word and start collaborating to solve problems

There are great points. In addition I feel:

Typically requirements for given business problem is derived based on some hypothesis. In today’s dynamic world, where Change is the only constant, those hypothesis can change. So instead of holding on to the by-product of the hypothesis, why not focus on the real business problem that we are trying to solve.

Requirements belongs to the solution domain. Since, there are multiple ways to solve any problem. Prematurely deciding on any one solution does not seem like a good idea. We need to spend time in the problem domain to actually come up with the closest solution.

The word requirements comes from a Target driven planning approach. Target Driven Planning has huge drawbacks that Agile methods try to avoid. Instead they focus on value driven planning.

When ever I hear about Business Analysis capturing the requirements, it reminds me of waiters in a restaurant. In most restaurant, you have a menu to select from, a waiter who will take your order (requirement) and pass it on to the chef (developers). I don’t mean to look down upon Business Analysts or Waiters.

What I’m trying to highlight is, in my experience, the BAs I’ve worked with, pretty much capture what the customer wants in form of requirements. But there is no rationale behind what is the real problem that we are trying to solve. Even if that is understand by the BA, its not communicated to everyone on the team. Do we even need some software for it? Critical questions seems to be missed out.

Also going back to the analogy, I think the analogy is flawed. In software, customers don’t get a menu. Even if they get a menu its in a language they don’t understand and to make matters worst the restaurant is serving a cuisine that the customers have no clue about. How can one possible order stuff without actually having a conversion around what kind of an appetite they have, whether they are in a hurry or not, if they like spicy food or not and so on.