The Design of Design: Essays from a Computer Scientist

Reviewed by: 

This will be an instant classic. If you are a designer you should beg, borrow, buy or steal this book (as a reviewer, I got it for free).

Brooks has been my hero ever since The Mythical Man Month, and his new book is written in his same “no nonsense” style. “I believe the science of design,” says Brooks, “to be an impossible and indeed misleading goal. I offer neither a text nor a monograph with a coherent argument, but a few opinionated essays.” The audience for this book will be designers, design researchers, and project managers interested in design. While Brooks continues to mine lessons from the OS/360 project, he also builds on his experiences after. He punctuates chapters with quotes and references from an extremely wide variety of sources, including, “The Cathedral and the Bazaar,” Francis Bacon, Tolkien, Herbert Simon, Dorothy Sayers, Seymour Cray, and the Bible. Brooks gives the reader a glimpse of the creative processes of various designers such as Mozart, Plato, and Schon, and uses offbeat chapter titles such as, “Requirements, Sin, and Contracts,” “User Models, Better Wrong than Vague,” and my favorite, “The Divorce of Design.” In the chapter, “Rationalism versus Empiricism in Design,” Brooks quotes both John Locke and Rene Descartes and proclaims, “I am a Dyed-in-the-Wool Empiricist”.

Brooks uses his knowledge of computer architecture, history, specification, and design to abstract the essence of the “design of design.” In the chapter “Esthetics in Technical Design,” he defines clean design as design made as simple as possible and calls this “esthetic parsimony,” but then adds that parsimony is not enough. A clean design also has orthogonality, propriety and generality. These three, stated as commandments become: Do not link the independent; Do not introduce the immaterial; and Do not restrict what is inherent.

The chapter “Requirements, Sin, and Contracts” is sure to raise controversy. Brooks claims that all process models are no more than miseducation through oversimplification, useful only for design by committee, that committee having only bureaucrats for stakeholders. He also claims that requirements specifications are nothing more than wish lists without constraints, unprioritized as to need or cost, decoupled from end-users, and with no tradeoffs made between urgency and oversight. Ah, Brooks, you had me at “miseducation.”

In another chapter Brooks addresses the need for improved user and use models to expose shared but incorrect assumptions. “As soon as a designer starts to make explicit models, trouble strikes: he is rudely confronted with how much he doesn’t know.” This realization of not knowing forces questions, and even if there are no answers forthcoming, yields good results as “[a]n articulated guess beats an unspoken assumption.” Brooks certainly knows also how to walk the walk. As designer of the Stretch operator’s console, knowing little of what computer operators do, he took on the job of apprentice operator. How many designers can make that claim, or more tellingly, are permitted that freedom?

Brooks still believes in the chief designer that he first wrote about in The Mythical Man Month, and provides the pro’s and con’s of teaming, and pro’s and con’s of design in a distributed environment. He claims that small teams are better than large, conceptual integrity is extremely important as are multidisciplinary design reviews, and that a manager must have the ability to stand up to a customer and say “No” (to prevent “bells and whistles”). Brooks points out the value of identifying and prioritizing design constraints, the value of prototypes, the value of incremental development and iterated delivery. He also keeps the questions coming for the prospective designer such as, “Which assumptions matter?” How much?” “What are the critical resources?” And notes that the critical resources aren’t always dollars but sometimes something else, more often as not, time and timing.

In the chapter “Great Designs Come from Great Designers,” Brooks again rails at the managerial emphasis on process. Declaring process to be conservative, aiming at predictability, the reader may ask, “What’s wrong with this?” “It sounds like a manager’s dream.” What’s wrong, Brooks states is that process fights the last war, working against innovation to prevent great design. Brooks isn’t advocating no process, but instead identifying the value in holding off process as long as possible—process that can smother greatness in its cradle. What’s wrong with process he claims, is its prematurity; process
1. Is rules bound (i.e. anti-imagination)
2. Avoids mistakes rather than encourages great things to happen
3. Uses resources that may be better applied elsewhere.

