A critic of Guido's blog on Python's lambda

[Alex Martelli]

Bill Atkins <NOatkinwSPAM at rpi.edu> wrote:
   ...
> > And here is where we check if you're as gracious about admitting your
> > errors, as I am about mine.  Brooks' law is:
> >
> > """Adding manpower to a late software project makes it later."""
> >
> > These are Brooks' words, literally.  OK so far?
> 
> You are correct.
> 
> I posted too hastily.  Here is what my paragraph ought to have said:
> 
>  Buh?  The project doesn't have to be late for Brooks's law to hold;
>  adding programmers *in the middle of a project*, so goes Brooks
>  reasoning, will always increase the time required to complete the
>  project because of various communication issues.
> 
> Agree?

"What does one do when an essential software project is behind schedule?
Add manpower, naturally. As Figs 2.1 through 2.4 suggest, this may or
may not help".

How do you translate "may or may not help" into "will always increase
the time required", and manage to impute that translation to "Brooks
reasoning"?  It *MAY* help -- Brooks says so very explicitly, and from
the Fig 2.4 he quotes just as explicitly you may infer he has in mind
that the cases in which it may help are those in which the project was
badly understaffed to begin with (a very common case, as the rest of the
early parts of chapter 2 explains quite adequately).

I could further critique Brooks for his ignoring specific personal
factors -- some extremely rare guys are able to get up to speed on an
existing project in less time, and requiring less time from those
already on board, than 99.9% of the human race (the JOAT in my previous
example); and, another crucial issue is that sometimes the key reason a
project is late is due to lack of skill on some crucial _specialty_, in
which case, while adding more "generic" programmers "may or may not
help" (in Brooks' words), adding just the right specialist (such as, the
cryptography expert in my previous example) can help a LOT. But, it
would be uncourteous to critique a seminal work in the field for not
anticipating such detailed, nuanced discussion (besides, in the next
chapter Brooks does mention teams including specialists, although if I
recall correctly he does not touch on the issue of a project which finds
out the need for a specialist _late_, as in this case). I'm still more
interested in critiquing your overgeneralization of Brooks' assertions
and reasoning.


Alex