
The Mythical Man-Month - DanielBMarkham
http://www.hn-books.com/Books/The-Mythical-Man-Month.htm
======
drallison
The Mythical Man Month is a classic. I'd suggest that you also read the
transcriptions of the two NATO Software Engineering Conferences -- Garmishch
1968 and Rome 1969. They were incredibly influential and still make good
reading thanks to the efforts of Brian Randall and others. Many of the classic
software engineering quotes come from these conferences. The citeseer cache
links are:

[http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.14.2...](http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.14.2194&rep=rep1&type=pdf)

[http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.127....](http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.127.3064&rep=rep1&type=pdf)

------
ilcavero
This book is like reading Aristotle, it feels pretty old but it talks the
truth and the truth never changes

~~~
gjm11
Aristotle was a very smart chap, but it's hardly the case that everything he
said was unchangeable truth. (Random examples: his fundamental physics was
really, really wrong -- see
[http://csep10.phys.utk.edu/astr161/lect/history/aristotle_dy...](http://csep10.phys.utk.edu/astr161/lect/history/aristotle_dynamics.html)
for a very brief summary of some important errors; he said that men and women
have different numbers of teeth, which they don't; his distinction between
"substance" and "accidents" has been pretty much abandoned for ages, with the
possible exception of the Roman Catholic Church's teaching on
transubstantiation.)

~~~
ilcavero
You are right, I should've said Plato

~~~
icandoitbetter
Are you serious?

------
kevinburke
Quick summary: The complexity of a project increases as the square of the
number of people on the project, so if a project is behind schedule you may
want to remove people from it, not add them. It's difficult to predict
completion times for software projects but that won't stop non-technical
people from setting deadlines, or from asking you to promise to meet
deadlines. Waterfall development does not work.

~~~
uygtfrgtyjuhk
Why is it that people all remember this as the golden rule of the mythical man
month?

The exact circumstances refer to a particular type of team development
(surgical team) form a day when you wrote OSes in assembler and you had to
coordinate who used which memory address for which variable.

Yet people use the advice to avoid adding testers or documentation people to a
late project to relieve the developers. We have also advanced the programming
techniques and tools a little since the IBM360.

Yes adding a large number of rookie/trainee programmers to a crunch project is
a bad idea - but so is saying we can't get any extra help (Brook's says so) ,
we will just increase the hours the devs work until they are back on schedule.

~~~
JanezStupar
Well he explains pretty well why adding people (any kind of people) won't
work. To summarize it in one phrase: communication overhead.

You need to educate technical writers and testers on what the system does, but
this is the easy part - you also have to allow for a period of transition of
organization to accommodate all the new folks, that means education of the
original team who is probably already panicked and stressed out..

There are two ways you can go about it IMHO to prevent total loss - triage the
features and roll the thing out ASAP. Or you could try to make the most of
situation by indeed adding people - but not in parallel since this will only
increase the confusion. I would assign apprentices to the original team and
branch off later.

In a situation like this you have to accept that you have screwed up and that
there are no short term solutions. In longer term you can try to prevent
similar mistakes.

Once the torpedoes are in water no amount of wishing is going to make them
disappear. Time to tie down cargo and brace for impact.

------
j_baker
I think this (along with Peopleware) should be required reading to start a
software company. It's incredible how many companies still make fundamental
(and preventable) errors in running a software project.

------
ccwu
A nice summary. I was having drinks with a vc and he said the issues always
remain organizational. Brooks saw that software is no different.

------
peterquest
As a student, I read "Dreaming in Code" by Scott Rosenberg, which makes
several references to this book. In it, they run into just about every
conceivable problem a software project can encounter, which makes for a pretty
fun read.

