The Design of Design 73
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 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.| 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 |
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.
In Other WORD (Score:1, Insightful)
Metadesign
Yours In Akademgorodok,
K. Trout
Re: (Score:1)
Most people can't do good design.
... or maybe they just don't do good design, because it's work.
Re: (Score:1)
Systems of Systems (Score:3, Interesting)
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:
Re: (Score:3, Insightful)
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-t
Re:Systems of Systems (Score:4, Informative)
Oh, well I'm being purely facetious. We were joking around about Systems of Systems the other day and imagined it was just a matter of time before the upper management starts talking about filling their ranks with "specialists" working on selling their expertise on Architectures of Architectures and other nebulous self referential recursive functional titles. And lo and behold, we now have Design of Design. Brilliant!
Beat the gold rush while you can! ;-)
Re: (Score:1)
Oh, well I'm being purely facetious. We were joking around about Systems of Systems the other day and imagined it was just a matter of time before the upper management starts talking about filling their ranks with "specialists" working on selling their expertise on Architectures of Architectures and other nebulous self referential recursive functional titles. And lo and behold, we now have Design of Design. Brilliant!
Beat the gold rush while you can! ;-)
Oh, that's what you meant! LOL. I know exactly what you mean... it is a goldmine for architectural astronauts! :)
Re: (Score:3, Funny)
Designers!
Designers!
Designers!
Designers!
Re: (Score:2)
Like this chair [dornob.com]
Re: (Score:2)
"Great, SoS was the last big buzzword around corporations who wanted to charge the government a lot for doing LSI (large scale integration)."
What this is really about is planning, you learn to design better by experience and considering what goals you are trying to achieve and then you should spent time looking at other projects historically. Quite frankly planning ("design of design") is an experimentalist discipline since the human mind is limited and can't see all the details of large systems quickly an
Design Is Easy (Score:4, Funny)
Re:Design Is Easy (Score:5, Funny)
Re: (Score:3, Funny)
If your designer is hard, you've got other issues.
Yeah, it means you're working for Apple, for starters....
Thanks (Score:2)
That explains it. Those of us who care about design are always working hard to pay our Apple tax.
Re: (Score:1)
The hard part is the Designer.
Forget that! The hard part is the programmer!(10+1)!
Re: (Score:1)
Unfortunately this aint taught in school.. (Score:5, Interesting)
Re: (Score:3, Interesting)
As a mechanical engineer we had a quite a few courses related to design.
One course was dedicated solely on the design process itself in a general sense.
Another class dealt with the machine design process.
Another dealt with the design process for thermal and fluid systems.
Our final year course was a one year long design class where we were expected to iterate through our design multiple times and implement it.
Re: (Score:2)
While I agree on some points about the gap between academia and real world, I think you have to clarify what aspect of design is missing as well what kind of engineering.
In the classical sense of engineering, design is always a key component, but the engineer is concerned more with the practical aspects of design. In terms of UI and aesthetics, that's not always up to the engineer but the designer. For electronic devices for example, the electrical engineer will be concerned with the wires, solder, joints
Re:Unfortunately this aint taught in school.. (Score:4, Insightful)
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.
Re: (Score:2)
Re: (Score:3, Informative)
Its never been a crime to call yourself a doctor if you aren't- look at the fact everybody with a PHD, froma respectable school or some mail order place, calls themselves Doctor. Its illegal to practice medicine without a license, but not to use the title.
Re: (Score:2, Informative)
It is a crime (or should I say misdemeanor) to use the title 'Doctor' in the Netherlands, if you are neither a Medical Doctor [MD] nor a philosophical doctor [PhD].
I would assume this true in other parts in the world too, including the States, but I could of course be mistaken.
(Interestingly, the title 'professor', often the title of the one who is coaching the PhD student, is not protected in the Netherlands: you could start your own 'institution' and give yourself this title)
Re: (Score:2)
Its not in the states. Nor is it illegal to claim any other title, real or made up. Its only illegal to pretend to do the things they do (practice medicine, practice law, pretend to be a cop, etc). But I could sign my name Dr. Smith or John Smith M.D. and its legal as long as I don't try to diagnose someone. Nor should it be illegal- there's no harm being done. Now it is a firable offense to lie and claim you haev a doctorate to get a job, and that's as it should be. But they can't then go and arrest
Re: (Score:2)
You are onto something... (Score:2, Interesting)
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 softwar
Re: (Score:2)
Re: (Score:2)
That's because it's still far more art than science. There are too many design variations (combinations of variables) that satisfy requirements (at least). It is very expensive to run repeated experiments on the same design to control the variables, and no business is going to test dozens of designs of complex projects in production for long periods.
At best we can analyze similar projects and hope we can se
trying it (Score:1)
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,
Re: (Score:2)
And, of course, a book written by a designer of OS/360 would be useful mainly to people who want to learn to design things the way that OS/360 was designed. To those of us who have used OS/360, Brooks' name on a book is a red flag saying to stay far away from the book or any ideas that it might contain.
Unfortunately, lots of managers are likely to pick up on this book and push it on their designers. If you look at the design of much commercial software, you'd conclude that this has already happened. You'
Re: (Score:2, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Yeah, I've read TMMM. I've also seen lots of attempts to (blindly;-) put its advice into practice. I haven't been impressed by the results.
I also remember questions like "If one woman can make one baby in nine months, how many babies can twelve women make in three months?" back in the 1950s. The point back then was to satirize the man-hour (or person-hour) concept that was so widely used by industrial "efficiency experts". But we still use such measures. We also still measure programmer productivity by
Re:trying it (Score:5, Insightful)
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.
Re: (Score:1, Informative)
Remember that the total RAM of a typical 360 was less than 4 megabytes.
Try less than half a megabyte. You must be thinking of the 370.
Our campus 360/50 had 256K of stock memory and another 256K in a third-party add-on (the size of a refrigerator). Most x86 processors these days have that much on-chip cache.
actually 8MB... Re: must be thinking of the 370 (Score:2)
Try less than half a megabyte. You must be thinking of the 370.
up to 8MB actually... [wikipedia.org] 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 fascinati
Re: (Score:2)
My point is that some of the things done to save space and cycles were necessary evils under the resource constraints.
Re: (Score:2)
The best strategy for good design (Score:3, Insightful)
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.
Re: (Score:2)
And here, I'll point you to Dilbert [dilbert.com] on the topic. :-P
Re: (Score:3, Funny)
Re: (Score:2)
Meeting bloat is not necessarily a property of RAD. Its a symptom of out of control project management.
Back when I worked at Boeing, we used to have design meetings that were attended by 50 or 100 people. When maybe a dozen (or fewer) were ever expected to take action items or provide deliverables for the project. That was a symptom of matrix management and having to find something for all the idiot nephews to do.
At one meeting I suggested that documenting the legacy processes would go a lot faster if eve
Re: (Score:2)
I've got to remember that trick in the future. I could have used it many times in the past myself. About every committee I've ever been on has been loaded with a small core of people actually doing something and a large bloat of people
Re: (Score:2)
Really good design takes talent (Score:3, Insightful)
"Talent," you say... (Score:4, Interesting)
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.
Re: (Score:2)
So the key is to provide an environment in which this talent is nurtured. The people who've 'got it' will rise to the top. Those that don't remain down in the ranks.
This flys in the face of the 'nose to the grindstone, shoulder to the wheel' culture that some companies try to maintain. Effort is rewarded, not results. So everyone puts forth maximum effort. If the knuckle-draggers and mouth-breathers see someone working smarter instead of harder and receiving a reward for doing so, they might slack off. Or
Re: (Score:2)
Sure, tell that to any music teacher. Of course, you need to study and practice to become good at any job, but it's no use if you don't have a natural "gift" for it.
There's a big difference between repetitive and creative tasks. The more you train for a repetitive job the better you perform at it, but there's no way you can become a creative person if you lack the basic talent needed.
Re: (Score:1)
In fact, having natural ability hurts far more than it helps. More often than not, the students that display a lot of natural talent early on become intensely frustrated when they reach the extent of their natural gifts, and have to start practicing like their less gifted counterparts. The students that worked hard to achieve their talent
Re:Really good design takes skill, not talent (Score:2)
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.
Re: (Score:2)
Uhh... Software engineering is not an art. It is an applied science. It's why it's called "software engineering" and not "software theater".
Re: (Score:2, Insightful)
(Software) engineering is an art. You don't design science.
Engineering is creative. It's a highly personal skill that must be honed through years of study and practice. Engineers have different personal styles, but stay "on-model" during collaborative work for consistency's sake. An engineer's best work is their "masterpiece". etc.
Engineering is the art of applying science to make technology. The different fields of engineering are like the different fields of art in that they use different mediums but are
Brooks is a smart guy but (Score:1, Troll)
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.
Re: (Score:2, Insightful)
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. Ye
When noobs want to start a project... (Score:2)
Re: (Score:1)
...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.
You should get with the times. Agile is so out. Kanban lets you get into the fun parts with even less design.
Difference between design and academia (Score:2)
deduction, induction, pragmatism, fanaticism... (Score:2)
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 Sand