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:
The hard part is the Designer.
A major component missing from engineering education - software or otherwise - is the design process. In retrospect, I think this is due to too many professors lacking real world experience outside academia. Basically most of them have never been involved in large, complicated projects. I don't know about everyone else's education, but in my school we had just one course devoted to the software engineering process and one course devoted to the electrical engineering process. In retrospect this lopsided mix of fundamentals and process is really at odds with how engineering really works.
---------
No matter how thin you slice it, its still baloney.
The best way to learn how to design is by trying it. Like anything worth learning, you can't cheat the process by reviewing some tips in a book. Maybe a book will give you some great insights, but the human brain isn't going to apply it until it tries it.
Solutions to things you learn the hard way turn memetic. The best ideas propagate quite a distance, end up in APIs and crud, but most of the things you learn stop after 0 hops, i.e. they dont ever make it out of your own brain. This is your custom brew, what makes you a good or bad designer, and is arguably the slop you evolve on the path to becoming a good designer.
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
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.
Design is best learned via experience. You can read the pros/cons of a specific implementation within an overall design, but that doesn't give you any insight into the pros/cons of the specific implementation working with any other specific implemenation of the overall design.
In short, there are no generalities and generic specifics, which makes it very hard to teach traditionally as that requires consistency.
You can't teach talent.
He was in the computer business for only about 10 years and left it over 40 years ago. That makes him more of an "armchair quarterback" than an expert in design.
It's not some mythical "gift" that people either have or don't. It is a finely honed skill of combining creative thinking with pragmatic analysis and predicting what will happen in the future of the design process and product lifespan. The people who have "talent" are the ones who have nurtured their creativity and had lots of experience (often in unexpected places) that lets them anticipate what will be needed and how it will be used.
It's true that you can't "teach" it the way you teach someone arithmetic, but you can encourage the development of certain mental processes by providing the right environment, examples, and opportunities. But everyone develops differently, not everyone grows to college age with the same amount of creativity and pragmatism, and not everyone is even able to learn it until later in life. Thus, some people are better designers than others, and hopefully they will end up making more money for it. But that's not to say we can't increase the average design aptitude of the population through concerted effort. They may not all be geniuses, but they may be able to spot a genius when they see one and pay attention to him.
A major component missing from engineering education - software or otherwise - is the design process. In retrospect, I think this is due to too many professors lacking real world experience outside academia. Basically most of them have never been involved in large, complicated projects. I don't know about everyone else's education, but in my school we had just one course devoted to the software engineering process and one course devoted to the electrical engineering process. In retrospect this lopsided mix of fundamentals and process is really at odds with how engineering really works.
Funny you mention that (and I agree with you in that a lot of professors lack experience in large, complex projects, in particular enterprisey ones.) A few days ago I was talking with some colleagues about the disconnect between CS, EE and CE as well as between CS and MIS (which can be almost fatal for young graduates working either in engineering or corporate projects.)
But, and more related to your point, I was wondering how great it would have been if I had been exposed not just to one undergrad software engineering course, but to several, or perhaps one software engineering course paired with a systems engineering course (perhaps using case studies of projects that had problems wrt to design and management.)
My own undergrad course in software engineering had me building a fairly non-trivial application using PowerBuilder with a team. It was a good exercise, but I would have preferred this experienced to have been followed by another undergrad course covering requirements elicitation and analysis, testing, project estimation, design trade-offs and software process management., perhaps by using case studies.
My two grad courses in software engineering were mostly learning how to architect systems in UML and case studies on formal methods. Those are fine, but still, the items listed above were missing. Those were equally valuable and I had to learn about them the hard way. Software engineering education cannot be complete until those topics are standard part of the curriculum at the undergrad level.
Good design takes skill, which is different from talent in that skills can be honed through practice, whereas talent is one's ability to perform a task without any prior experience at it. If your natural hand-eye coordination is good enough, you can juggle without ever really practicing or learning technique. But, with practice, most everyone can learn to juggle, no matter what their starting ability is. Design is the same. Some people have a better natural ability to partition a system into subsystems. However, with practice, everyone can learn that skill.
We all know what to do, but we don't know how to get re-elected once we have done it
Most people can't do good design.
... or maybe they just don't do good design, because it's work.
...they by-pass a solid design stage and whip out the agile card. It allows them to get onto the fun parts straight away. Of course, it all turns to custard. Good design is a combination of education, and experience. In the end some perople just never get it.
In post Patriot Act America, the library books scan you.
That explains it. Those of us who care about design are always working hard to pay our Apple tax.
-- Our systemic servants do not good masters make.
Try less than half a megabyte. You must be thinking of the 370.
up to 8MB actually... excerpt
The part about 256 KB fits what you say with less than half a meg - I've read that memory was crazy expensive back in the day (as I write this on my 16gb laptop!). Before my time, but still - very interesting stuff. I bet it was fascinating to write code for these things.
Still is a crime to represent yourself as an Engineer without being licensed, or, in some states, to "practice" engineering. However, the "industrial exemption" applies to a lot of folks working in "industry", and in industry, there's no licensure requirement.
better not get a yellow pages ad calling yourself an Engineer, unless you've got the license. (and no, it's not like a contractors license)
The big difference between design and academia is that when you build something it is judged by Reality. In academia another person is the judge. A person can be manipulated into agreeing with your theoretical ideas. Reality doesn't care. That is why engineering is so difficult. Unlike almost any other field you can't BS your way through. When you build something it either works or doesn't and it is apparent for even a layperson to know you screwed up. Ask the BP engineers. They have millions of hours of experience drilling wells in deep water but in this one Reality came in and showed them they don't know everything. It doesn't take an engineer to know they screwed up.
The same can't be said of a scientist, lawyer, doctor, politician, teacher, ect. They can always blame their failures on other things and it usually takes someone with a similar level of education to know they screwed up.
I love Jesus, except for his foreign policy.
The big difference between design and academia is that when you build something it is judged by Reality. In academia another person is the judge. A person can be manipulated into agreeing with your theoretical ideas. Reality doesn't care.
The underlying questions, to which you allude here, are [or once were] the passionate obsession of professional philosphers, from David Hume [in the mid-18th Century], through Immanuel Kant & Friedrich Schiller [at the turn of the 19th Century], and on to Charles Sander Peirce [in the late 19th and early 20th Centuries].
If you are at all interested in these topics, then you ought to read a little Peirce, on questions of common sense and pragmatism [or pragmaticism, as Peirce liked to call it].
Of course, during the remainder of the 20th Century, all of that progress came to a screeching halt, with the rise of the fanatical nihilism of Sartre, Derrida, Foucault, Chomsky, and their ilk...
Very few children are encouraged to be creative. Most teachers are parrots spitting from the text books which are not written by the best teachers. best teacher don't write books and best book writers almost never teach. Thus, to capture a higher level thinking in a creative way becomes a gift. So, when some one comes up a book that shows how things work and are designed people do not accept it and find ways to improve that is published. Creative people are in general, not appreciated. Thus, most University Professors are not creative and basic researchers, rather applied researchers. For example, the person finds a species say, Elephant is a basic researcher. However, twenty others who state African elephants are 10" taller than Asian elephant and so on are applied scientists who have never done any practical discoveries. Software Engineering and Design in general, are creative basic research. Coder and others are applied technicians. So, teach a Design course needs immense amount of creativity, enthusiasm to teach and document the thought process itself. How may such basic design Professors are there with industrial and hands on experience in addition academic credentials? The current book is just a starting point and instead of criticizing, why don't we find people to improve it?