Upon reading this book for the third time over a span of two decades, I decided to react to its content this time rather than to simply dismiss it as poorly informed and seriously flawed. That assessment derives largely from my fifty years of experience as an aerospace system designer, with an extensive record in development methods R&D. Furthermore, I am dismayed at the book’s trivialization of design and its naive understanding of engineering practice in general. Regrettably, the book thereupon proceeds along an even worse course via its fatuous prescriptions for a purported science of design and its automation.
Questions for Inquiring Minds: forty-five years after its initial publication, how many books can be found on Amazon that address “design science” or the like, especially in the sense that Simon laboriously enunciated? Ok then, what actual impact has Simon’s version of design science in itself ever had on engineering or design practice? Did actual engineering practitioners or experienced designers in general ever regard this book as consequential or relevant?
Fundamentally, Simon construes design as amenable to casting as a science per se, rather than as an endeavor wherein many of the more challenging aspects are typically dealt with largely as an art. That design is informed or facilitated by science is vacuously true, not to mention irrelevant. Moreover, engineers/designers have developed much of that sort of science, because they are resourceful in finding better ways to fashion improved products. Disconcertingly, Simon’s thesis begins with the premise of design as problem solving, rather than one mainly of resolving problem situations by first systematically formulating problem statements. Furthermore, design problem discovery proceeds well beyond design per se – at least into development testing. The lesson: finalized well-formed problem statements exist only in textbooks or in classrooms.
To expand on the book’s critique in the context of the exigencies of the real world of design,
1. the only design-oriented engineering author cited by Simon is Clive Dym (p. 128)
- Dym otherwise states “as grounds for serious study, the art of engineering has lain fallow...To recognize that there is an art to engineering design does not preclude design from being worthy of serious scientific study.” (p.185 of “Engineering Design – A Synthesis of Views”)
2. the conceivability of a science of design (chapters 5 & 6 ) is dubious given the vital role of the practitioner art component typical of customary practice
- Turing Award recipient Frederick Brooks has written “I believe a ‘science of design’ to be impossible” (p. xii of “The Design of Design – Essays from a Computer Scientist”)
3. that technical rationality inherent in the science of design can serve as a practical basis for design methodology (chapter 5 ) is widely discounted
- Donald Schon counsels “Let us search, instead, for an epistemology of practice which some practitioners do bring to (design challenges)” (p. 49 of “The Reflective Practitioner- How Professionals Think in Action”)
4. that design problems are givens readily available as design requirements (e.g., p. 115) for immediate search for design alternatives (p. 121) from which to select, is wholly unrealistic
- Donald Schon points out that “with this emphasis on problem solving, we ignore problem setting...In real world practice, problems do not present themselves...as givens” (p.40)
5. even worse, Simon’s advocacy of a science-based methodology (Chapter 5 ) is questionable, especially as reliant upon an encompassing automated search/optimization process
- Christopher Alexander states “the search for the image or criterion for success is going on at the same time as the search for a solution” (p. 197 of “Notes on the Synthesis of Form”)
- Frederick Brooks observes that “as one ponders the tradeoffs, there comes a new understanding of the whole design problem as an...interplay of factors (that yields) ...a change in the weightings of the desiderata” (p. 26)
6. the value of formal logic for development (p. 115 ) is neither uncommon nor a panacea, but its use may be misleading
- Christopher Alexander notes that “however rational we should like to be...Logical methods, at best, rearrange the way in which our personal bias is to be introduced” (p.194)
7. as a response to Item 1 above, Ozgur Eris’ “Effective Inquiry for Innovative Engineering Design” is a thoughtful, systematic, and admirable exploration of design practice
- Eris’ thesis claims “the uniqueness of design thinking by identifying a specific class of questions that are characteristic of design situations.” (p. 1)
To elaborate on the fourth bullet above, in engineering development endeavors, there are typically three partly trial-and-error steps leading up to the codification of design requirements, or problem definition per se:
1, problem situation – exploration, bounding & characterization of the problem in context
2. problem setting – determination of the programmatic goals, strategies, resources, etc., for project definition/go-ahead
3. problem framing – delineation of the essential technical issues and implications to be addressed, along with reservations and success criteria
4. problem specification – particular requirements that the design effort is committed to satisfy and verify.
Upon the completion of Step 4, one then has a design problem statement in hand, albeit one subject to refinement as design proceeds. The good news is that much of the more problematic work has been accomplished at this point. Moreover, if a (hypothetical) design problem is reduced to algorithmic resolution, then there exists a relatively tractable design task to deal with, provided the algorithms’ (largely subjective) parameters remain fixed. After all, optimization algorithms per se are rather straightforward; it’s their subjective application that is highly problematic.
Although Simon had presented the notion previously, his characterization of bounded rationality here is both cogent and useful. Somewhat surprisingly though, he then attempts to overcome this phenomenon by articulating his automated design alternative via a generation-selection-optimization strategy. This technical rationality synthesis stands in complete disregard of the essential nature, context, and conduct of design. Simon’s design strategy is accordingly at best an idealization; but in my estimation, not at all a helpful or viable one. Nonetheless, bounded rationality is an important concept, and its clear explication and fruitful development may be found in Gerd Gigerenzer’s “Bounded Rationality”. In acknowledging the realities of decision making as vital to matters besides design, Gigerenzer develops the companion notion of “quasi-rationality”. As the term suggests, it obtains from an interplay of analysis and intuition, as characteristic of many human cognitive tasks. Quasi-rationality, moreover, is the basis on which designers naturally operate.
In sum, Simon’s design science and technical rationality are idealized notions resiliently contrary to successful design practice. Moreover, practical design automation itself has been introduced from at least the 1960s and applied ever more expansively. This has been done largely on the initiatives of engineering practitioners themselves. In contrast, Simon’s skewed and inordinate vision of design automation simply fails to apprehend the multifaceted nature of design and the flexible performance demanded of designers. Furthermore, Simon’s crucial expectations for operations research and artificial intelligence technologies have since this book was first published been quite notably compromised in terms of delivered results. In all then, what in tenuous principle might be done per this book’s vision, through expansive automation under ideal conditions, is unworthy of serious consideration, and especially so now in hindsight.
Even if Simon’s vision were realized, it would merely shift much of the presently perceived complexity would be shifted elsewhere in the development process, and the overall process implementation would be rendered even more complex and probably less responsive. (See Nicholas Rescher’s commentary on the inevitability of complexity escalation via the introduction of technology that appears in “Complexity: A Philosophical Overview.”) Arguably, Simon’s proposal for design science automation will likely remain unworthy of consideration, if only because of the staggering complexity concentration, flexibility/fragility issues, and development cost/time entailed in its workable implementation for real-world deployment.
Loading your book clubs
There was a problem loading your book clubs. Please try again.
Not in a club? Learn more
Join or create book clubs
Choose books together
Track your books
Bring your club to Amazon Book Clubs, start a new book club and invite your friends to join, or find a club that’s right for you for free.
Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required. Learn more
Read instantly on your browser with Kindle Cloud Reader.
Using your mobile phone camera - scan the code below and download the Kindle app.
Flip to back Flip to front
Follow the Author
Something went wrong. Please try your request again later.
Customers who viewed this item also viewed
Page 1 of 1 Start overPage 1 of 1
About the author
Follow authors to get new release updates, plus improved recommendations.
Customer reviews
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
Reviewed in the United States 🇺🇸 on March 25, 2014
Reviewed in the United States 🇺🇸 on May 1, 2021
Reviewed in the United States 🇺🇸 on May 23, 2017
Reviewed in the United States 🇺🇸 on September 11, 2014
Reviewed in the United States 🇺🇸 on September 20, 2017
Reviewed in the United States 🇺🇸 on November 9, 2009
Reviewed in the United States 🇺🇸 on September 29, 2022
Top reviews from other countries
Amazon Reader
Important and useful
Reviewed in the United Kingdom 🇬🇧 on March 14, 2013
