Brook's law:
Adding man power to a late software project makes it later
Not always.
I am living proof that Brook's law not always prevails. No, it's not because I'm extremely good in what I do (<joke>which I am, of course, cough, cough</joke>), it's just that Brook's law doesn't account for every possible scenario.
In this case, I was called to the rescue to perform a task that the main team could do anyway, but that could also be done by an outsider (thus saving precious time to that team), because it was a self-contained task for which no deep knowledge of the project was required. I simply (yeah, simply, I'll tell you about "simply") had to migrate a database, which proved to be a real PITA, but was doable anyway.
The project was late when I got there and was still late after I left, and the day after they told me the migration would have to be done again with some different specs over the destiny database (another PITA), but my point remains: the project was late, I was there, I finished my task, and I didn't delay the project further.
Hence, Brook's law not always holds.
Well... (Score:1)
Tasks can be implemented in parallell only if they are independent and require no communication effort on the part of the designers/programmers. If not, the communication effort adds overhead which may overcome the effect of more people.
Correct (Score:1)
In justifying his law, Brooks specifically cited the increasing number of interpersonal interfaces (n**2) and the ramp-up time of the new staff (and the concomittant investment required by the existing staff in the new staff's ramp-up. If Rent on a pickup is less than on a bulldozer, or if there's a premium for early completion advantage; or if Supervisors get paid double rate
Splitting non-core tasks off and out-sourcing
Bill
# I had a sig when sigs were cool
use Sig;
Re:Correct (Score:1)
Yes, he is
And I'm adding that book to my list of books to buy