Customer Reviews

The Design of Design: Essays from a Computer Scientist

5 star:		(10)
4 star:		(8)
3 star:		(3)
2 star:		(0)
1 star:		(2)

 

 

Brook's new book is a worthy successor to the classic Mythical Man-Month. It starts by discussion of the well known waterfall model of design and why this model remains seductive to this day. It then shows its flaws, pragmatic problems with design in the real world and alternative models. Many readers may be familiar with these issues (as I was ) but Brooks digs into a lot of history that you may not know about.

The next sections talk about design as a collaborative process , different perspectives for thinking about design, visions for designing houses, the role of individual design talent (process can't replace greatness!), and how great designers can be nurtured. This part of the book is superb.

The last section is a series of case studies including buildings, a System/360 (naturally), computer architecture, and the design of a joint research facility. This is the one area where the book could have been improved and the reason I did not give it 5 stars. Understandably, Brooks draws on his own experience in picking cases studies but I personally would have liked a bunch of cases studies of application software. I imagine most designers who read this book will be software developers and few will be involved in OS design or design of physical structures. Brooks would argue that there are universal ideas that really make design transcend particular design domains, and in that sense the cases studies he provides are certainly useful. However, it is always easier to learn form a case study that is close to what you actually do yourself.

Overall, Brook's writing style is excellent, entertaining and thoroughly researched so you will not be disappointed.

In 1989 I started a new kind of software company, and considering that I had no financial, business, nor management experience, things went fairly well. Indeed, we doubled revenue every year for the first five years and grew from 3 people to more than 60. Somewhere along the line we hit our first real management crisis, and I was given the assignment to read The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) as a first step in understanding why our scheduling and deliverables process had become so protracted and precarious.

It was an eye opener, and it gave me my first real understanding of the fundamental limits of the industrial model. (Michael Pollan's The Omnivore's Dilemma: A Natural History of Four Meals was the second, and perhaps even more profound.) Thus, when I discovered that Brooks had written a new book to treat one of my favorite new topics--Design--I decided to order it right away. Then, while it was sitting in my shopping cart, I read through some of the comments, and though several of them spread doubt about the quality or validity of this latest effort, I decided that I would risk the purchase. And I am glad I did.

I recently gave a four star review to another book on the topic of design: Roger Martin's latest book The Design of Business: Why Design Thinking is the Next Competitive Advantage. I felt bad about doing so because there is so much to like about that book and so much I appreciate about Martin's teachings. But the book did not strike me as one the best possible treatment of the subject, so I gave it only four stars. By that measure, I'm giving The Design of Design: Essays from a Computer Scientist a full five-star rating because I believe he has met that criteria. His writing is economical, elegant, accessible, and authoritative. His stance is earnest and authentic. His examples are relevant and essential. And his topic is absolutely vital to the proper construction of our 21st century economy.

This is a book I will have to buy in bulk, and to give to the many people I meet in my daily work who need the conceptual reboot that it provides. I recommend it to anyone who needs or produces creative work in these early days of the 21st century, whether in the public, private, or academic sectors.

There are few people who can be described as part of the foundation of modern business computing technology and IT management. Fred Brooks is one of them. His book "The Mythical Man Month" (MMM) is one of the seminal works on IT management. Now he follows that book up with "The Design of Design." Like MMM this book is a collection of essays and thoughts from someone who has been thinking and working on the deep systems behind information technology. This book is thought provoking, informative and makes a contribution to our understanding of IT and the nature of design.

