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

[brian at sweetapp.com]

Bill Atkins wrote:
> brian at sweetapp.com writes:
>
>> Bill Atkins wrote:
>>> Buh?  The project doesn't have to be late for Brooks's law to hold;
>>> adding programmers, so goes Brooks reasoning, will always increase the
>>> time required to complete the project because of various communication
>>> issues.
>> 1. This is not what Brooks says. Brooks was talking about late
>>    projects. Please provide a supporting quote if you wish to continue
>>    to claim that "adding programmers will always increase the time
>>    required to complete the project".
>
> The "always" in my claim should not be there, I admit.  Brooks didn't
> claim that.
>
> I refer you to pages 17 - 18 of The Mythical Man-Month:
>
>   Since software construction is inherently a systems effort - an
>   exercise in complex interrelationships - communication effort is
>   great...Adding more men then lengthens, not shortens, the schedule.
>
> It is totally absurd to assume that, simply because a project has not
> yet passed its deadline, it will somehow become immune to the kinds of
> things Brooks is talking about.

Right. But only when a project is late does Brooks say that adding
programmers will always make it later (the claim that you made). In
other cases he says "Add manpower, ..., this may or may not help". That
seems intuitively obvious to me. If the programmers being added require
extensive training [1] by the team to become productive, and their
contribution to the project will be smaller than that amount (e.g. it
is a small or nearly completed project) then their net impact on the
project will be negative. If, OTOH, the new programmers are able to
quickly understand the project/organization/technologies and almost
immediately make useful contributions, then they are likely to have a
net positive impact.

>> 2. There has to be a mechanism where an organization can add
>>    developers - even if it is only for new projects. Python advocates
>
> Obviously.

It's good that you agree. I think that the ability to add new
productive developers to a project/team/organization is at least part
of what Alex means by "scaleability". I'm sure that he will correct me
if I am wrong.

>> [list of proposed Python advantages snipped]
> These are not things I look for in a programming language.

Fair enough. That doesn't mean that these advantages aren't important
to others or, in some situations, objectively important in the survival
of a project/organization.

For example, imagine that Google had used language X instead of Python
to develop their tools (assume they started with 10 expert X
programmers). Expert X programmers are Y percent more productive than
expert Python programmers. Now Google wants to grow aggressively and
needs 100 times more developer productivity (and expects to need even
more productivity in the future). If it is harder to find/hire/create
experts in language X than Python, then Y will have to be large to make
language X a better choice than Python. Also, if non-expert Python
programmers can be more productive than non-expert X programmers, then
Python also has an advantage. Eric Raymond claims that Python has very
high initial productivity and that becoming an expert is fairly easy.

BTW, I'm not saying that Common Lisp fits X in this example.

Cheers,
Brian

[1] I'm considering introducing bugs or misdesigns that have to be
fixed
    as part of training for the purposes of this discussion. Also the
    time needed to learn to coordinate with the rest of the team.