7 ms·

The Mythical Man-Month

45 points by DanielBMarkham 16y ago

ilcavero 16y ago
This book is like reading Aristotle, it feels pretty old but it talks the truth and the truth never changes
- gjm11 16y ago
  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_dynamics.html http://csep10.phys.utk.edu/astr161/lect/history/aristotle_dy... 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 16y ago
    You are right, I should've said Plato
    - icandoitbetter 16y ago
      Are you serious?
  - yters 16y ago
    He's more right than wrong, esp when compared to our naturalism.
  - huherto 16y ago
    What I find amazing about them is that they were able to figure out so many things with a very limited body of knowledge. I understand they missed the mark in many things, but still they were able to come up with many great ideas(even if they were wrong).
- sabat 16y ago
  I agree with the author's concepts, but I find this book unreadable. It's just too darned dense -- needlessly dense.
  - lolfoo 16y ago
    It's one of the easiest reads on my shelf. What do you want, a version where you find Waldo instead?
ccwu 16y ago
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.
- deleted 16y ago
  [deleted]
kevinburke 16y ago
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.
- kokon 16y ago
  That's one thing. The other problem he was also trying to cover was, how do you scale? When you are dealing with a big project, how can you tame the complexity of dealing with so many people?
- yoyar 16y ago
  > Waterfall development does not work. < All evidence that I've seen confirms this. Yet, in companies where they practice waterfall, all the evidence in the world can't seem to convince them of this fundamental problem. The solution is try "more" waterfall, or to alter the process of waterfall. The cognition that it isn't working, despite mountains of evidence just doesn't seem to register. I suppose this is due to an already dysfunctional company culture.
  - Joeri 16y ago
    It's worse. I've proven, with cold hard numbers, that our waterfall process didn't work and gotten agreement. But I get told that we _have to_ provide a waterfall schedule to some of our key customers (big multinationals) or otherwise they won't believe we'll deliver, because everybody that's not in software knows by now that waterfall is how all real software gets made. le sigh So, what we do know is we make up a waterfall schedule to give to the customer, and then we do our own thing afterwards.
- uygtfrgtyjuhk 16y ago
  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.
drallison 16y ago
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.2194&rep=rep1&type=pdf http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.14.2... http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.127.3064&rep=rep1&type=pdf http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.127....
j_baker 16y ago
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.
peterquest 16y ago
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.

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

gjm11 16y ago
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_dynamics.html http://csep10.phys.utk.edu/astr161/lect/history/aristotle_dy... 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 16y ago
  You are right, I should've said Plato
  - icandoitbetter 16y ago
    Are you serious?
- yters 16y ago
  He's more right than wrong, esp when compared to our naturalism.
- huherto 16y ago
  What I find amazing about them is that they were able to figure out so many things with a very limited body of knowledge. I understand they missed the mark in many things, but still they were able to come up with many great ideas(even if they were wrong).
sabat 16y ago
I agree with the author's concepts, but I find this book unreadable. It's just too darned dense -- needlessly dense.
- lolfoo 16y ago
  It's one of the easiest reads on my shelf. What do you want, a version where you find Waldo instead?

ccwu 16y ago

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.

deleted 16y ago
[deleted]

kevinburke 16y ago

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.

kokon 16y ago
That's one thing. The other problem he was also trying to cover was, how do you scale? When you are dealing with a big project, how can you tame the complexity of dealing with so many people?
yoyar 16y ago
> Waterfall development does not work. < All evidence that I've seen confirms this. Yet, in companies where they practice waterfall, all the evidence in the world can't seem to convince them of this fundamental problem. The solution is try "more" waterfall, or to alter the process of waterfall. The cognition that it isn't working, despite mountains of evidence just doesn't seem to register. I suppose this is due to an already dysfunctional company culture.
- Joeri 16y ago
  It's worse. I've proven, with cold hard numbers, that our waterfall process didn't work and gotten agreement. But I get told that we _have to_ provide a waterfall schedule to some of our key customers (big multinationals) or otherwise they won't believe we'll deliver, because everybody that's not in software knows by now that waterfall is how all real software gets made. le sigh So, what we do know is we make up a waterfall schedule to give to the customer, and then we do our own thing afterwards.
uygtfrgtyjuhk 16y ago
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.

drallison 16y ago

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.2194&rep=rep1&type=pdf http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.14.2... http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.127.3064&rep=rep1&type=pdf http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.127....

j_baker 16y ago

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.

peterquest 16y ago

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.