4 ms·

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 re

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.
- duncanj 16y ago
  It's not just rookie programmers. Even adding experienced programmers who are unfamiliar with the circumstances of the project will often make a project later. I do agree with you about adding orthogonal people, provided the project manager can bring them up to speed without slowing down the development team even more.
- Joeri 16y ago
  The irony is that the "never add people to a late project" principle is often viewed as a silver bullet solution to save late projects.
- JanezStupar 16y ago
  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.
jaymon 16y ago
Reminds me of a story about Larry Ellison: "He told me a story of how Larry Ellison actually got efficiencies from teams. If a team wasn’t productive, he’d come every couple of weeks and say, let me help you out. What did he do? He took away another person until the team started shipping and stopped having unproductive meetings." I love that quote, via: http://scobleizer.com/2010/11/12/why-google-cant-build-instagram/ http://scobleizer.com/2010/11/12/why-google-cant-build-insta...

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.

duncanj 16y ago
It's not just rookie programmers. Even adding experienced programmers who are unfamiliar with the circumstances of the project will often make a project later. I do agree with you about adding orthogonal people, provided the project manager can bring them up to speed without slowing down the development team even more.
Joeri 16y ago
The irony is that the "never add people to a late project" principle is often viewed as a silver bullet solution to save late projects.
JanezStupar 16y ago
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.

jaymon 16y ago

Reminds me of a story about Larry Ellison: "He told me a story of how Larry Ellison actually got efficiencies from teams. If a team wasn’t productive, he’d come every couple of weeks and say, let me help you out. What did he do? He took away another person until the team started shipping and stopped having unproductive meetings." I love that quote, via: http://scobleizer.com/2010/11/12/why-google-cant-build-instagram/ http://scobleizer.com/2010/11/12/why-google-cant-build-insta...