Being able to follow recipes is certainly a good foundation for mixing a decent drink.  Even experienced bartenders follow recipes, although they manage without the measuring cups and they have the recipes in their head.  Why is that?  A recipe is like a blueprint.  But unlike the blueprint for an air traffic control system, almost everybody can read the blueprint for a Martini.  Interestingly, not everybody can read a cooking recipe!  Just ask any freshman to sauté chopped onions, I rest my case.  

But why are recipes for cocktails relatively easy, and those for software so incredibly difficult?  For one, they are of a different nature!  A recipe is more like a system specification or a process description.  It is designed to be used over and over again for producing a desired, repeatable result.  The software is usually built exactly once, and then distributed many times.  Although in practice, the software is modified, fixed and extended, and having an accurate specification can make a big difference.

Recipes are easy, because we can assume common knowledge between the cook and the writer of the recipe.  When James Bond orders a Martini, the bartender understands what’s meant by shaken, and we know what stirring is.  On the other hand, every chef knows how to sauté, but not every teenager who is away from home for the first time does.  We can strive to make our technical specifications better by stating explicitly what skill set we expect the reader to have, and many technical books have a section describing their target audience – a good practice.

Specifications are easy if a good requirements document exists.  Many projects fail because of faulty requirements, as Tom DeMarco beautifully described in his novel "The Deadline", where the leading characters inspects the requirements for a air traffic control system, just to realize that they say nothing in a sophisticated way.  Contrast that with a recipe, where the requirements are simple: "Make me a Martini", "I need to drive, something without alcohol, please".  "Martini" describes what I want, but not how it’s prepared (although 007 begs to differ).  I leave the implementation details to the barkeeper, who decides what glass to use, the proportions of liquor and so forth.  Likewise, if we collect the requirements for a software, we shouldn’t describe the how ("use XML", "must be Oracle"), but the what ("allow secure communication over the Internet", "must allow ODBC access").

But the main reason why the bartender’s job is so much easier is that he doesn’t have to design the product on the spot.  He gets the requirements and simply picks an existing recipe that fits the bill.

Vincenti distinguishes between radical design and normal design.  Building a car today is normal design – we have done it many times before, the driver sits up front (there once were cars with the driver in the back), and so forth.  But in software we often do radical design, and success at best means building something that will function well enough to warrant further development.

Sadly, in software we are typically faced with radical design, no matter how much the vendors promise a world where solutions are assembled like Lego pieces.  So be prepared to put the required effort in for describing, specifying and building your software – it will be worth it.