
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.”
Rating: 3 stars
Yevgeniy Brikman
If you enjoyed this post, you may also like my books. If you need help with DevOps, reach out to me at Gruntwork.