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

[Bill Atkins]

aleaxit at yahoo.com (Alex Martelli) writes:

> Bill Atkins <NOatkinwSPAM at rpi.edu> wrote:
>    ...
>> Believe it or not, _you_ got it wrong.
>
> Acknowledged: Common Lisp is even MORE insane (note that the quote
> "INSANELY extensible" is from Tilton) than I believed -- I'm pretty sure
> that the Lisp dialects I used in 1979-1981 didn't go to such crazy
> extremes, and neither did Scheme.
>
>> 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.
>
> 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?

> Your claim, that adding programmers will ALWAYS increase the time, is
> not just wrong, but utterly ridiculous.  I can't put it better than the
> wikipedia:
> """
> Misconceptions
>
> A commonly understood implication of Brooks' law is that it will be more
> productive to employ a smaller number of very talented (and highly paid)
> programmers on a project than to employ a larger number of less talented
> programmers, since individual programmer productivity can vary greatly
> between highly talented and efficient programmers and less talented
> programmers. However, Brooks' law does not mean that starving a project
> of resources by employing fewer programmers beyond a certain point will
> get it done faster.
> """
>
> Moreover, check out the research on Pair Programming: it scientifically,
> empirically confirms that "two heads are better than one", which should
> surprise nobody.  Does this mean that there aren't "various
> communication issues"?  Of course there are, but there's no implied
> weighting of these factors wrt the _advantages_ of having that second
> person on the team (check the Pair Programming literature for long lists
> of those advantages).
>
> Only empirical research can tell us where the boundary is -- when
> productivity is decreased by going from N to N+1.  A lot depends on
> imponderable issues such as personality meshes or clashes, leadership
> abilities at hands, methodology used, etc.  All of this is pretty
> obvious, making your assertion that Brooks held otherwise actionable (as
> libel, by Brooks) in many legislations.

Hahaha.

> As it happens, I also have examples in which adding (a few carefully
> selected) people to a software project that WAS (slightly) late put that
> project back on track and made it deliver successfully on schedule.
> Definitely not the "pointy-haired boss" management style of "throwing
> warm bodies at the problem" that Brooks was fighting against, but,
> consider: the project's velocity has suffered because [a] the tech lead
> has his personal (usually phenomenal) productivity hampered by a painful
> condition requiring elective surgery to abate, and [b] nobody on the
> team is really super-experienced in the intricacies of cryptography, yes
> some very subtle cryptographic work turns out to be necessary.  One day,
> the tech lead calls in -- the pain has gotten just too bad, he's going
> for surgery, and will be out of the fray for at least one week.
>
> I still remember with admiration how my Director reacted to the
> emergency: he suspended two other projects, deciding that, if THEIR
> deadlines were broken, that would be a lesser damage to the company than
> if this one slipped any further; and cherrypicked exactly two people --
> one incredibly flexible "jack of all trades" was tasked with getting up
> to speed on the project and becoming the acting TL for it, and an
> excellent cryptography specialist was tasked to dig deep into the
> project's cryptography needs and solve them pronto.
>
> So, We Broke Brooks' Law -- the cryptographer did his magic, and
> meanwhile the JOAT ramped up instantly and took the lead (kudos to the
> Jack's skills, to the clarity and transparency of the previous TL's
> work, to the agile methodologies employed throughout, AND to the
> uniformity of style of one language which will stay unnamed here)... and
> the project delivered on time and within budget.  We had one extra
> person (two "replacements" for one TL's absence), yet it didn't make the
> late software project even later -- it brought it back on track
> perfectly well.
>
> I have many other experiences where _I_ was that JOAT (and slightly
> fewer ones where I was the specialist -- broadly speaking, I'm more of a
> generalist, but, as needs drive, sometimes I do of necessity become the
> specialist in some obscure yet necessary technology... must have
> happened a dozen times over the 30 years of my careers, counting
> graduate school...).
>
> This set of experiences in no way tarnishes the value of Brooks' Law,
> but it does *put it into perspective*: done JUST RIGHT, by sufficiently
> brilliant management, adding A FEW people with exactly the right mix of
> skills and personality to a late software project CAN save the bacon,
>
>
>> Fair enough. But what does Python offer above any garbage-collected
>> language that makes it so scalable?
>
> Uniformity of style, facilitating egoless programming; a strong cultural
> bias for simplicity and clarity, and against cleverness and obscurity;
> "just the right constraints" (well, mostly;-), such as immutability at
> more or less the right spots (FP languages, with _everything_ immutable,
> have an edge there IN THEORY... but in practice, using them most
> effectively requires a rare mindset/skillset, making it hard to "scale
> up" teams due to the extra difficulty of finding the right people).
> 
>
> Alex

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan