Donald C. Gause & Gerald Weinberg
Dorset House, 1989
Donald C. Gause & Gerald Weinberg
Dorset House, 1989
ISBN: 0932633137
320 pages, boards.
Buy it from Amazon.com
Buy it from Amazon.co.uk
There are not very many technical books on specification from over a decade ago that people still keenly read, enjoy, and recommend to their colleagues, but this is such a one: Fred Brooks' The Mythical Man-Month is another. What does it take to write a book that survives amidst the frantic whirl of new technology? Good writing, certainly, but more than that, it takes a clear head to reflect on what is really happening, and then to look ahead to what ought to be done about it. It is even better if the book is not only visionary and sharp on the essential principles of a domain, but also delightfully funny and spicy. This book is.
Technocentric people like you and me tend to believe that everything significant has happened within the last few years. It is healthy now and again to read a book that makes it quite clear that there have been intelligent engineers in the world for many years. For instance, we have frequently quoted the Standish report on the cost of system problems and their causes. The authors quote Barry Boehm's Software Engineering Economics (1981), which reported that the cost ratio of fixing an error found in coding compared to one found in requirements to be 10 times as much, in acceptance testing 30 to 70 times, and in operation 40 to 1000 times. These figures were already classic stuff when Gause and Weinberg were writing. Wisdom seems to be something that develops slowly.
The book is full of quotable sayings that make important points. Here is a family story:
"In 1945, Jerry [Weinberg]'s dad, Harry, went into business with a line of wooden toys that had been user-tested on hundreds of children at Northwestern University. Unfortunately, the toys failed to sell well because in 1945 children were toy users, but not toy customers. The parents not only did the paying, they did the choosing. Assuming there was no difference between users and customers turned a design success into a business failure."
All the recent talk of 'stakeholders' has not said this more clearly. The story shows another feature of the book - the use of playfulness in the service of engineering understanding. This is explicitly acknowledged in the text: "How to attack ambiguity is the subject of the entire book. But above all, remember to use your mind in a playful way - exploration should be fun!"
Playful activities that bring definite benefits include making Tony Buzan's Mind Maps (little tree-diagrams annotated with the themes of meetings, talks, or books you are reading); brainstorming lists of possibly-desirable attributes; and playing with sentences to discover possibly ambiguities (a recurring theme of the book).
"Nursery rhymes are infamous examples of ambiguity, because some of them have been transmitted from child to child over hundreds of years, and the original meaning of the rhyme may have been lost, or transformed. For instance, 'pop goes the weasel' is not about an exploding animal, but about pawning one of a shoemaker's tools, the anvil… To 'pop' meant to pawn, hence the rhyme:
A penny for a spool of thread,
A penny for a needle,
That's the way the money goes,
Pop goes the weasel.
Now the puzzling rhyme makes more sense: the shoemaker has a cash flow problem because of rising expenses for small items, and so pawns his anvil to tide him over."
Terms shift their meanings, especially when these are technical (like weasel), and are readily misunderstood. The lesson, to define a project dictionary and to make sure the people who know - the users, not the requirements engineers - supply accurate definitions, is memorable. So is the page that follows, in which the authors comprehensively demolish 'Mary had a little lamb', showing that you can make it mean all sorts of things by emphasizing one or more words in turn. They conclude
"Although the nursery rhyme example may seem silly, we've used this heuristic for years in reviewing requirements documents, and it has often saved vast sums of money."
You can't argue with that.
The book is organized into five parts, each of about five chapters.
In other words, the book has great breadth of thought but a narrow remit - exploring requirements. The exploration goes much wider than you might have expected, as the subject is harder than it looks.
The book is richly and suggestively illustrated with diagrams and lithographs. It is beautifully indexed and has a proper bibliography, one that actually explains in a few sentences what each book on the list is like. If only more books had such helpful helps.
This is a classic book on requirements, full of good things to reflect on and enjoy. It may even improve the way you practice on your next project. Students and newcomers may also find Weinberg's gentle humour and wide vision an excellent lead in to the subject.
© Ian Alexander 2001-2
By the way, Weinberg maintains a lively website which is well worth a visit.
You may also like:
