Design of Design, The: Essays from a Computer Scientist

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.

Brooks is a distinguished person and listening to him often pays off. But don't expect to learn any specific technique from this book. There are lots of practical guides on the Internet. The book is a collection of wisdom, most of which, however, you have probably heard before.In the first few chapters the book stresses the point that design is iterative process, that it is not possible to get the design right from the very beginning. Then he mentions several cases of how the design of complex system was done in a wrong way. For example, designing a military chopper without consulting with pilots. Therefore, even during early design stage it is important that users be taken into consideration. And this is indeed why open-source systems are so successful - because they are driven by users of the product.Brooks mentions that previously the designers were actually the users of the product: think of Wright brothers, Ford who rode on the car that he designed, etc. But as the time goes by this happens to change: do you think that space rocket designers are same people as astronauts? Obviously no. And this is going to happen to the software as well, Brooks claims.As the library of software components gets bigger and bigger, the process of building software becomes more like that in assembly factory: take piece labeled S1 and S2, connect them together, wrap them into S3, etc. In such a scenario the designer might not even know how to program, and this is the good part. The drawback is that such software can have bad design.In further chapters of the book Brooks delves into philosophy - empiricism and rationalism. He mentions that abstract math was generated by French philosophers who were mostly into rationalism, whereas applied science was created by Brits who are into empiricism. Brooks claims that software engineering is totally empirical, that is, requires constant verification, and so is the design of software.Then Brooks sheds light on what are the characteristics of a good design, in his opinion. The major design principles are: orthogonality, propriety, and generality. But those are just general principles. When you design something, you have to make thousands of micro-decisions and the way you make them is called style. How to achieve good style? Brooks mentions the importance of copying other people's styles. Even great composers such as J. S. Bach spent considerable amount of time studying other people's works.So, design is a complicated iterative process. As always, documentation plays a very important role. So how can one document the design trajectories? For that tools are needed. Brooks cites a few tools available online, but I cannot say they are mainstream. On the other hand, he fails to mention Mind Maps, a recent tool which is hugely popular among engineers.To summarize, this book is a message from a successful engineer of previous generation of computer programmers. Can the youngsters learn something from this book? Definitely yes. On the other hand, the book will not fix the problems in existing products, but it can help prevent further mistakes.

This 2010 book clearly shows that there was almost no significant progress in the "science of design" internationally between 1990 and 2010 - which is kind of interesting but matches my understanding. It is a brief workmanlike review of design studies theory as of 2020.[I had a research fellowship for 5 years working in an aspect of design theory, and was a visiting prof at the CMU NSF Engineering Design Centre in 1990 as well as working with the EDC in my own department and visiting MIT and Stanford. So I think I had a pretty broad spread of understanding of the field.]This book includes case studies you won't find elsewhere on Brooks' house extensions, but these are pretty pallid stuff. I fear it is showing his age in that the disturbing and insightful author of the Mythical Man Month is not in evidence.One for absolute beginners in studying design process, otherwise something that any decent library should have but few people will read.

I specialise for one of the big 4 accountancy fimrs on programme and project management, working on large IT and regulatory change. Frederick P. Brooks' Mythical Man Month is the most important book I have read within my field (along with Code Complete, Rapid Development and Software Estimation - all by Steve McConnell, the Project Management Institute's PMBoK and Harold Kerzner's Project Management text book).Thus I was very much looking forward to this book. Sadly, it is not in the same league. The author's obvious talent does shine through, but not in a way that that a lesser mortal like me could derive tangible benefit from. IMHO, there are better books to be found on design (such as the Design of Everyday Things, by David Norman).

I wish I had read this earlier. It is an amazing book and as a software engineer you owe it to yourself to read this. To much these days people say "the code is the documentation", but the code doesn't include all the roads-not-taken, and often when someone new comes to a piece of software they end up reinventing all the mistakes of their predecessors because of this lack of communication. This book should be compulsory reading for anyone who is allowed to touch software in our society. And I am deadly serious.I'm off to read it again.

How top level technological thinking applied to computer design can and should affect aspects of everyday life, especially building projects. Very clearly written and illustrated, excellent read.

I found the book to be a relatively easy read. I may have missed some critical points.What interested me was the idea of deliberating training oneself to be a great designer. This is a new concept. I have just fallen into design. There has been no conscious decision to do design. And then to actively study design.Up to now, I have not designed any real database systems. I have designed small subsystems mainly to do with searching music titles, storing financial transactions for credit cards, etc. All really conceptually uninteresting, but very challenging in physical implementation. I was more of a carpenter rather than an architect.Once one has made the decision to become a designer, Brooks suggests that one seek out the best in the field and study their designs. This is extremely difficult to do in the database field because all database designs are hidden away. I know of no published database designs. There are books on database designs but these are recipe books not a diary of what was done and why.In studying design, Brooks says to concentrate on the constraints the designer worked under, and try to find out what was the conceptual vision they were working towards.From database designs I have seen to date, not all of the design is in the database. By this, I mean that the rules about object behaviour is sometimes encoded in the application itself not in the constrints explicated in the data dictionary. Some constraints may even be in user behaviour.