A word of caution however, this book, like MMM is not for the casual reader. People who are looking for a book similar to the other `sliver bullet' books about tech will be sorely disappointed because there is no silver bullet. Brooks told us that in the MMM. However, serious students of the evolution of design and IT management however will find much in this book to debate, disagree and discussion.

Overall the 20 essays and 7 case studies provide an in-depth view on Brook's thinking and experience concerning design. Brook's approach tends toward a more academic treatment of these issues than other more solution oriented books. A strength of these essays is their ability to go back to the founding ideas and principles based on Brook's study or often first hand knowledge of the pioneers in IT.

Two disclosures here. First I wrote my dissertation about the design of enterprises, so I am very interested in the topic and found the book enjoyable. Second, a while ago I was leading a class about IT for some MBA students and I added MMM to the reading list. Unfortunately it did not work, as the MBA students did not have a grounding or appreciation of the ideas in MMM. I am afraid the same can be said of the Design of Design as it provides a comprehensive and thoughtful look at a complex subject that may be too much for the casual reader or someone with casual interest.

The Design of Design is a fitting compliment to MMM and should be among the reading list of those people seriously looking at the fundamental processes and management of IT. This book is recommended for people who have the interest and passion to think through Brook's thoughts, ideas and advice.

I, as probably many others, was looking forward reading "the design of design." I had pre-ordered it as soon as I knew I could and read it soon after it arrived. Unfortunately, the book disappointed me somewhat. It is not that it doesn't have insights... it does! It is not that it is written badly... it isn't! It is that most of the insights and examples are similar or the same as the Mythical Man-Month. Next to that, Fred Brooks doesn't seem to have any newer experiences managing software projects than the OS360 project :( The book is still worth reading, but it definitively isn't as useful as the Mythical Man Month (which with every work of Fred Brooks will be compared).

The book contains six parts and is about 400 pages thick. The first part of the book called "Models of Designing" dives (again) in the Waterfall Model and explains that it doesn't work, cannot work, and has never ever worked. He compares the Waterfall model to the Rational Model of design (from Simon) which has been criticized as being overly simplistic. Brooks still spends about 50 pages diving in Waterfall model and concludes this with: "The waterfall model is wrong and harmful; we must outgrow it"

The second part is about collaboration and tele-collaboration. To me, this was the weakest part of the book. In this part, Brooks argues that a good design always comes from one designer and cannot be developed by a group or a team. This is contrary to my own experiences and also, according to his notes, contrary to some of the reviewers experiences. Yet he keeps stressing this point throughout his book. The subject of tele-collaboration was covered only minimally.

The third part is probably the best part of the book and names design perspectives. Each chapter is a separate essay about one aspect of design. I especially enjoyed chapter 13 where Brooks argues we'll need more examplars of good software developers we can build on. Good design is build on good examples, but in software development... good examples are rarely studied (even though they are nowadays frequently Open Sourced)

The fourth and most of the sixth part of the book were uninteresting to me. The fourth part discusses a design that Brooks made with his team to design a dream system for architects for designing houses. It was mainly a description of the design decisions he made. Chapter six consists of case studies. Most of these case studies are Brooks amateur (physical) architecture studies where he, in he free time, extended his house and build a beach house. The cases aren't strongly linked to the design perspectives and design model he described earlier and it made them rather uninteresting to me (a software developer first). Chapter six also has cases about the IBM 360 system and operating system. I was more interested in these chapters, especially from a historical perspective. (Brooks his beach house might be beautiful, it had no impact on the world other than Family Brooks' enjoyable life at the beach).

The fifth part is short and names Great Designers. It contains two chapter "Great Designs come from Great Designers" and "Where do Great Designers Come From?". I enjoyed these chapters as a reminder of the impact of people and talent on the result of a project. And the question, which is unfortunately not a common discussion, how to actually teach great design (which he then links back to the examplars).

Overall, I enjoyed reading The Design of Design, yet I expected more. I was particularly disappointed by the old-ness (and perhaps obsoleteness) of the examples. Nearly all examples came again from the IBM 360 project. As programming language examples with a good design, Brooks doesn't talk about Ruby or Haskell... no he mentions APL. There is no example about modern design (in software that is) or any suggestion that Fred Brooks has been involved in a software development project after the IBM 360 project. This did not make his writing less entertaining, nor his insights less insightful, yet... I had expected more. Oh, and the case studies about his amateur architecture projects could probably be skipped.

Anyways, as mentioned, I still enjoyed reading it. The writing was good and the lessons were still valid. I thought of rating it 3 or 4 stars and decided to still go with a 4 star rating. However, if you are unfamiliar with Fred Brooks work, I'd recommend to read "The Mythical Man Month" instead.

As a UI Designer in the video games industry, this book helped me draw many parallels between our relatively young field and it's more mature parent in traditional software design. In fact our industry's fast and sometimes turbulent rise to the top of the entertainment medium has been forgiving to many of the same mistakes discussed in this book that predecessor design disciplines have long addressed. Things like defining a budgeted resource, weighting design requirements, and the correct use and cataloguing of exemplars are all terms rarely used (from my limited experience) in the offices of a video game development studio.

Not to say there aren't people thinking of these and contributing to the growing academic field of game design. But many of the best video game development practices remain intuitive and undocumented. It is exciting at least, to see how much room for growth there is to grow in such areas. The distilled wisdom of the author's experience in computer hardware and software design, as well as the historical perspective provided in this book have proved invaluable for me. This book has really expanded my big-picture view of the "design" profession as more than just the sum of its parts.

The first chapters provide an illuminating and concise look at the meta-field of design (with a focus on computer hardware and software design) and the models historically developed to describe it. The later chapters on designing a beach house and additional were initially harder to relate to, however important as a personal touch to show the author's own struggles and growth at mastering a new design discipline and (more importantly) documenting his own process with an academic precision that ultimately made them worthwhile.

As some of you know, I rarely read business books, personally finding most of them collections of platitudinous clichés or the rehash of tired old war stories. However, there are exceptions and Frederick Brooks' The Design of Design: Essays from a Computer Scientist is one of them. Written from a lifetime of experience in large and small scale design projects (like the IBM System 360), Brooks has a lot of very sensible things for all of us to think about. Fortunately the book really is a collection of essays and does not have to be read cover to cover. The first section covers conceptual models of design process contrasting the rational sequence of requirements, design, validation, and implementation with reality. Reality wins. The second section sensibly talks about collaboration and telecollaboration but doesn't tell us much we don't already know. The third section titled design perspectives gets into details of understanding how good design processes work and how flawed design processes fail. Then there is a section of case studies in computer science and architecture that may or may not be very interesting although his uniform analysis method is interesting. A short section of Great Designers and Great Designs is well worth looking at and is followed by another set of case studies similar to the earlier set.
A sense of the tenor of the conversation with Brooks is his teaching that requirements are never and should never be frozen at the start of the project - in fact they always change and develop as the project continues if there is any meaningful communication between designers and some representatives of the user community. He strongly advocates early conceptual prototyping of more or less functional if crude prototypes to bring reality kicking and screaming into the design cycle. Brooks believes that bold design decisions taken early in a project are a hallmark of good outcomes. He ponders the inherent problem that most corporate design processes of toll gates and the like have negative intent and are primarily designed to create vetoes of bad projects not elevations of great projects. Brooks thinks this is not wrong in itself but must be recognized when confronting a really innovative project.
You may not agree with all of Brooks' points and may not be interested in all his stories but this is really written by someone who has walked the walk and is still able to talk about it. I really recommend it for everyone involved in the product development process.

The author of the Mythical Man-Month, the Father of the IBM 360 hardware and software, Brooks is a giant. He has put together a series of essays that give any designer serious insights into the process. Regardless of what you work in, architecture for homes or cathedrals,. OS for RIM, Linux modules, web pages or wooden picnic tables, there is something for everyone on these essays. From the book , "The author tracks the evolution of the design process, treats collaborative and distributed design, and illuminates what makes a truly great designer. He examines the nuts and bolts of design processes, including budget constraints of many kinds, aesthetics, design empiricism, and tools, and grounds this discussion in his own real-world examples--case studies ranging from home construction to IBM's Operating System/360. Throughout, Brooks reveals keys to success that every designer, design project manager, and design researcher should know.

He points out that you study history to find out what works and how in order to learn from others. His chapter Constraints are Friends is worth the price of the book. He is veru harsh on himself for the errors that occured on his watch. He also advocates that good design requires much more planning and research than people are giving it. If a company is always in a hurry to get to market, then it is not committed to good design. If you consider yourself a designer - you have read this book. If you love computers you will cherish this book.

I borrowed this book from a friend, and rushed through it quite quickly. Brooks has a quite good big picture of design. And this is a much more mature book than his book 28 years ago, which is a great book. But it is not very useful to me, since I have a much deeper view on this matter than him. :) So I think I can just start writing this review after briefly rushing through all the section titles plus some paragraphs (to clarify what he means with those titles). I will go back to read the book in more details if someone points out my mistakes. :P

As regard to his arguments on rational models vs. empirical ones (I was reading the Chinese version, by the way), I look at it this way: when you start a software projects, there are many things you don't know, and some things you know. So the software dev process is to explore the unknown with things you already know. So for example, the prototyping is a good tool to help you find out the unknown (for example, by involving the users in at the very early stage).

For me I summarize the process of software dev as principle of playing. [...]

Brooks mentioned beauty in this book. That is very right. It is very much about beauty. It is also about life. On this level, you can understand design very deeply.

This is a quite complete guide on design and offer you a complete view on what design is and how to be a good designer. But the author can still go deeper to a level that touches the principle of everything, which is about life (fun, beauty, and love). When he wrote about the constraints in design, you know life has constrains. This is the subject of constrains and freedom.

A little spoiler here. I like the chapter about partition. The partition caused a danger: the integrity of concept might be harmed. The partition started at mass production time, and it caused harms. The uniqueness of software makes it possible to do all things by one person. First it is because the barrier in software to do so in lower. Secondly software is a lot more complex and demands integrity of concept. So at least for software programming, the integrity of concept is very vital. Two people collaboration is a wonder.

I have just finished reading Fred Brooks's new book, _The Design of
Design_. I LOVED it.

I will be recommending that we adopt it as a text book in our
requirements engineering course. What this book calls design, we call
requirements engineering in the broadest sense.

As Brooks said on page 190, "Design Isn't Just to Satisfy
Requirements, but Also to Uncover Requirements".

Perhaps, it's not terribly important whether one labesl this activity
that helps uncover requirements as "design" or as "requirements
engineering". What IS important is that it be done AND that sufficient
time be allocated to do it right, as observed in several "Lessons
Learned" subsections in the book. If is for these lessons that I am
recommending this book.

"Better Wrong than Vague!" drives home the importance of having a
complete specification in which the fatal flaws can be found. It's too
easy to handwave people into accepting an incomplete specification with
the seductive "We'll work out the details when we start implementing".

I particularly enjoyed the chapters dealing with house and kitchen
remodeling. These drive home the point that even in non-computer based
systems, it's important to spend time getting the design or
requirements, however you call it, right.

I understand that many potential readers seem to think that the case
studies are wasted pages, ego trips, or both. However, to my mind they
are the most valuable parts of the book, because (1) anyone can
understand them, regardless of technical background and (2) there are
so few published case studies that give design rationale. Indeed, these
case studies are a major reason for my wanting to adopt the book for my
class. These case studies help make what would otherwise be
just-classroom-material relevant to real life and real-life systems.

One minor correction: The name of the author of "If you can't stand the
heat, get out of the kitchen." is Harry S Truman (without any period
after the "S". His name IS "Harry S Truman" and not something like
"Harold Samuel Truman", of which "Harry" is a nickname and "S." is an
abbreviation. Indeed, his enemies used to call him "Harry S-for-
nothing Truman". Since I was born in 1948, I don't have a personal
memory of this, but I remember my father teaching me this after we saw
a _Candid Camera_ episode in which ordinary people were exposed to the
real Harry Truman walking his dog down their streets, and someone said,
"There goes 'Harry S-for-nothing Truman'!", and Truman just laughed.

I thank Fred Brooks for writing the book.

(Note that I am a professor of Software Engineering at the Cheriton
School of Computer Science at the University of Waterloo, where I am
one of those who teaches the requirements engineering course. So,
I DO have some influence on the adoption of books :-) )

This was an excellent book. Dr. Brooks is a brilliant engineer and an engaging writer. This book contains great insights that everyone on a development should know. Dr. Brooks is a renaissance man who uses allusions to the arts as well as engineering to teach some universal principles of design.