Hot Best Seller

The Design of Design: Essays from a Computer Scientist

Availability: Ready to download

Making Sense of Design Effective design is at the heart of everything from software development to engineering to architecture. But what do we really know about the design process? What leads to effective, elegant designs? The Design of Design addresses these questions. These new essays by Fred Brooks contain extraordinary insights for designers in every discipline. Brooks pinpo Making Sense of Design Effective design is at the heart of everything from software development to engineering to architecture. But what do we really know about the design process? What leads to effective, elegant designs? The Design of Design addresses these questions. These new essays by Fred Brooks contain extraordinary insights for designers in every discipline. Brooks pinpoints constants inherent in all design projects and uncovers processes and patterns likely to lead to excellence. Drawing on conversations with dozens of exceptional designers, as well as his own experiences in several design domains, Brooks observes that bold design decisions lead to better outcomes. 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.


Compare

Making Sense of Design Effective design is at the heart of everything from software development to engineering to architecture. But what do we really know about the design process? What leads to effective, elegant designs? The Design of Design addresses these questions. These new essays by Fred Brooks contain extraordinary insights for designers in every discipline. Brooks pinpo Making Sense of Design Effective design is at the heart of everything from software development to engineering to architecture. But what do we really know about the design process? What leads to effective, elegant designs? The Design of Design addresses these questions. These new essays by Fred Brooks contain extraordinary insights for designers in every discipline. Brooks pinpoints constants inherent in all design projects and uncovers processes and patterns likely to lead to excellence. Drawing on conversations with dozens of exceptional designers, as well as his own experiences in several design domains, Brooks observes that bold design decisions lead to better outcomes. 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.

