Slashdot Mirror
The Design of Design
asgard4 writes "Coming up with sound, elegant, and easy to implement designs is not a trivial matter, as Fred Brooks, author of the classic book The Mythical Man-Month, acknowledges in his latest book The Design of Design. In many disciplines — especially in software development — the design process and how to produce good designs is relatively poorly understood. Teaching the design process to students is even more difficult. In the form of opinionated essays, Brooks attempts to summarize what we know about the design process, how it has changed over time, and how we can produce better and more elegant designs. Brooks has decades of experience designing large systems and is well known for his involvement in the design of IBM's OS/360. Even though Brooks is a computer scientist, the book applies equally well to many other disciplines outside of software development that have a formal design process, such as architecture. A lot of his examples come from other engineering disciplines and architecture. But of course he presents the obligatory OS/360 case study as well." Read on for the rest of Martin's review.
The Design of Design: Essays from a Computer Scientist
author
Frederic P. Brooks, Jr.
pages
432
publisher
Pearson Education
rating
8/10
reviewer
Martin Ecker
ISBN
0201362988
summary
Inspiring new book by Fred Brooks
The book is divided into six parts, the first three of which I consider the most relevant and most interesting. In part one, Brooks starts out with a discussion of models for the design process. In particular, he presents his take on how the traditional Rational Model (or the Waterfall Model — its offspring that is better known to computer scientists) is not sufficient to achieve greatness in design because it has a too simplistic and idealistic view of the design process. Brooks then proceeds to discuss better, more iterative models for designing, for example, Boehm's Spiral Model used in software development, which much of the newer so-called agile methodologies are based on. He argues that it is important to have a clear, concise model that can be accompanied by an easy to understand graphical representation, such as a diagram, in order to be able to teach the design process to novice designers.
Part two of the book is about collaboration and team design. On large projects there will usually be multiple designers who are forced to work together to produce a single, coherent design. The major stumbling block in team design is achieving conceptual integrity. Brooks suggests that the most important way of achieving this is by empowering a single software architect who has a high-level overview and can make the final call on different, competing design alternatives. I totally agree with this from my own experience of working on large projects where multiple people held design responsibilities. In this part of the book, the author also has a timely chapter on telecollaboration and on the impact of modern technologies, such as videoconferencing via the internet, on team design.
Part three, titled Design Principles, contains various essays on budgeting, constraints, and user involvement in the design process. There is also some interesting material on what Brooks calls exemplars in design, i.e. the reuse of previous designs as a whole or in part in creating new designs. My favorite chapter in this section of the book is the one on good style. I find that a good design doesn't just need to be coherent and functional, it also needs to be elegant. Brooks's definition of design style is quite good in my opinion: "Style is a set of different repeated microdecisions, each made the same way whenever it arises, even though the context may be different". Well put.
Part four of the book, in which the author outlines his dream software system for designing houses, is the by far weakest part of the book for me. The presented "design" of the dream system is simply a list of high-level features without going into any detail, which is pretty pointless in my opinion. Part five gets more interesting again with two essays on great designers and how to foster an environment at a company to make designers great. In particular, I like the idea of having designers "eat their own dog food", i.e. forcing them to use the end products of their designs out in the wild (maybe in form of a sabbatical at one of the system's customers). The book concludes with seven chapters on various case studies. While these are certainly interesting, they don't contain any additional essential thoughts on the design process that weren't already presented in the previous parts of the book.
The Design of Design is an excellent book from one of the pioneers in computer science. Brooks's writing style is as elegant and enjoyable as ever. While he dates himself in some of his examples, the overarching ideas of the book are timeless and important. Not many books have been written about the design of the design process itself and this book is a valuable addition. It is mostly aimed at designers and people who have spent some time reflecting on the design process itself. The casual reader and people who are more concerned with implementing designs rather than creating the designs themselves might find it somewhat intangible. However, even designers in disciplines other than computer science or software development can gain a lot from the insights in this book.
You can purchase The Design of Design: Essays from a Computer Scientist from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Part two of the book is about collaboration and team design. On large projects there will usually be multiple designers who are forced to work together to produce a single, coherent design. The major stumbling block in team design is achieving conceptual integrity. Brooks suggests that the most important way of achieving this is by empowering a single software architect who has a high-level overview and can make the final call on different, competing design alternatives. I totally agree with this from my own experience of working on large projects where multiple people held design responsibilities. In this part of the book, the author also has a timely chapter on telecollaboration and on the impact of modern technologies, such as videoconferencing via the internet, on team design.
Part three, titled Design Principles, contains various essays on budgeting, constraints, and user involvement in the design process. There is also some interesting material on what Brooks calls exemplars in design, i.e. the reuse of previous designs as a whole or in part in creating new designs. My favorite chapter in this section of the book is the one on good style. I find that a good design doesn't just need to be coherent and functional, it also needs to be elegant. Brooks's definition of design style is quite good in my opinion: "Style is a set of different repeated microdecisions, each made the same way whenever it arises, even though the context may be different". Well put.
Part four of the book, in which the author outlines his dream software system for designing houses, is the by far weakest part of the book for me. The presented "design" of the dream system is simply a list of high-level features without going into any detail, which is pretty pointless in my opinion. Part five gets more interesting again with two essays on great designers and how to foster an environment at a company to make designers great. In particular, I like the idea of having designers "eat their own dog food", i.e. forcing them to use the end products of their designs out in the wild (maybe in form of a sabbatical at one of the system's customers). The book concludes with seven chapters on various case studies. While these are certainly interesting, they don't contain any additional essential thoughts on the design process that weren't already presented in the previous parts of the book.
The Design of Design is an excellent book from one of the pioneers in computer science. Brooks's writing style is as elegant and enjoyable as ever. While he dates himself in some of his examples, the overarching ideas of the book are timeless and important. Not many books have been written about the design of the design process itself and this book is a valuable addition. It is mostly aimed at designers and people who have spent some time reflecting on the design process itself. The casual reader and people who are more concerned with implementing designs rather than creating the designs themselves might find it somewhat intangible. However, even designers in disciplines other than computer science or software development can gain a lot from the insights in this book.
You can purchase The Design of Design: Essays from a Computer Scientist from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Metadesign
Yours In Akademgorodok,
K. Trout
Great, SoS was the last big buzzword around corporations who wanted to charge the government a lot for doing LSI (large scale integration).
On the bright side, "DoD" is already taken in the military-industrial complex, so hopefully this won't catch on.
insert "yo dawg" reference here:
SoS is a big buzzword when it comes to software-intensive systems. In this case, I agree with you that it's just plain ol' LSI. When you start putting hardware in the mix (and I don't mean hardware=server), then the notion of SoS (and the engineering complexities of building such things) becomes more relevant (and less of a buzzword.) As a software enginer who has been working with systems engineers lately, it seems, at least to me, that software engineers (or at least people involved in developing medium-to-large software systems) could learn a thing or two from that discipline.
I'm not being facetious or argumentative. But I would like to know what your take on the SoS matter is. Honest curiosity.
Is for management to have a bunch of meetings and tell everyone what to do! It has worked so well so far.
But seriously, the issue is too much of MGMT sees "design" as a cost variable that can be slashed and money saved. Why waste time "designing" when you can save money doing!
Then again, anyone that knows a good thought out design will save dividends in the long run. But hey, what do us code monkeys know. It is rarely taught in school and if you are lucky enough to work with someone that understands the design process - you will benefit immensely.
You seem ignorant of how much Brooks learned from the OS/360 project. Many of those lessons he teaches in The Mythical Man-Month. Brooks' Law aside ("adding programmers to a late software project will make it later"), you might want to look up things like "second system effect".
If you have actually used OS/360, then you've been around the field for as long as I have. If you've never read TMMM in all that time, then I weep for your employers.
You can't teach talent.
In some circles, the "designing" he is talking about is called "system engineering". How do you arrange and partition the components in a system for the maximum amount of efficiency in designing, operating, and maintaining the system? How do you balance the customer's requirements with best practices, and where do you need to push back and get requirements changed? You have to think about the full life cycle of the product, not just any one phase, to come up with a truly elegant design, and this is what system engineering is all about.
That being said, while working at NASA I've seen the "system engineer" title slapped on more than a few engineers who appear to have very little intuition for how to create an elegant design (or frankly any design at all), resulting in bloated products and lots of wasted time explaining (and then implementing) things that are completely irrelevant to the project.
Whether unfortunately or no, system engineering is uncommon as an undergrad topic in most disciplines. It really does take a lot of knowledge and experience to be a true system engineer. That is why the code monkeys coming out of school haven't seen much of it and might not have fully appreciated what they were offered at the time.
Brooks has written about the lessons learned from OS/360, including some of the things that went wrong. If you're only going to judge someone by their work 40 years ago without paying any attention to any of the intervening time . . . heck, you're going to assume that a lot of people in the field today need their diapers changed.
Whatever you may think about OS/360 - and yes, I'm old enough to have worked with it, and written SVCs and channel programs - it was one of the biggest software efforts *ever* (let alone at the time), with high standards, thorough documentation, and tremendous success at satisfying its specifications and providing high reliability. We have gone so far beyond it because it was there to stand on and to show us both the good and bad results. Overcoming the limitations of the OS/360 VTOC, for example, was a prime impetus to the distributed-directory-tree concept that we now assume is normal (and ignoring those lessons - failing to learn from the past - leads one to the Windows Registry).
Remember that the total RAM of a typical 360 was less than 4 megabytes. Remember that the disk drives were under 200 Mb, and the data rate was 1 meg/second. I've got many times that inside the ARM embedded processor I work with. What they did with what they had was a giant step forward.
Oh, I dunno about that. He ran a UUCP site back in the very early 90s that I was fortunate enough to be able to maintain Internet access through once I left the university. Had a shell account and all. I figure you don't admin a box like that in that era without having technical skillz and imagination both.
But, honestly, when it comes to design, it's the intangible qualities that matter most. Taste, aesthetics, wisdom, call it what you will. Bottom line is, design is at least as much an art as a science. Yeah, technique can be and is learned by experience. But the underlying imagination to be a good designer is not learned. Someone either has it or does not.
Thanks, Fred, for the access a long time ago in a galaxy far far away.