Thomas Otter

I have been meaning to write up a book review on this for a while, so here goes. The publisher sent me a review copy of the Design of Design sometime ago.  Many of us have heard of Fred Brooks, the fellow who wrote the Mythical Man Month and was at heart of IBM System /360 development.

This is a book tinged with reminiscences. It discusses building a beach house, writing a book,  and the System /360. Brooks’ decades of experience seep through the book. It is a series of essays, but it hangs together as a whole rather well. It is part text book, part memoir. I reckon this would be a good audio book, read by the author. Brooks seems a remarkable fellow, he writes with an engaging modesty about his own accomplishment. He doesn’t preach or patronize. At times it rambles a bit, but that personalizes the book, rather than undermining and distracting from its key message.

At its heart, the book challenges engineers to think about design, and the process of design.

The book is laced with aphorisms, often surrounded by anecdote. Some examples.

The hardest part of design is deciding what to design. 

This followed up with a couple of paragraphs about a punchcard application that he kept adding features too.

A chief service of the designer is helping clients discover what they want designed.

The waterfall model is wrong and harmful; we must outgrow it.

His advice on teams and collaboration is spot on, again using an anecdote from his experience.

Have one user-interface designer.

No amount of collaboration eliminates the need for the “dreariness of labour and the loneliness of thought”

An articulated guess beats an unspoken assumption.

If a design, particularly a team design, is to have conceptual integrity, one should name the scare resource explicitly, track it publicly, control it firmly.

Constraints are friends. He goes on to define what are real constraints, versus obsolete, misperceived and artificial…

I’m not sure that I agree with his statement about being very leery about assigning graduate students with little real world design experience dissertation topics in the field of collaborative design tools.  You could apply this argument to almost any topic, and then you would have grad schools filled with ancient experienced types. 

The chapter on Telecollaboration is rather quaint in technological terms, but the advice is useful. He makes a telling point in the last paragraph of the chapter. There are too many books about collaboration tools and not enough on using the tools to accomplish a real task.

The book is also peppered with quotes from antiquity. I particularly like the quote from Vitruvius 22 BC, Firmitas, Ulilitas, Venusitas. Firmness, usefulness, delight.  Chapter 12 on Esthetics and Style is one of the more punchy chapters.

As I dealt with JCL in my youth, I thoroughly enjoyed his dissing of JCL. (chapter 14).  Permit me a nostaligic moment and diversion.

In 1992,  straight out of university, I worked as a consultant on a mainframe HR implementation. I wrote a really complex series of reports, basically to produce the contracts for 70,000 insurance brokers. When I tested the reports in the sandbox it was fine and I also ran it in the test system. I filled in a long form for permission to run it against the production system. The rule was that you had to sit with the sys admin guy on the first night the report ran, in case anything went wrong. You then had to be on call for a week…

After a couple of rewrites my JCL was approved by the JCL standards committee.  So, on the appointed evening, I got the special pass that allowed me to enter the data centre, and I sat down next to a long bearded Gent  who hadn’t seen daylight for sometime.  We ran the report, and after about 3 minutes, all hell broke loose.  The final report, instead of printing out contracts for the dozen new brokers, began to print out contracts for all 70.000. eeek, the lights dimmed in Cape Town as we sucked all the available energy up… We shut down the the report, and I thought I was in deep trouble. Actually what happened is that I had been told to set up the program to work with fixed block, and the production system used variable block (or the other way round) This meant that my report was reading field 4 digits out on the selection rule, and this messed up the whole report.

Despite layers of testing and change control, I still managed to break something that was supposed to be unbreakable.

Another hidden gem is on page 234 on working with Germans.. “the engineers had always scrupulously followed IBM’s official corporate product procedure..”  In fact, the whole of chapter 19 is a gem.

Chapter 20 provides good solid advice on hiring and developing designers. This could be a whole book.

The house building chapters didn’t really grab me, I found myself skipping over them. There are better books on house design. However, chapters 24-26 on the System /360 are a must read for those interested in the history of one of the most significant computers and operating systems.

The recommended reading is useful, but I would have liked to have seen some of the more recent work on design thinking referenced. However it reminded me to spend more time with Barry Boehm’s work-

This is not a how to do design textbook. It is not as slick and cool as an IDEO book. It talks honestly and practically about the importance of design in computer science. I will make you think, and note that design is not just for those in black T-shirts and New Balance shoes.

It is a book I will continue to dip into, and I now need to go back and re-read his other work.

Sadagopan has written a thoughtful review of the book here.

2 Comments »

Category: books     Tags: the design of design; book review

Share