Brooks lightly touches on the subject of software design and development; process is bad, patterns are good, and has criticism for how the designer in general is educated and employed. He states that students must be allowed practice more, have their designs critiqued more, be encouraged to create portfolios that they can take to job interviews, and most importantly, that student teams must be allowed to fail (i.e. fail without getting a failing grade). In industry, new engineers must have mentors and have their assignments rotated to encourage growth. Note that Brooks practices what he preaches. He sent one of his reports back to grad school mid-career(!). Edgar Codd went on to invent the relational database, generating millions of dollars for IBM.

The book concludes with several design case studies on topics such as the architecture of buildings, the IBM/360, book design of Computer Architecture: Concepts and Evolution, and computer center organization. There are so many goodies in this book there really is no way to give it all proper justice. Each chapter ends with notes and references; there is a recommended reading section (!) in addition to a bibliography, and an index. That good design and designers can only come from the study and practice of design may be obvious, but still there is something unidentifiable, mysterious, inexpressible, that separates designers such as you and me from the Fred Brooks Jr’s of this world.

Long Description: 

This will be an instant classic. If you are a designer you should beg, borrow, buy or steal this book (as a reviewer, I got it for free).

Brooks has been my hero ever since The Mythical Man Month, and his new book is written in his same “no nonsense” style. “I believe the science of design,” says Brooks, “to be an impossible and indeed misleading goal. I offer neither a text nor a monograph with a coherent argument, but a few opinionated essays.” The audience for this book will be designers, design researchers, and project managers interested in design. While Brooks continues to mine lessons from the OS/360 project, he also builds on his experiences after. He punctuates chapters with quotes and references from an extremely wide variety of sources, including, “The Cathedral and the Bazaar,” Francis Bacon, Tolkien, Herbert Simon, Dorothy Sayers, Seymour Cray, and the Bible. Brooks gives the reader a glimpse of the creative processes of various designers such as Mozart, Plato, and Schon, and uses offbeat chapter titles such as, “Requirements, Sin, and Contracts,” “User Models, Better Wrong than Vague,” and my favorite, “The Divorce of Design.” In the chapter, “Rationalism versus Empiricism in Design,” Brooks quotes both John Locke and Rene Descartes and proclaims, “I am a Dyed-in-the-Wool Empiricist”.

Brooks uses his knowledge of computer architecture, history, specification, and design to abstract the essence of the “design of design.” In the chapter “Esthetics in Technical Design,” he defines clean design as design made as simple as possible and calls this “esthetic parsimony,” but then adds that parsimony is not enough. A clean design also has orthogonality, propriety and generality. These three, stated as commandments become: Do not link the independent; Do not introduce the immaterial; and Do not restrict what is inherent.

The chapter “Requirements, Sin, and Contracts” is sure to raise controversy. Brooks claims that all process models are no more than miseducation through oversimplification, useful only for design by committee, that committee having only bureaucrats for stakeholders. He also claims that requirements specifications are nothing more than wish lists without constraints, unprioritized as to need or cost, decoupled from end-users, and with no tradeoffs made between urgency and oversight. Ah, Brooks, you had me at “miseducation.”

In another chapter Brooks addresses the need for improved user and use models to expose shared but incorrect assumptions. “As soon as a designer starts to make explicit models, trouble strikes: he is rudely confronted with how much he doesn’t know.” This realization of not knowing forces questions, and even if there are no answers forthcoming, yields good results as “[a]n articulated guess beats an unspoken assumption.” Brooks certainly knows also how to walk the walk. As designer of the Stretch operator’s console, knowing little of what computer operators do, he took on the job of apprentice operator. How many designers can make that claim, or more tellingly, are permitted that freedom?

Brooks still believes in the chief designer that he first wrote about in The Mythical Man Month, and provides the pro’s and con’s of teaming, and pro’s and con’s of design in a distributed environment. He claims that small teams are better than large, conceptual integrity is extremely important as are multidisciplinary design reviews, and that a manager must have the ability to stand up to a customer and say “No” (to prevent “bells and whistles”). Brooks points out the value of identifying and prioritizing design constraints, the value of prototypes, the value of incremental development and iterated delivery. He also keeps the questions coming for the prospective designer such as, “Which assumptions matter?” How much?” “What are the critical resources?” And notes that the critical resources aren’t always dollars but sometimes something else, more often as not, time and timing.

