Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Design of Design

samzenpus posted more than 4 years ago | from the read-all-about-it dept.

Books 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.

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.

cancel ×

73 comments

Sorry! There are no comments related to the filter you selected.

In Other WORD (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32267044)

Metadesign

Yours In Akademgorodok,
K. Trout

Nigger-free code is most important (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32267404)

Its a well-known fact that niggers can't do good design. This is why ubuntu sucks. If it had only kept the purity of debian's nigger-free code it would be of higher quality.

Re:Nigger-free code is most important (0)

egcagrac0 (1410377) | more than 4 years ago | (#32269056)

Most people can't do good design.

... or maybe they just don't do good design, because it's work.

Re:In Other WORD (1)

tesseractor (1201811) | more than 4 years ago | (#32268820)

Kilgore! We have been looking for you.

The design of first posting (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32267046)

Is to post first.

Systems of Systems (2, Interesting)

rwa2 (4391) | more than 4 years ago | (#32267156)

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:Systems of Systems (3, Insightful)

luis_a_espinal (1810296) | more than 4 years ago | (#32267286)

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.

Re:Systems of Systems (3, Informative)

rwa2 (4391) | more than 4 years ago | (#32267520)

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:Systems of Systems (1)

luis_a_espinal (1810296) | more than 4 years ago | (#32267694)

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:Systems of Systems (0)

Anonymous Coward | more than 4 years ago | (#32267428)

Just by reading the summary, it seems like he's written a book about a well-studied field.

We call it Ergonomics [wikipedia.org] .

Re:Systems of Systems (2, Funny)

twistedsymphony (956982) | more than 4 years ago | (#32267452)

I'm waiting for the book by Steve Ballmer

Designers!
Designers!
Designers!
Designers!

... I'm especially looking forward to the chapter on looking at every day objects (like a simple chair) from a COMPLETELY different perspective.

Re:Systems of Systems (1)

egcagrac0 (1410377) | more than 4 years ago | (#32269236)

Like this chair [dornob.com]

Re:Systems of Systems (1)

blahplusplus (757119) | more than 4 years ago | (#32268492)

"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 and easily, and hence we need to iterate a lot or experiment with a lot of projects and their problems first. Notice that simple systems that the human mind can grasp it can make great designs provided the combinations of elements are not numerous and the pieces of the design you want are not severely conflicted by the system (universe, compuational limit of CPU, memory, etc) of what you are trying to harness and design _around_ (the goals vs the universe/systems limitations). Designs are ultimately about balancing possibilities of a system against and limitations and constraints it puts on the goals you want to achieve.

Design Is Easy (3, Funny)

NicknamesAreStupid (1040118) | more than 4 years ago | (#32267210)

The hard part is the Designer.

Re:Design Is Easy (5, Funny)

Anonymous Coward | more than 4 years ago | (#32267284)

If your designer is hard, you've got other issues.

Re:Design Is Easy (2, Funny)

grcumb (781340) | more than 4 years ago | (#32271046)

If your designer is hard, you've got other issues.

Yeah, it means you're working for Apple, for starters....

Thanks (1)

ynotds (318243) | more than 4 years ago | (#32272398)

That explains it. Those of us who care about design are always working hard to pay our Apple tax.

Re:Design Is Easy (1)

luis_a_espinal (1810296) | more than 4 years ago | (#32267308)

The hard part is the Designer.

Forget that! The hard part is the programmer!(10+1)!

Re:Design Is Easy (0)

Anonymous Coward | more than 4 years ago | (#32268326)

Design is where all the brain work is, whether you do the design up front or not. Programming is grunt work. At best you might use a clever trick when programming.

Re:Design Is Easy (1)

kaychoro (1340087) | more than 4 years ago | (#32267484)

Designers (Systems & UI) are easy. The hard part is making sure both designs match.

Unfortunately this aint taught in school.. (5, Interesting)

carn1fex (613593) | more than 4 years ago | (#32267328)

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.

Re:Unfortunately this aint taught in school.. (2, Interesting)

TheKidWho (705796) | more than 4 years ago | (#32267422)

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:Unfortunately this aint taught in school.. (1)

UnknowingFool (672806) | more than 4 years ago | (#32267672)

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, battery all confirm to power requirements, safety, durability, etc. He isn't concerned as much with how the device looks or the UI. The materials guy will be worried about what how the materials perform and not so much how they look, etc.

Re:Unfortunately this aint taught in school.. (3, Insightful)

robot256 (1635039) | more than 4 years ago | (#32267940)

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:Unfortunately this aint taught in school.. (1)

UnknowingFool (672806) | more than 4 years ago | (#32268510)

For the most part, I think the term "engineer" is overused. The archaic or classical usage was for one of the main disciplines of engineering like Mechanical, Chemical, Electrical, etc. These days it may mean anything from networking to design. Back in the day, the title "Professional Engineer" meant you were certified in one of the disciplines and it is a crime to misrepresent yourself as if you said you were a Attorney-At-Law or Doctor when you were not.

Re:Unfortunately this aint taught in school.. (2, Informative)

AuMatar (183847) | more than 4 years ago | (#32268622)

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:Unfortunately this aint taught in school.. (2, Informative)

plankrwf (929870) | more than 4 years ago | (#32269012)

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:Unfortunately this aint taught in school.. (1)

AuMatar (183847) | more than 4 years ago | (#32272018)

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 you for having amde the claim.

Re:Unfortunately this aint taught in school.. (0)

Anonymous Coward | more than 4 years ago | (#32273840)

Remember, Barney always signed his name Barney Fife, M.D.

In his case, the M.D. stood for Mayberry Deputy.

Professional engineers (0)

Anonymous Coward | more than 4 years ago | (#32274868)

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)

Re:Unfortunately this aint taught in school.. (0)

Anonymous Coward | more than 4 years ago | (#32272070)

and lots of wasted time explaining (and then implementing) things that are completely irrelevant to the project.

Possibly true but keep in mind that that's just your perception. They may have had good reasons for working on things that you regard as unnecessary but they think are needed.

Different people regard different things as important. Including designers.

Re:Unfortunately this aint taught in school.. (1)

elrous0 (869638) | more than 4 years ago | (#32267902)

It's funny you should say this. I'm taking a course in system design even as we speak. It's one of my degree requirements. So, yes, it is actually required today as part of a software engineering curriculum (at my university anyway).

You are onto something... (2, Interesting)

luis_a_espinal (1810296) | more than 4 years ago | (#32268302)

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.

Re:Unfortunately this aint taught in school.. (1)

w0mprat (1317953) | more than 4 years ago | (#32274762)

Design is related to critical thinking and creativity, being among things evaporating from our school systems in developed nations. These, along with any any physical education and core science education.

Re:Unfortunately this aint taught in school.. (1)

Tablizer (95088) | more than 4 years ago | (#32275268)

A major component missing from engineering education - software or otherwise - is the design process.

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 separate out the design process differences from the domain (business rule) differences.

Some of the "cherished" design ideas I learned in school turned out to be mostly wrong in hindsight: hierarchies and separation of concerns. Hierarchies are too inflexible for non-trivial systems. Some form of set theory is usually a better fit, but conceptually difficult for users to grok and manage.

And at least in the business domain you can't separate all concerns: they interweave whether we want them to or not. For example, a customer discount may be calculated based on where the customer lives, past purchases, relationship to employees (which may disqualify them), and product availability. These will cut across multiple concerns. Instead, work on managing the crossing of concerns rather than pretend like we can easily separate them. (It's possible to separate them with thick interface walls, but this creates its own problems.)

trying it (0)

digitalsushi (137809) | more than 4 years ago | (#32267346)

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.

Agreed! (0)

Anonymous Coward | more than 4 years ago | (#32267406)

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.

Re:trying it (1)

jc42 (318812) | more than 4 years ago | (#32267636)

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'd be wrong, of course, since this book has just been published. But other books along the same line have existed for some time.

(Out of curiosity, has Brooks been involved in the design of things that we might want to emulate? Presumably OS/360 isn't the only thing he's had a hand in, but the review doesn't seem to mention anything else.)

Re:trying it (2, Insightful)

Anonymous Coward | more than 4 years ago | (#32267748)

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:trying it (1)

careysub (976506) | more than 4 years ago | (#32268888)

Mod parent up!

Re:trying it (1)

jc42 (318812) | more than 4 years ago | (#32274178)

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 lines of code produced, with results that are well understood by most programmers.

It's always seemed to me that such advice books should have contributed to our understanding, but it's not obvious that this can even be tested in any meaningful fashion. It does seem clear that the computer field is still as poorly managed as it was decades ago, so maybe we haven't learned all that much about organization or design.

OTOH, we probably have a lot more people with strongly-held beliefs in the subject. ;-)

Re:trying it (5, Insightful)

DutchUncle (826473) | more than 4 years ago | (#32268074)

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.

Re:trying it (1, Informative)

Anonymous Coward | more than 4 years ago | (#32268488)

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 (1)

Fubari (196373) | more than 4 years ago | (#32274790)

Try less than half a megabyte. You must be thinking of the 370.

up to 8MB actually... [wikipedia.org] excerpt

The System/360 models announced in 1964 ranged in speed from 0.034 MIPS [1] to 1.700 MIPS (50 times that speed)[2], with 8 kB and up to 8 MB of main memory,[2] though the latter was unusual. A large system might have 256 KB of main storage.

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.

Re:trying it (1)

DutchUncle (826473) | more than 4 years ago | (#32356314)

Rensselaer Polytechnic Institute, 1975 I believe, upgraded from a 360/50 to a 360/67 using the same 3.5 meg of core (four telephone-booth sized racks, water cooled). You could cook on it. Literally. One of the grad students managed to cook an egg.

My point is that some of the things done to save space and cycles were necessary evils under the resource constraints.

Re:trying it (1)

lena_10326 (1100441) | more than 4 years ago | (#32313106)

Technology changes. Design principles don't. Case study: mankind's history and study of structural engineering and architecture.

The best strategy for good design (2, Insightful)

hsmith (818216) | more than 4 years ago | (#32267386)

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.

Re:The best strategy for good design (1)

gstoddart (321705) | more than 4 years ago | (#32267796)

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!

And here, I'll point you to Dilbert [dilbert.com] on the topic. :-P

Re:The best strategy for good design (2, Funny)

elrous0 (869638) | more than 4 years ago | (#32268008)

Haven't you heard? The new buzzword today is RAD design [wikipedia.org] , which means that EVERYONE has a bunch of meetings and tells you how to do it--over and over again. It's like playing baseball with the stadium hot dog vendor and loudmouth fans right there on the team with the players.

Re:The best strategy for good design (1)

PPH (736903) | more than 4 years ago | (#32269386)

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 everyone in the room were to take a piece of the process, write up a short description of it and bring it to the next meeting. At the next meeting, we had about 10 people in attendance.

We did some RAD design where we'd prototype something on a development server, give the users a week or two to tinker with it, try to break it, and make comments. That worked well, as the people outside of the user community couldn't be bothered to learn the system. Interestingly, the biggest problem we had with a prototype was that it was too good. We were working around the edges of a piece-of-shit system that had cost the company about a quarter of a billion dollars to develop and caused manufacturing no small number of headaches. A couple of us slapped together a prototype web page that did what the legacy system tried to do over a couple of weeks in our spare time. When manufacturing management saw it, they ordered it to be put into production within a week. Talk about panic.

Re:The best strategy for good design (1)

elrous0 (869638) | more than 4 years ago | (#32277592)

At one meeting I suggested that documenting the legacy processes would go a lot faster if everyone in the room were to take a piece of the process, write up a short description of it and bring it to the next meeting. At the next meeting, we had about 10 people in attendance.

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 who are just looking for something to kill time (and who usually aren't paying attention, know nothing about the subject at hand, and just get in the way of the real work).

Re:The best strategy for good design (1)

PPH (736903) | more than 4 years ago | (#32278522)

All they need is a cc of the meeting minutes. Often, I've taken the other side of this argument as well. If I get 'invited' to a meeting, I'll expect to be providing input there. Lots of it. If they don't want my advice, they can just send me the memo later.

Really good design takes talent (3, Insightful)

ivandavidoff (969036) | more than 4 years ago | (#32267888)

You can't teach talent.

"Talent," you say... (3, Interesting)

robot256 (1635039) | more than 4 years ago | (#32268104)

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:"Talent," you say... (0)

Anonymous Coward | more than 4 years ago | (#32268892)

Perhaps one of the reasons it's not taught, is that it is hard to measure. Math and language skills are nice testable attributes that a school can test in a short period of time to see if the student is smart enough. It's pretty hard to subjectively measure how good design or leadership skills are beyond some standard metrics like timeliness and cost versus complexity and funding. We live in a society that is hyper-focused on getting SAT and GRE scores up, such that other skills get marginalized until later in life when they matter.

Re:"Talent," you say... (1)

PPH (736903) | more than 4 years ago | (#32268978)

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 feel that the compensation system is unfair. That's bad for morale.

Re:"Talent," you say... (1)

mangu (126918) | more than 4 years ago | (#32269950)

It's not some mythical "gift" that people either have or don't. It is a finely honed skill

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:"Talent," you say... (1)

lkeagle (519176) | more than 4 years ago | (#32275310)

As a music teacher, from a family of classical musicians going back at least 3 generations, I can promise you that there is no natural aptitude that can't be learned.

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 are far more likely to advance their skills to the highest level, and be able to cope with the pressures involved at the level of professional performance.

I'm sure that things are similar in any creative field.

Many people say that too much study kills spontaneity in music, but although study may kill a small talent, it is a must to develop a big one. By concentrating on precision, one arrives at technique, but by concentrating on technique one does not arrive at precision. - George Gershwin

Re:Really good design takes skill, not talent (1)

quanticle (843097) | more than 4 years ago | (#32269000)

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.

Re:Really good design takes talent (1)

lena_10326 (1100441) | more than 4 years ago | (#32269812)

You can't teach talent.

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:Really good design takes talent (2, Insightful)

urusan (1755332) | more than 4 years ago | (#32271988)

(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 unified by the common principles of design.

My mother is a professional artist and it's amazing how similar our work really is.

Brooks is a smart guy but (0, Troll)

ClosedSource (238333) | more than 4 years ago | (#32268088)

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:Brooks is a smart guy but (0)

Anonymous Coward | more than 4 years ago | (#32268560)

Agreed. I don't see how he could offer anything relevant other than historical perspective from 40+ years ago, but nothing state of the art.

Re:Brooks is a smart guy but (0)

Anonymous Coward | more than 4 years ago | (#32268676)

Modding this informative. "Armchair quarterback" is a perfectly fair criticism.

Re:Brooks is a smart guy but (2, Insightful)

metallurge (693631) | more than 4 years ago | (#32268720)

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.

Re:Brooks is a smart guy but (0)

Anonymous Coward | more than 4 years ago | (#32269894)

Wikipedia says 8 years. But, if he only worked for 8 years and managed a failure, but told the truth about how that happened in a way that many people can understand and learn from, I can see how that could be immensely valuable.

S360 is 40+ years old..what can Brooks tell us? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32268234)

I was at IBM after college, and S360 was ancient news in the 70's! What on earth can Brooks say or write in 2010 about 'how to design?' I'm assuming wherever Brooks is, he's got academic tenure based on his 40 year old contribution to S360. I'd be more interested in knowing how John Bardeen developed the transistor to be honest.

When noobs want to start a project... (1)

stimpleton (732392) | more than 4 years ago | (#32270216)

...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.

Re:When noobs want to start a project... (1)

Bocconcini (1057516) | more than 4 years ago | (#32270340)

...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.

Re:When noobs want to start a project... (0)

Anonymous Coward | more than 4 years ago | (#32270550)

I've been doing this for a while now, and 'build one and throw it away' is the only "design stage" that's never failed me. For the first one you shouldn't overly care about upfront design (just grow it and learn), and when you're throwing it away you know what to do for the next one, so agile works fine.

Difference between design and academia (1)

trout007 (975317) | more than 4 years ago | (#32277030)

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.

deduction, induction, pragmatism, fanaticism... (1)

mosel-saar-ruwer (732341) | more than 4 years ago | (#32278748)

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 [wikipedia.org] , 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...

Anonymous Coward. (0)

Anonymous Coward | more than 4 years ago | (#32280042)

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?

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?