

“The Mythical Man Month” is still a good read - jmount
http://www.win-vector.com/blog/2011/10/the-mythical-man-month-is-still-a-good-read/

======
jseliger
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...](http://blog.seliger.com/2009/08/23/one-person-one-proposal-
dont-split-grant-writing-tasks) , 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.

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

~~~
tjr
I also had high hopes, but read this first:

[http://philip.greenspun.com/book-reviews/the-design-of-
desig...](http://philip.greenspun.com/book-reviews/the-design-of-design)

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

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

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

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

------
thret
"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

~~~
Monkeyget
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?

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

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

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

------
impendia
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?

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

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

------
brudgers
_Augustine's Laws_ is always worth a reread as well.

[[http://www.amazon.com/Augustines-Chairman-Lockheed-
Corporati...](http://www.amazon.com/Augustines-Chairman-Lockheed-Corporation-
Augustine/dp/1563472406)]

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

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