In the chapter “Great Designs Come from Great Designers,” Brooks again rails at the managerial emphasis on process. Declaring process to be conservative, aiming at predictability, the reader may ask, “What’s wrong with this?” “It sounds like a manager’s dream.” What’s wrong, Brooks states is that process fights the last war, working against innovation to prevent great design. Brooks isn’t advocating no process, but instead identifying the value in holding off process as long as possible—process that can smother greatness in its cradle. What’s wrong with process he claims, is its prematurity; process
1. Is rules bound (i.e. anti-imagination)
2. Avoids mistakes rather than encourages great things to happen
3. Uses resources that may be better applied elsewhere.

Brooks lightly touches on the subject of software design and development; process is bad, patterns are good, and has criticism for how the designer in general is educated and employed. He states that students must be allowed practice more, have their designs critiqued more, be encouraged to create portfolios that they can take to job interviews, and most importantly, that student teams must be allowed to fail (i.e. fail without getting a failing grade). In industry, new engineers must have mentors and have their assignments rotated to encourage growth. Note that Brooks practices what he preaches. He sent one of his reports back to grad school mid-career(!). Edgar Codd went on to invent the relational database, generating millions of dollars for IBM.

The book concludes with several design case studies on topics such as the architecture of buildings, the IBM/360, book design of Computer Architecture: Concepts and Evolution, and computer center organization. There are so many goodies in this book there really is no way to give it all proper justice. Each chapter ends with notes and references; there is a recommended reading section (!) in addition to a bibliography, and an index. That good design and designers can only come from the study and practice of design may be obvious, but still there is something unidentifiable, mysterious, inexpressible, that separates designers such as you and me from the Fred Brooks Jr’s of this world.

Reviewed by: 

This will be an instant classic. If you are a designer you should beg, borrow, buy or steal this book (as a reviewer, I got it for free).

Brooks has been my hero ever since The Mythical Man Month, and his new book is written in his same “no nonsense” style. “I believe the science of design,” says Brooks, “to be an impossible and indeed misleading goal. I offer neither a text nor a monograph with a coherent argument, but a few opinionated essays.” The audience for this book will be designers, design researchers, and project managers interested in design. While Brooks continues to mine lessons from the OS/360 project, he also builds on his experiences after. He punctuates chapters with quotes and references from an extremely wide variety of sources, including, “The Cathedral and the Bazaar,” Francis Bacon, Tolkien, Herbert Simon, Dorothy Sayers, Seymour Cray, and the Bible. Brooks gives the reader a glimpse of the creative processes of various designers such as Mozart, Plato, and Schon, and uses offbeat chapter titles such as, “Requirements, Sin, and Contracts,” “User Models, Better Wrong than Vague,” and my favorite, “The Divorce of Design.” In the chapter, “Rationalism versus Empiricism in Design,” Brooks quotes both John Locke and Rene Descartes and proclaims, “I am a Dyed-in-the-Wool Empiricist”.

Brooks uses his knowledge of computer architecture, history, specification, and design to abstract the essence of the “design of design.” In the chapter “Esthetics in Technical Design,” he defines clean design as design made as simple as possible and calls this “esthetic parsimony,” but then adds that parsimony is not enough. A clean design also has orthogonality, propriety and generality. These three, stated as commandments become: Do not link the independent; Do not introduce the immaterial; and Do not restrict what is inherent.

The chapter “Requirements, Sin, and Contracts” is sure to raise controversy. Brooks claims that all process models are no more than miseducation through oversimplification, useful only for design by committee, that committee having only bureaucrats for stakeholders. He also claims that requirements specifications are nothing more than wish lists without constraints, unprioritized as to need or cost, decoupled from end-users, and with no tradeoffs made between urgency and oversight. Ah, Brooks, you had me at “miseducation.”

