3 ms·

The argument he makes about increasing your chances of having one successful project by funding lots of projects is similar to the VC idea of investing in many

The argument he makes about increasing your chances of having one successful project by funding lots of projects is similar to the VC idea of investing in many companies in the hope that one pays off. While interesting Mythical Man Month's use of the metaphor always seemed to me to be saying that the non-parallelizable tasks take up the majority of the development time. Which is a different argument

JoeAltmaier 12y ago
Not the majority of the time; the long pole on the project. It won't be done-done until the long pole is done. So the schedule can't be brought in by adding 'resources'.
icegreentea 12y ago
Yeah, but one thing that often gets overlooked when talking about 'non-parallelizable tasks' is that most tasks aren't actually non-parallelizable, rather that they are weakly parallelizable (less than linear speed-up), or they have a large time constant (the 'train-up' time of adding additional resources). If you can identify this and recognize your current position, it can still be possible to accelerate your timelines by adding more people in some cases.
- HCIdivision17 12y ago
  Can we say courting is the equivalent of the 'train-up' period for having a baby?
  - JoeAltmaier 12y ago
    Definitely THAT can be parallelized. Just play the field!
    - adwn 12y ago
      But make sure that you have proper isolation between the subtasks.
- JoeAltmaier 12y ago
  Still you can't parallelize design/coding/debugging/packaging, much. Maybe each of those tasks can be individually, weakly.
- leni536 12y ago
  I think the main message that independently working on the same task can be a weak parallelization of random time tasks (independently random depending who is working on it). It simply falls in the category of "less than linear speed-up" parallelization. Since it is a trivial one, you can take it into account most of the time, however it's not too efficient.
Retric 12y ago
He also ignores overhead. Say you assign 5 teams to fix a bug and 2 finish it that day. Which code get's committed? First sounds great but the odds of solving the wrong problem or introducing another bug are high. As first team may have just missed the real issue. So now you compare solutions which adds another step. Now what happens if the bug is less than clear? You now have 5 teams that want to ask more or less the same questions.

JoeAltmaier 12y ago

Not the majority of the time; the long pole on the project. It won't be done-done until the long pole is done. So the schedule can't be brought in by adding 'resources'.

icegreentea 12y ago

Yeah, but one thing that often gets overlooked when talking about 'non-parallelizable tasks' is that most tasks aren't actually non-parallelizable, rather that they are weakly parallelizable (less than linear speed-up), or they have a large time constant (the 'train-up' time of adding additional resources). If you can identify this and recognize your current position, it can still be possible to accelerate your timelines by adding more people in some cases.

HCIdivision17 12y ago
Can we say courting is the equivalent of the 'train-up' period for having a baby?
- JoeAltmaier 12y ago
  Definitely THAT can be parallelized. Just play the field!
  - adwn 12y ago
    But make sure that you have proper isolation between the subtasks.
JoeAltmaier 12y ago
Still you can't parallelize design/coding/debugging/packaging, much. Maybe each of those tasks can be individually, weakly.
leni536 12y ago
I think the main message that independently working on the same task can be a weak parallelization of random time tasks (independently random depending who is working on it). It simply falls in the category of "less than linear speed-up" parallelization. Since it is a trivial one, you can take it into account most of the time, however it's not too efficient.

Retric 12y ago

He also ignores overhead. Say you assign 5 teams to fix a bug and 2 finish it that day. Which code get's committed? First sounds great but the odds of solving the wrong problem or introducing another bug are high. As first team may have just missed the real issue. So now you compare solutions which adds another step. Now what happens if the bug is less than clear? You now have 5 teams that want to ask more or less the same questions.