“The Mythical Man Month” is still a good read | Hacker News Reader

“The Mythical Man Month” is still a good read

win-vector.com

63 pointsjmount21 comments

It's not only a good read for hackers, either: it's a good read for almost any group who have an intellectually demanding task that can't be easily parallelized. I talked about The Mythical Man Month in a blog post about grant writing: http://blog.seliger.com/2009/08/23/one-person-one-proposal-d... , because in the grant world nonprofits will try to divide writing tasks among a group. The result is a proposal that, even if it hits the deadline, is probably a bad proposal.

I find books that cross their putative genre or field very interesting. Chris Matthews' Hardball is another; it's about politics, but it's really about life.

One of the things that makes MMM so good is how literate it is. It reminds me of the thing that Steve Jobs said was great about Apple, that it combined computing and the humanities. That is true of Fred Brooks as well, at least in his writing.

Coincidentally, Brooks made a surprise cameo in this piece about Jobs: http://www.wral.com/news/local/story/10230791/

Has anyone read his recent book, The Design of Design? I had high hopes for it, but ran out of steam.

I also had high hopes, but read this first:

http://philip.greenspun.com/book-reviews/the-design-of-desig...

and then decided not to buy a copy of the book. I may be wrong, but I've got stacks of stuff to read.

Thanks. What Greenspun says is consistent with what I read of the book. I think its biggest problem is that Brooks has been out of the business for too long; it lacks the buzz of MMM, the connection to real work and hard problems. As Greenspun points out, the only thing like that in the new book is the stuff about Brooks' house, and that's too self-referential.

Also the style is kind of bureaucratic and process-y. That's probably why I ran out of steam.

I'd agree with that review. The problem is, by the time you're experienced enough to grok what The Design of Design is trying to tell you, you've already figured out what he's trying to explain, and if you don't already know, mere reading is unlikely to be the thing that finally turns on the lightbulb.

Though I did walk away with one interesting insight, which is that when you are designing something one should always ask "What is the limiting factor in my design?", and that one should consider the question quite widely. "Money" or "time" are always the obvious answer, but the analysis should be taken deeper. It may also be something like "the amount of time my customer is willing to spend learning my putatively better design" or "the amount of bandwidth I have between me and my customers" or any number of subtler things. It is always something I was subconsciously considering but there is value in bringing those things to the conscious mind's attention, so you can add them to the mental checklist.

It strikes me funny how Brooks is mentioned so casually as an area professor as opposed to the living legend that he truly is.

This book will never get dated. There are fundamental lessons here to be learned through these stories that will affect all facets of life.

I am a believer that startups don't have to be hard or life consuming, and that organization and understanding of common pitfalls in the development cycle can really reduce stress. Kayak is an example of such success, a startups with strict 9-5 philosophy.

I highly recommend this book to anyone serious about developing software or working on any sort of projects.

Fantastic book. One of the things that is rough about computer science academia is usually it's either quickly obsolete, or too theoretical to be useful. In a sense they're confused about being and producing programmers or mathematicians. Brooks is the rare exception. His core concept that adding programmers increases communications which slows you down combines sociology with engineering. It is just as relevant today as when he first wrote it.

As mrchess states, you can read it an essay a day to digest it. Or better yet, reread every few years. The material doesn't chance, but with experience, one learns to appreciate him even more.

"On a small scale, a classic yields significantly different meanings when read in different circumstances and moods; on a larger scale, a classic conveys wholly different worlds when read in different times of life, at different stages of experience, feeling, and understanding of life. Classics may be interesting and even entertaining, but people always find they are not like books used for diversion, which give up all of their content at once - the classics seem to grow wiser as we grow wiser, more useful the more we use them." - Thomas Cleary

I read MMM years ago when I was in school because it was supposed to be one of the must read book of the field I was getting into. I found it abstruse, outdated, irrelevant and boring at the time.

The older, more mature, me with some real world experience, got back to a completely different book. What was dry is now engaging. Random opinions are now insights.

It also helps that my English is much better. The obscure vocabulary and outdated terms have become good writing and old fashioned (in a good way) style.

One thing that surprises me is the definition of architecture. To Brooks the architecture is the set of manuals needed for the user to use the system being created. It sort of is the (external) specification of the software. He clearly states that the architects must refrain from prescribing how the implementation should be. This is very different from today's definition of architect and software architecture. Why is it defined like this? Why isn't the conception of the (internal) architecture of the software a concern to Brooks?

I missed the change in meaning of architecture until you pointed it out. I had an uneasy feeling about the use of the word when reading, but you have really clarified what the difference in use is. Thanks!

Brooks particularly had in mind IBM's System 360. One of its goals was to have a single architecture span an extremely wide range of performance. So there were many models (e.g., 360-20, 360-65, 360-90) with a couple of orders of magnitude differences in cost and performance, but sharing a single architecture. Implementation teams built each model with attention to its specific required performance and cost constraints, leading to many different hardware designs. The system architects worked to define an architecture without constraining the possible implementations unnecessarily.

Yes, but it is what the 'A' in ISA stands for (http://en.wikipedia.org/wiki/Instruction_set_architecture)

My neighbour borrowed the book from uni library and gave it to me to read after he'd finished reading it in 5 days. I'm a bit slower than him, but so far I'm about 2/3 and it's a very understandable book with short concise stories that reflect on some major point to software development, and project management in general.

23 year old informatics student signing off.

No need to rush through it. I read an essay a day so that I could fully digest and reflect the lesson over the course of the day before going to the next.

The author (of this post, not Brooks) claims that desktops, icons, menus are "provably bad decisions".

Strong claim there. Anyone agree with him, and care to back up his point?

I've read MMM twice. Once, at about 28 years old, the next around 35 years old. (I'm aging myself here.)

I think I'll pick it up again next year. It really is a classic read that I'm only just now beginning to fully appreciate, even if I'm not discovering anything I didn't already know.

It tells me so much about myself and my colleagues. Thank you, Fred Brooks.

In a street market in Beijing I found the Handbook of Diagnosing and Solving Computer Problems, by William E. Perry, 1989. By contrast, this book has aged a lot more than MMM, but still is a fun read. The author calls software data processing GIGO, garbage in garbage out.

Augustine's Laws is always worth a reread as well.

[http://www.amazon.com/Augustines-Chairman-Lockheed-Corporati...]

My school uses this book for instruction in our software engineering course. During one of our capstone studio projects, they threw additional people at projects behind schedules. From what I heard, at best they wrote documentation while the teams continued developing.

When I was a kid, I'd heard of the "Mythical Man Month", but I thought it was some kind of dodecannual periodical about (or for) mythical men.

Reply on news.ycombinator.com