In another chapter Brooks addresses the need for improved user and use models to expose shared but incorrect assumptions. “As soon as a designer starts to make explicit models, trouble strikes: he is rudely confronted with how much he doesn’t know.” This realization of not knowing forces questions, and even if there are no answers forthcoming, yields good results as “[a]n articulated guess beats an unspoken assumption.” Brooks certainly knows also how to walk the walk. As designer of the Stretch operator’s console, knowing little of what computer operators do, he took on the job of apprentice operator. How many designers can make that claim, or more tellingly, are permitted that freedom?

Brooks still believes in the chief designer that he first wrote about in The Mythical Man Month, and provides the pro’s and con’s of teaming, and pro’s and con’s of design in a distributed environment. He claims that small teams are better than large, conceptual integrity is extremely important as are multidisciplinary design reviews, and that a manager must have the ability to stand up to a customer and say “No” (to prevent “bells and whistles”). Brooks points out the value of identifying and prioritizing design constraints, the value of prototypes, the value of incremental development and iterated delivery. He also keeps the questions coming for the prospective designer such as, “Which assumptions matter?” How much?” “What are the critical resources?” And notes that the critical resources aren’t always dollars but sometimes something else, more often as not, time and timing.

In the chapter “Great Designs Come from Great Designers,” Brooks again rails at the managerial emphasis on process. Declaring process to be conservative, aiming at predictability, the reader may ask, “What’s wrong with this?” “It sounds like a manager’s dream.” What’s wrong, Brooks states is that process fights the last war, working against innovation to prevent great design. Brooks isn’t advocating no process, but instead identifying the value in holding off process as long as possible—process that can smother greatness in its cradle. What’s wrong with process he claims, is its prematurity; process
1. Is rules bound (i.e. anti-imagination)
2. Avoids mistakes rather than encourages great things to happen
3. Uses resources that may be better applied elsewhere.

Brooks lightly touches on the subject of software design and development; process is bad, patterns are good, and has criticism for how the designer in general is educated and employed. He states that students must be allowed practice more, have their designs critiqued more, be encouraged to create portfolios that they can take to job interviews, and most importantly, that student teams must be allowed to fail (i.e. fail without getting a failing grade). In industry, new engineers must have mentors and have their assignments rotated to encourage growth. Note that Brooks practices what he preaches. He sent one of his reports back to grad school mid-career(!). Edgar Codd went on to invent the relational database, generating millions of dollars for IBM.

The book concludes with several design case studies on topics such as the architecture of buildings, the IBM/360, book design of Computer Architecture: Concepts and Evolution, and computer center organization. There are so many goodies in this book there really is no way to give it all proper justice. Each chapter ends with notes and references; there is a recommended reading section (!) in addition to a bibliography, and an index. That good design and designers can only come from the study and practice of design may be obvious, but still there is something unidentifiable, mysterious, inexpressible, that separates designers such as you and me from the Fred Brooks Jr’s of this world.

Long Description: 

This will be an instant classic. If you are a designer you should beg, borrow, buy or steal this book (as a reviewer, I got it for free).

Brooks has been my hero ever since The Mythical Man Month, and his new book is written in his same “no nonsense” style. “I believe the science of design,” says Brooks, “to be an impossible and indeed misleading goal. I offer neither a text nor a monograph with a coherent argument, but a few opinionated essays.” The audience for this book will be designers, design researchers, and project managers interested in design. While Brooks continues to mine lessons from the OS/360 project, he also builds on his experiences after. He punctuates chapters with quotes and references from an extremely wide variety of sources, including, “The Cathedral and the Bazaar,” Francis Bacon, Tolkien, Herbert Simon, Dorothy Sayers, Seymour Cray, and the Bible. Brooks gives the reader a glimpse of the creative processes of various designers such as Mozart, Plato, and Schon, and uses offbeat chapter titles such as, “Requirements, Sin, and Contracts,” “User Models, Better Wrong than Vague,” and my favorite, “The Divorce of Design.” In the chapter, “Rationalism versus Empiricism in Design,” Brooks quotes both John Locke and Rene Descartes and proclaims, “I am a Dyed-in-the-Wool Empiricist”.