30 review for The Design of Design: Essays from a Computer Scientist

  1. 5 out of 5

    William Blair

    No words I might add to the still-growing tide of reviews of Dr. Brooks' latest book would ever convince anyone to buy and read it. You either already know who Frederick P. Brooks, Ph.D is, or you don't. The sad thing is, like his other popular book, The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition (TMMM), most who will comment on it will never have read it completely, cover-to-cover, and understood much, if anything, in it. In the online world we find ourselves in today, what No words I might add to the still-growing tide of reviews of Dr. Brooks' latest book would ever convince anyone to buy and read it. You either already know who Frederick P. Brooks, Ph.D is, or you don't. The sad thing is, like his other popular book, The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition (TMMM), most who will comment on it will never have read it completely, cover-to-cover, and understood much, if anything, in it. In the online world we find ourselves in today, what passes for research (never mind genuine, original research) sometimes only consists of finding some text (quoted elsewhere) using Google, and accepting it as fact. Hence, for example, the frequent misquotation (not to mention, the misrepresentation and misinterpretation) of "Brooks' Law." Sad to say, but this gem -- with an even larger load than TMMM of what in the broadcast world is termed "sound bites" -- will be equally misquoted. For computer programmers, there is much, but not as much, I think, as the horde seems to have expected. I have already encountered online grumbling that the book is not what they were told to expect. Brooks discloses (as well as can be expected) that the book is about design -- and the care and feeding of what he calls great designers. Only some of his examples are taken from software engineering, and I am afraid the rest are likely to be deemed "too boring" for the impatient, increasingly-web-oriented audience to slog through and thereby learn what Dr. Brooks has to teach. I think Dr. Brooks anticipated this (as he has many things) because he cautions the reader to treat the book as a series of related, but disconnected essays on the topic at hand. But I think most that would miss the point of many such essays would also ignore that advice to begin with (and then go on to complain). I recently recommended this book to a well-known blogger who (tongue-in-cheek) complained that he would have to add it to his "already-too-long reading list." I responded that he should move it to the top and that he would be glad he did. I also offered the suggestion to heed Dr. Brooks' advice that it is not necessary to read every chapter. Dr. Brooks even suggests some chapters that can be (initially) skipped. For many, the chapters on the design of the NC beach house and the remodeling and expansion of his Chapel Hill, NC home can be initially omitted. The case studies of System/360 and OS/360 are interesting, but I think they would be obscure to anyone who was not once a programmer on those (or the early System/370) systems. The bottom line is that you can skip almost half the pages, and not just initially. Brooks' prose is so engaging that I think most will go back and read the rest, anyway, but that's not necessary (nor even particularly valuable) the very first time. Like all of Brooks' written works, more and more value can be gleaned from rereading and reflective study. Except for the fact that it's been this way for 40 years, it would amaze me that, when I need to explain some things to those that are still wet behind their young programmers' ears, I can still find inspiration relevant to certain issues by reference to a book of his which is even older than The Mythical Man-Month. And so I told the blogger to move it to the top of his reading list – and then put it back in the middle of the stack. There is much here of interest, regarding both Dr. Brooks' personal and professional life and research, tidbits about the writing of TMMM and his equally great work, Computer Architecture: Concepts and Evolution (with Gerrit A. Blaauw), and his well-known Christian convictions (which do not intrude). Unlike TMMM, this is a good book to give to rising stars in any field of endeavor to encourage them to learn more about shining in their own field, how to go about it, and how to develop humility about their own talents and that of others on whom their efforts will necessarily depend.

  2. 5 out of 5

    David Workman

    This is quite an interesting book, delving in quite some depth into what makes a good design, a good designer, and asking (and answering) many important questions related to these topics. It stays quite process-agnostic, instead expounding the view that the important things are: - To have some form of design process - To have good designers - To give your designers the power to actually design - To ignore the formal design process as required to make a good design This is quite an interesting book, delving in quite some depth into what makes a good design, a good designer, and asking (and answering) many important questions related to these topics. It stays quite process-agnostic, instead expounding the view that the important things are: - To have some form of design process - To have good designers - To give your designers the power to actually design - To ignore the formal design process as required to make a good design The structure of the book will be familiar to anyone who has read Brooks' previous work 'The Mythical Man Month', with each chapter of the book actually being a stand-alone essay written by Brooks (or sometimes a guest contribution). This means there is little cross-linking between chapters, and also that sometimes chapters will repeat themselves in places to remain self-contained. This is a minor niggle though, and doesn't detract seriously from the book as a whole. There isn't really a 'narrative' over the entire book, so the book seems to lack a bit of cohesiveness from this, but the ordering of the essays is well chosen to provide a somewhat sensible linear ordering to the book. In a somewhat 'strange-loop-esque' (Godel-Escher-Back) self-reflective way, there is even a description of the process of 'flattening' a design graph into a hierarchical tree description that can be made into a linear ordering for a book, meaning this book of design talks about the design of a book in a limited fashion, which appeals to my sense of style. The book ends with several case-studies on several designs that Brooks has been involved in over the years. Two of these are construction projects (one a from-scratch, one an addition to an existing structure), one is the architecture of the 360 series computers that Brooks was in charge of designing at IBM, and so on. Each case-study is presented in a consistent and easily reviewed style, bringing out important decisions that were made in the design process, budgeted resources and so on. They provide a good summation of the ideas presented in the rest of the book in a more practical and useful context. They also provide exemplars that can be studied to give a budding (or experienced) designer some insight into the thought processes of a peer, which Brooks does cite as a key part of a designers education in several essays. Overall, I would say that this book is interesting and a good read, but it isn't as important a book as Brooks' previous work. Someone familiar with design will likely not pick up too much new information here as Brooks does mainly cover familiar ground. However, if you are new to the world of design, or looking for something to tie together disparate ideas in their understanding, this book is good as it provides a well-rounded, cohesive view of the subject and contains a lot of references to other works that can be used to further expand your knowledge.

  3. 5 out of 5

    Vladyslav

    Every time I start a new book it is excitement: imagination grasps everything from the reviews to the cover to draw new universe of thoughts. What one can expect from Frederick Brooks? Author of one of the classical books in software development The Mythical Man-Month: Essays on Software Engineering? I must say I expected more or rather I expected something else.. The book is over bloated and written in highly academical manner difficult to read. It is full of references to "The Mythical Man-Mo Every time I start a new book it is excitement: imagination grasps everything from the reviews to the cover to draw new universe of thoughts. What one can expect from Frederick Brooks? Author of one of the classical books in software development The Mythical Man-Month: Essays on Software Engineering? I must say I expected more or rather I expected something else.. The book is over bloated and written in highly academical manner difficult to read. It is full of references to "The Mythical Man-Month" in every chapter in almost every paragraph. Reader might get a feeling that it worth skip this one and go to "The Mythical Man-Month" directly. Around one third of the book is long going story about design and construction of the house at the beach for himself and his family. And a lot of thoughts how design the house is similar to designing software. With lists of decisions made, plans presented, sketches, opinions. I can not stand this metaphor. And because of that I do not see any point to trying to find any similarities. Many years ago it felt natural to think that building software is like building a house until I actually participated in commercial software development myself. I believe another metaphor purposed by Andrew Hunt and Dave Thomas in The Pragmatic Programmer: From Journeyman to Master reflects true nature of software development much better - programming is gardening. "With a garden, there's a constant assumption of maintenance. A garden is something that you're always interacting with to improve. We want people to view software as being far more organic, far more malleable, and something that you have to be prepared to interact with to improve all the time." Another part of the book covers the revelation of Mr. Brooks regarding waterfall model. Mr. Brooks claims that earlier he was complete ally to it but understood how wrong he was and there are references to scientific report regarding its inefficiency that helped him to change his mind. Can not comment much about that. The only thing I actually liked the most is the list of recommended reading because I found there the book I would strongly recommend myself Peopleware: Productive Projects and Teams But after all it is only my personal opinion and it is up to you to decide is this journey worth it or not.

  4. 5 out of 5

    Yevgeniy Brikman

    I was excited to read this, as I was hoping that studying the design process would help me become a better designer. Unfortunately, the book wasn't particularly insightful, and I don't think I took away any lessons that will impact my design process or abilities. In part, this is because the book tries to focus on all types of design—how to design a house, how to design software, how to design a computer, how to design a tool for designing, etc—rather than focusing on one discipline. As a result I was excited to read this, as I was hoping that studying the design process would help me become a better designer. Unfortunately, the book wasn't particularly insightful, and I don't think I took away any lessons that will impact my design process or abilities. In part, this is because the book tries to focus on all types of design—how to design a house, how to design software, how to design a computer, how to design a tool for designing, etc—rather than focusing on one discipline. As a result, it seems like a somewhat random collection of observations about various aspects of design, with a few interesting essays, and a lot of boring ones. The writing is stiff ("academic") and while I love the idea of the "case studies" at the end, those case studies solely show the _result_ of the design process, rather than the design process itself. In short, the book will get you to think about design as its own discipline, but it probably won't do much to make you a better designer. As always, I've saved a few of my favorite quotes from the book: "Sometimes the problem is to discover what the problem is." "The hardest part of design is deciding what to design." "A chief service of a designer is helping clients discover what they want designed." "In software engineering practice, another kind of harm can readily be spotted—the Rational Model, in any of its forms, leads us to demand up-front statements of design requirements. It leads us to believe that such can be formulated. It leads us to make contracts with one another on the basis of this enshrined ignorance." "A design flows from a chief designer, supported by a design team, not partitioned among one." "Is a computer program a mathematical object to be fashioned in abstraction and made correct by proof? So the rationalists would contend, led by Edsger Dijkstra. It is all a matter of proper careful thinking. One can, and should, design software to be correct and then prove the design is correct. And that will suffice. Now, granted, a program is a pure mathematical object and in principle can be designed perfectly by correct thought. The difficulty is not with the design medium but with designers. Empiricists believe that humans will inevitably make mistakes: in defining objectives, in software architecture, in implementation in objects (algorithms and data structures), and in realization in code itself. This firm faith in fallibility prescribes a design methodology that includes design, early prototypes, early user testing, iterative incremental implementation, testing on a rich bank of test cases, and regression testing after changes." "An articulated guess beats an unspoken assumption." "I believe that consistency underlies all principles of quality. A good architecture is consistent in the sense that, given a partial knowledge of the system, one can predict the remainder." "By its very nature, a product process “fights the last war,” encouraging tactics that have worked in the past and discouraging those that have failed. Hence for the product addressing a new war—a totally new need or mode of operating—both kinds of tactics may be irrelevant." "Consensus stifles great design in several ways. First, each expert watchdog is paid to avoid mistakes, not to make great things happen. So each is separately biased toward finding reasons not to proceed. Even when a really new product is not vetoed, consensus mechanisms often take off the sharp edges by forcing compromises. But the sharp edges are the cutting edges!" "Product design and release processes cannot turn good designers into great ones. They rarely produce great designs without a great designer. But the disciplines imposed can bring up the low end of the design curve and improve the average performance of the art. That’s nothing to sneeze at. The software engineering community has given much attention to its development processes. It has needed to, for I know of few design communities where average practice is so far behind best practice, and where worst practice is so far behind average practice."

  5. 4 out of 5

    Michael Scott

    I bumped into The Design of Design accidentally, while browsing the Kindle store for Peopleware and The Mythical Man-Month. I'm just glad I did: from the moment I picked up this book, I regretted every second I could not spend on it. In The Design of Design, Frederick P. Brooks Jr. starts from the premise that the process of designing anything---computers, software, houses, books, and organizations are the prime examples used in this book---follows very similar processes, when the outcome needs to be top-class. This boo I bumped into The Design of Design accidentally, while browsing the Kindle store for Peopleware and The Mythical Man-Month. I'm just glad I did: from the moment I picked up this book, I regretted every second I could not spend on it. In The Design of Design, Frederick P. Brooks Jr. starts from the premise that the process of designing anything---computers, software, houses, books, and organizations are the prime examples used in this book---follows very similar processes, when the outcome needs to be top-class. This book tries to decipher the structure and contents of a process that can lead to excellent design. The book includes 27 chapters in 6 parts. Brooks looks at models of design process (part I) and elements of design (part III), the growth of team design into remote design and tellecolaboration (part II), the relationship between great designs and great designers (part V), and seven use cases in design (part VI). There is also an incursion into architecting houses via advanced computer visualization and interfaces (part IV). Interspersed in this book are summaries of Brooks' wisdom, such as "A chief service of a designer is helping clients discover what they want designed"---this lack of initial understanding of the real objectives of a design is a major obstacle in the theory of systematic design exploration, which is much favored by engineers as a better alternative to purely creative processes. The writing is robust, often from the perspective of absolute truth, which helps with starting designers but may not be so much fun for experienced professionals. There are many technical elements in this book that may raise the attention of the wannabe designer. I found so many of the things I was looking for: notes on the design of a system architecture, notes on the design of an academic book, anecdotes and practical advice, an incursion into the history of design, useful literature references (up to 2010), etc. I also took notes, oh, so many notes (over 150 of them)! Among the "trivial" treatment of some subjects, I absolutely loved the anecdote about rigid procedure following, among the German IBM team (Chapter 19)---this approach turned a talented team with strong leadership into a production pipeline rather than a creative powerhouse. There is plenty more in this book. On the negative side, I was unable to relate to the architectural design. I found it very difficult to follow the process, perhaps because there are so many different aspects; space, the management of which I could easily follow, has to give room to considerations about materials, weather, etc. I enjoyed very much in the Chapters related to this topic, though, the discussion about patterns of house use. Overall, a brilliant book about design. Highly recommended for any computer scientist, and perhaps for anyone in the world of design.

  6. 5 out of 5

    Erika RS

    This is a book of essays from Fred Brooks, author of The Mythical Man-Month . A number of the essays are excellent. A couple were positively dull. The rest were in the middle. Brooks' aim in this book is to talk about the process of design in a way that is reasonably general. In that respect, I think he fails. I think if you're not designing computer systems, the essays on design will not provide a good overlap with the reader's experience. But if you are, you'll likely find much that is valuable. This is a book of essays from Fred Brooks, author of The Mythical Man-Month . A number of the essays are excellent. A couple were positively dull. The rest were in the middle. Brooks' aim in this book is to talk about the process of design in a way that is reasonably general. In that respect, I think he fails. I think if you're not designing computer systems, the essays on design will not provide a good overlap with the reader's experience. But if you are, you'll likely find much that is valuable. What I found most valuable about this book was revisiting ideas about design and collaboration from a perspective that isn't as heavy with the modern buzz words and paradigms. By shaking me out of my normal mindset, I was able to look at some topics in a different way. Part III: Design Perspectives, does the best job of this. I don't think this is likely to become as much of a classic as The Mythical Man-Month, but it's definitely food for thought if you care about the design of computer systems.

  7. 4 out of 5

    Dave Peticolas

    Another book on design, but this one emphasizes the actual practice of design and how to make it better. The first two-thirds or so is just excellent. Brooks's contention is that the best designs always come from either a single designer or (at most) two designers working very closely together. The reason is that the quality most important to a great design is conceptual integrity, an attribute that "design by committee" can never achieve. But design reviews are best done by multitudes, bringing Another book on design, but this one emphasizes the actual practice of design and how to make it better. The first two-thirds or so is just excellent. Brooks's contention is that the best designs always come from either a single designer or (at most) two designers working very closely together. The reason is that the quality most important to a great design is conceptual integrity, an attribute that "design by committee" can never achieve. But design reviews are best done by multitudes, bringing many different perspectives to bear. The last third of the book is a compendium of case studies. A few, like the design of IBM's S/360 mainframe computer, are interesting to a computer geek like myself for their historical value. But others, like the design of the Brooks family beach house, are quite frankly boring. But no matter, the good parts are well worth the price.

  8. 4 out of 5

    Ole Laursen

    Fred Brooks discusses the flaws of the waterfall model and the importance of all parties in a project that involves design (in a wide sense, including design of systems, of software, of houses) to learn about the problem domain and to use the knowledge gained to improve the design, incrementally. The book contains a lot of discussion and back and forth which is probably less interesting to many readers, although I personally enjoyed the glimpse into the world of a former IBM chief, bu Fred Brooks discusses the flaws of the waterfall model and the importance of all parties in a project that involves design (in a wide sense, including design of systems, of software, of houses) to learn about the problem domain and to use the knowledge gained to improve the design, incrementally. The book contains a lot of discussion and back and forth which is probably less interesting to many readers, although I personally enjoyed the glimpse into the world of a former IBM chief, but it also makes a couple of crystal-clear and well-articulated insights, for which the entire book is worth reading, just like The Mythical Man-Month.

  9. 5 out of 5

    Margaret Heller

    Thinking about how design works and models for design is important, even if the models are imperfect. Brooks describes the importance of models, flaws in the commonly used models, and some ways to think about better models and the types of practical problems that arise in design. I think given the structure it's harder to pick out a coherent argument, but there are some important ideas in here. I admit I totally skimmed all the case studies, since I didn't think they added all that much other th Thinking about how design works and models for design is important, even if the models are imperfect. Brooks describes the importance of models, flaws in the commonly used models, and some ways to think about better models and the types of practical problems that arise in design. I think given the structure it's harder to pick out a coherent argument, but there are some important ideas in here. I admit I totally skimmed all the case studies, since I didn't think they added all that much other than generally to see the practical considerations in epistemology of design,

  10. 4 out of 5

    Bharath

    This book provides excellent insight into the design process. Its amazing to discover how engineers posses a implicit view of the design process. Call engineers systematic thinkers or whatever, But that doesn't really help achieve a better design process. This book address the weaknesses of a rational model of design. Coherent and easily readable.

  11. 4 out of 5

    Ushan

    In 1961-1965, in his early 30s, Frederick Brooks was the project manager of the IBM System/360 and OS/360 project, one of the most successful engineering projects in history. Called "I.B.M.'s $5,000,000,000 gamble", this project succeeded enormously, and transformed not only the company and the industry, but the entire civilization: the computer architecture and it successors, and the operating system and its successors have been the de facto standard for mainframe computers ever since (of cours In 1961-1965, in his early 30s, Frederick Brooks was the project manager of the IBM System/360 and OS/360 project, one of the most successful engineering projects in history. Called "I.B.M.'s $5,000,000,000 gamble", this project succeeded enormously, and transformed not only the company and the industry, but the entire civilization: the computer architecture and it successors, and the operating system and its successors have been the de facto standard for mainframe computers ever since (of course, mainframe computers have been becoming ever less important in the world of computers, though they are still a multibillion-dollar business). Though Brooks has done other things later in life (working on interactive computer graphics, serving on the Defense Science Board, writing a textbook on computer architecture together with one of the architects of System/360, writing the famous book on software engineering The Mythical Man-Month), working on System/360 and OS/360 was the experience of his lifetime. He goes deeply into the design decisions made in these two projects. Having 8 bits instead of 6 bits in a byte, which allowed lowercase letters in software applications, was a terrific idea. JCL, on the other hand, was "the worst computer programming language ever" because its designers did not realize that they were creating a programming language (I would add templates in C++ as a much later example of an inadvertent programming language). A design goal was for the architecture to have 24 bits of address space, to be eventually extended to 32 bits; unfortunately, one instruction used the top 8 bits for its own purposes, which the architect overlooked, so when the architecture was extended to 31 bits (not 32 because of other design flaws) in System/370, programs compiled for System/360 had to run in a special compatibility mode. Emulation of earlier IBM computers was a great idea; adding decimal arithmetic for monetary values probably wasn't; applications or compilers should have stored the number of cents as an integer. Implementing OS/360 in assembly instead of PL/I made it less reliable, less clean, and slower to be delivered. Brooks gives more examples of good and bad design from his career, although System/360 and OS/360 are clearly where his passion lies. As a civilian expert on the Defense Science Board, he was invited to the review of the RAH-66 Comanche helicopter program, which was later canceled after a $6.9 billion investment. The colonel who briefed them said that one of the requirements for the helicopter was to be able to ferry itself across the Atlantic. Brooks asked, why it needed to do that: surely, this capability had to come at the expense of other capabilities more relevant to an attack helicopter. The colonel answered that this was because they did not have enough C-5 transport planes. Brooks asked, why they couldn't take some money from the helicopter program and use it to buy more planes. The colonel replied, "That's not possible," without explanation. There was no helicopter pilot or aircraft engineer on the committee formulating the requirements; just bureaucrats protecting their own turf. How could good design ever have emerged from that?

  12. 5 out of 5

    Tony

    Yes, it took me about a year and a half to read this. Parts of it can be dry. Parts of it are quite engaging. What is design? What needs to be designed? How does one go about this? For each of these questions, there is no one, single answer. And different answers may be better than others, depending on the context. I originally tumbled to this book while reading another one. It mentions the Comanche, a prototype scout/attack helicopter which I find quite interesting. The po Yes, it took me about a year and a half to read this. Parts of it can be dry. Parts of it are quite engaging. What is design? What needs to be designed? How does one go about this? For each of these questions, there is no one, single answer. And different answers may be better than others, depending on the context. I originally tumbled to this book while reading another one. It mentions the Comanche, a prototype scout/attack helicopter which I find quite interesting. The poor thing was doomed from the start. Dr Brooks was in one of the early meetings where the requirements for the chopper were laid out. It should be stealthy. It should be able to use/deploy these weapons. It should have this combat radius. It should have a tremendous "ferry range," enough that it could deploy overseas with the benefit of loading it into another aircraft or ship. These are mutually exclusive goals. The engines required to handle the weight were going to be pretty thirsty. The fuel required for that distance would mean having some extremely large fuel capacity. Which would add too much weight, even if the long-range tanks were removable. It simply wasn't do-able. And yet, the requirements had been developed by a committee, with different people bringing different goals to the table. Why did need that ferry range? Because the Army, which would be operating it, didn't want to have to turn to the Air Force or Navy to provide a means for deployment. Inter-service rivalry sank this bird before it made it off the drawing board. They needed a designer, sitting in on the meetings, who could keep them in line with reality. And that is the essence of design. What is easy to use? What is efficient in operation? What is useful? What is possible? A good designer sits at the intersection of these questions, with enough domain knowledge to answer them (or find answers) and help synthesize all the competing requirements into something which works and works well. The latter part of the books dives into case studies. I found these dry and boring; it took me over a year to slog through them. What's designed? A beach house. Additions to am existing house. A book. A computer. An operating system. A computer center and the associated governance/management of same. Each one talks about how principles of design were used, what worked, what didn't. If you want a frank discussion of how to do this, backed up with real-world examples of it, this book is for you.

  13. 5 out of 5

    John

    Interesting stuff! Brooks examines not of what makes designs good or bad, but instead various issues around how designers come up with designs - the process of design. He looks at the subject from several different perspectives, since he himself has designed computer hardware (architectures), software, houses (his own), and books. Along the way he looks at questions including how designers can be enabled to work creatively, what "style" is and how it fits into design, collaboration versus solo desi Interesting stuff! Brooks examines not of what makes designs good or bad, but instead various issues around how designers come up with designs - the process of design. He looks at the subject from several different perspectives, since he himself has designed computer hardware (architectures), software, houses (his own), and books. Along the way he looks at questions including how designers can be enabled to work creatively, what "style" is and how it fits into design, collaboration versus solo design, and more. The first 20 chapters are more closely connected than one might expect from a collection of essays; they definitely demand to be read serially, rather than standing alone. The next seven chapters are case studies in design, of various projects the author participated over a 40-year period, in the four areas mentioned above. Finally, there is a short chapter listing some recommended reading, including a number of seminal books and papers in the computing field. Unlike a traditional book in either computing or design theory, this is a very personal book. The author carefully states his conclusions as opinions, backed up his own experiences as well as by referenced literature. This is both good and bad; not all of Brooks's points seem well supported by evidence he provides; it's hard to tell in those cases whether his position is actually weak, or whether he's simply failed - intentionally or otherwise - to provide all the support he actually has for it. Regardless, Brooks is an unquestionably skilled and influential computer scientist, and anyone who is interested in the craft of computing should read this book. However, while there might be some points of interest for people in other fields, I'm not certain that it would be of as much value to, say, an architect or a graphic designer.

  14. 4 out of 5

    Sten Vesterli

    Interesting thoughts from one of the grand old men of the young field of Information Technology, Fred Brooks (of "Mythical Man-Month" fame). This book is in six parts of varying relevance. In part I, Brooks reflects on design methods, the problems with waterfall and how to improve it, and in part II, he discusses collaboration and distributed teams. These parts show the age of the book (it was written in 2010) and is of limited use in todays where we have agile and good tool support for virtual Interesting thoughts from one of the grand old men of the young field of Information Technology, Fred Brooks (of "Mythical Man-Month" fame). This book is in six parts of varying relevance. In part I, Brooks reflects on design methods, the problems with waterfall and how to improve it, and in part II, he discusses collaboration and distributed teams. These parts show the age of the book (it was written in 2010) and is of limited use in todays where we have agile and good tool support for virtual teams. Part III discusses the design process and is still relevant with interesting observations on how to determine the main design criteria (which Brooks calls the "Budgeted Resource") and how to build decision trees to make design designings explicit and visible. Part IV is about how Brooks would like building design software to work and can be skipped. Part V is about great designers and posits that you need one chief designer to ensure conceptual integrity. However, finding, growing and nurturing great designers, and making use of their gift in real-life software development remains an unsolved problem. In part VI, Brooks shares various designs he has been involved with, from his own beach house to the IBM System/360 he is famous for. There are a few interesting anecdotes, but they do not support the points of the book in any major way. If you are an IT professional, you should read this book to feed your mind with ideas that could improve your own practice in the field.

  15. 4 out of 5

    John

    This book is the natural antithesis to "The Science of the Artificial", as it demonstrates where design science really stands (and in what poor shape it is according to design practice). Turing-award winner Fred Brooks is a nice counterweight to the Turing (and Nobel) winning Herbert Simon, not a theoretical genius who revolutionized several fields but a practical project manager who assisted in making a corporation a lot of money. What this book is clearly leading up to is a synthesis, a decisi This book is the natural antithesis to "The Science of the Artificial", as it demonstrates where design science really stands (and in what poor shape it is according to design practice). Turing-award winner Fred Brooks is a nice counterweight to the Turing (and Nobel) winning Herbert Simon, not a theoretical genius who revolutionized several fields but a practical project manager who assisted in making a corporation a lot of money. What this book is clearly leading up to is a synthesis, a decision theoretic treatment that can handle how the information of a design is gathered, which is trying solutions and seeing what interacts to make it break down. The case studies of this volume are terrible, but terrible in a way that illustrates exactly what is being talked about: that there are elements in design but not a science in real design projects. The truth is that design isn't organized by the discovered elements, but by the discovery activities and when it is appropriate to take them so that they best make new findings from what was known before. The writing is clear, real, and informal as befits a book of essays. Never count being easy to read against content. Overall, for an engineer starting to work on their processes, this is a great place to begin.

  16. 5 out of 5

    Jay

    The most influential professional book I have ever read was Frederick Brooks' classic The Mythical Man-Month. That was a book primarily for software developers, managers, and particularly managers OF software developers. It was drawn largely from Brooks' experience managing the development of the ground-breaking IBM System/360 mainframe operating system in the early and mid-1960s. Now Brooks has articulated more of his professional and life experiences. In The Design of Design, he gives his views on h The most influential professional book I have ever read was Frederick Brooks' classic The Mythical Man-Month. That was a book primarily for software developers, managers, and particularly managers OF software developers. It was drawn largely from Brooks' experience managing the development of the ground-breaking IBM System/360 mainframe operating system in the early and mid-1960s. Now Brooks has articulated more of his professional and life experiences. In The Design of Design, he gives his views on how to design well, how to grow good designers, and even what good design actually is. His insights are thorough, well-reasoned, and typically well-worded in Brooks professorial but genial style. This book gave me new ways to think about what I do, how to keep my skills honed, and what I should be striving for when I undertake a new software design project. I know that lots of people over the last 50 years have had many of the same experiences as Brooks; but none that I know of can impart them to succeeding generations of software professionals as well as he does.

  17. 4 out of 5

    Muhammad Khan

    With all due respect to Mr. Brooks, this book is a failure, compared to his previous, now infamous "Mythical Man-Month" which was the only reason I bought "Design of Design" in the hope of being inspired. There is nothing new in this book, Brooks is trapped in his old world of reflections about his past encounters, writing in a style that is not fit for the modern-day audience, i.e. the younger generation. Whilst I cannot really fault the book for its facts and in depth reference material, With all due respect to Mr. Brooks, this book is a failure, compared to his previous, now infamous "Mythical Man-Month" which was the only reason I bought "Design of Design" in the hope of being inspired. There is nothing new in this book, Brooks is trapped in his old world of reflections about his past encounters, writing in a style that is not fit for the modern-day audience, i.e. the younger generation. Whilst I cannot really fault the book for its facts and in depth reference material, the material is bland, a tedious read - that I have stopped and probably wouldn't plan on reading till the end if I hadn't paid close to £20 for it! If truth be told, the material covered in this book is better suited as a series of blog posts, rather than a costly book... I will update my review if I learn something, feel inspired once I bring myself to complete this rather dry piece of work :-(

  18. 5 out of 5

    Mike Barretta

    Overall the book came across rather scattershot, but there were enough good gems and bibliographic references to add weight. Nominally, the book is about issues, problems, and solutions incumbent in the process of design. The later half of the book is a series of case studies of design work done by the author in various realms (home architecture, computer architecture, ogranizations, etc), and is mostly useful as a reference, I think. In other words, you can't read the case-studies as prose and Overall the book came across rather scattershot, but there were enough good gems and bibliographic references to add weight. Nominally, the book is about issues, problems, and solutions incumbent in the process of design. The later half of the book is a series of case studies of design work done by the author in various realms (home architecture, computer architecture, ogranizations, etc), and is mostly useful as a reference, I think. In other words, you can't read the case-studies as prose and walk away with full knowledge; unsurprisingly, they must be studied and preferably studied while you are working through an actual design problem. This book has led me to more fully explore career paths that focus on design work.

  19. 5 out of 5

    Steve

    The first half of this book is a wonderful collection of essays that anyone who enjoys examples of how software designers can learn from designers in other fields should read. The second half is an assortment of case studies, ranging from a remodeling project to a book project, to IBM projects. The case studies are less compelling but add some background for those who want more examples. The book also has many references to learn more. If you are a student of Patterns or agile software developme The first half of this book is a wonderful collection of essays that anyone who enjoys examples of how software designers can learn from designers in other fields should read. The second half is an assortment of case studies, ranging from a remodeling project to a book project, to IBM projects. The case studies are less compelling but add some background for those who want more examples. The book also has many references to learn more. If you are a student of Patterns or agile software development, the first half of this book will be both useful and enjoyable. The value of the case studies will be more mixed for some.

  20. 5 out of 5

    Mike Thompson

    The author, Frederick Brooks, is probably best known for classic study of how software engineering is done, "The Mythical Man-Month: Essays on Software Engineering" (http://en.wikipedia.org/wiki/The_Myth...). In "The Design of Design" he again distills his extensive experience into many profound observations. This time, his focus is on software design. Don't expect this book to teach how to design software, because it doesn't. The author's eye is on understand The author, Frederick Brooks, is probably best known for classic study of how software engineering is done, "The Mythical Man-Month: Essays on Software Engineering" (http://en.wikipedia.org/wiki/The_Myth...). In "The Design of Design" he again distills his extensive experience into many profound observations. This time, his focus is on software design. Don't expect this book to teach how to design software, because it doesn't. The author's eye is on understanding the mental model of how humans design. Drawing on related research, personal and peer experience, and cross-disciplinary cases studies from his own life, Dr. Brooks shows us how to cultivate great design thinking.

  21. 5 out of 5

    Jonathan

    Dr. Brooks is the author of the famed "The Mythical Man Month," a seminal book engineering teams and productivity. This book discusses how to think about design and design problems based on his life's experience at IBM and Academia. The only reason I didn't give this 5 stars was that the examples towards the end of the novel were not that engaging. The writing style was unassuming and funny at times, and its highly recommended for anyone who is interested in Design. The book is filled with great Dr. Brooks is the author of the famed "The Mythical Man Month," a seminal book engineering teams and productivity. This book discusses how to think about design and design problems based on his life's experience at IBM and Academia. The only reason I didn't give this 5 stars was that the examples towards the end of the novel were not that engaging. The writing style was unassuming and funny at times, and its highly recommended for anyone who is interested in Design. The book is filled with great quotes from Brooks and others. This may become required reading at Dimagi.

  22. 4 out of 5

    Magnus Lidbom

    DNF: I really like to read well thought out books about design. Notes on the Synthesis of Form for instance blew my mind. This one, not so much. I just kept waiting for something interesting, something thought provoking. Nothing. *crickets*. Off to the dnf pile with it.

  23. 4 out of 5

    John

    Interesting perspectives on design with a good selection of case studies. My main take away from the book is that while it is possible to have a good design without having a design rationale, the design rationale makes the design better, more flexible, and more robust. This applies well to software, where code is the design and comments should provide a rationale: they should not describe what the code is, but rather why it is.

  24. 5 out of 5

    David Lindelof

    This book is the culmination of Brooks's reflection on the design process itself, and illustrates its many points through examples in architecture and computer design. I found this book extremely valuable, if only for the exposition of the fact that great design is almost always the product of a single mind---two at most. I personally also appreciate Mr Brooks's openness when it comes to informing his reasoning from biblical truths. I find this attitude laudable.

  25. 4 out of 5

    Dale W

    This collection of essays by Brooks focus on the design process and incorporates lessons that can be applied to any number of disciplines (though engineers will likely find many lessons easier to apply). This book generated some interesting discussion among my co-workers. As always, I don't completely agree with everything Brooks asserts but I If you do any design work this should fine this worth reading.

  26. 4 out of 5

    Clif

    A good primer on higher level thinking about design. My interest in this was primarily from a computer architecture sense, but also in organizing large teams to tackle big projects. Lots of case studies (I hope you like reading about Brooks' houses) and concerete examples. Nothing groundbreaking, but lots of truth and lessons learned the hard way from people that have designed big things.

  27. 5 out of 5

    Will

    Needs more hands on experience. You do get more discussion about the people involved in the project and some more information about how CS programs should be more "hands on" and teach people different kinds of designs... but I think that's a lost cause in Academia until you can create a "Software Engineering" program for applied CS.

  28. 5 out of 5

    Peter Poole

    Brooks wanders from time to time and repeats some of his examples a bit too often, but what he does go into depth on is often fascinating and eye-opening. Especially in the first few chapters, I've dog-eared a good number of the pages for further reading because the groundwork he lays out about project management in general is spot-on.

  29. 5 out of 5

    Jess Martin

    Interesting ideas on the importance and process of design. Basically, make bold design decisions, spend plenty of time in the design phase. Use some process or method to explore the design space. Single designers (or pairs) trump teams, if you can manage it.

  30. 5 out of 5

    Craig Motlin

    The detailed building architecture chapters seemed out of place and boring in a computer architecture book and not compelling or expert level enough to interest building architects. The book was still somewhat interesting. A more accurate title would have been "stuff I designed"

Add a review

Your email address will not be published. Required fields are marked *

Loading...
We use cookies to give you the best online experience. By using our website you agree to our use of cookies in accordance with our cookie policy.