Brooks uses his knowledge of computer architecture, history, specification, and design to abstract the essence of the “design of design.” In the chapter “Esthetics in Technical Design,” he defines clean design as design made as simple as possible and calls this “esthetic parsimony,” but then adds that parsimony is not enough. A clean design also has orthogonality, propriety and generality. These three, stated as commandments become: Do not link the independent; Do not introduce the immaterial; and Do not restrict what is inherent.

The chapter “Requirements, Sin, and Contracts” is sure to raise controversy. Brooks claims that all process models are no more than miseducation through oversimplification, useful only for design by committee, that committee having only bureaucrats for stakeholders. He also claims that requirements specifications are nothing more than wish lists without constraints, unprioritized as to need or cost, decoupled from end-users, and with no tradeoffs made between urgency and oversight. Ah, Brooks, you had me at “miseducation.”

In another chapter Brooks addresses the need for improved user and use models to expose shared but incorrect assumptions. “As soon as a designer starts to make explicit models, trouble strikes: he is rudely confronted with how much he doesn’t know.” This realization of not knowing forces questions, and even if there are no answers forthcoming, yields good results as “[a]n articulated guess beats an unspoken assumption.” Brooks certainly knows also how to walk the walk. As designer of the Stretch operator’s console, knowing little of what computer operators do, he took on the job of apprentice operator. How many designers can make that claim, or more tellingly, are permitted that freedom?

Brooks still believes in the chief designer that he first wrote about in The Mythical Man Month, and provides the pro’s and con’s of teaming, and pro’s and con’s of design in a distributed environment. He claims that small teams are better than large, conceptual integrity is extremely important as are multidisciplinary design reviews, and that a manager must have the ability to stand up to a customer and say “No” (to prevent “bells and whistles”). Brooks points out the value of identifying and prioritizing design constraints, the value of prototypes, the value of incremental development and iterated delivery. He also keeps the questions coming for the prospective designer such as, “Which assumptions matter?” How much?” “What are the critical resources?” And notes that the critical resources aren’t always dollars but sometimes something else, more often as not, time and timing.

In the chapter “Great Designs Come from Great Designers,” Brooks again rails at the managerial emphasis on process. Declaring process to be conservative, aiming at predictability, the reader may ask, “What’s wrong with this?” “It sounds like a manager’s dream.” What’s wrong, Brooks states is that process fights the last war, working against innovation to prevent great design. Brooks isn’t advocating no process, but instead identifying the value in holding off process as long as possible—process that can smother greatness in its cradle. What’s wrong with process he claims, is its prematurity; process
1. Is rules bound (i.e. anti-imagination)
2. Avoids mistakes rather than encourages great things to happen
3. Uses resources that may be better applied elsewhere.

Brooks lightly touches on the subject of software design and development; process is bad, patterns are good, and has criticism for how the designer in general is educated and employed. He states that students must be allowed practice more, have their designs critiqued more, be encouraged to create portfolios that they can take to job interviews, and most importantly, that student teams must be allowed to fail (i.e. fail without getting a failing grade). In industry, new engineers must have mentors and have their assignments rotated to encourage growth. Note that Brooks practices what he preaches. He sent one of his reports back to grad school mid-career(!). Edgar Codd went on to invent the relational database, generating millions of dollars for IBM.

The book concludes with several design case studies on topics such as the architecture of buildings, the IBM/360, book design of Computer Architecture: Concepts and Evolution, and computer center organization. There are so many goodies in this book there really is no way to give it all proper justice. Each chapter ends with notes and references; there is a recommended reading section (!) in addition to a bibliography, and an index. That good design and designers can only come from the study and practice of design may be obvious, but still there is something unidentifiable, mysterious, inexpressible, that separates designers such as you and me from the Fred Brooks Jr’s of this world.