Bill Atkins <[EMAIL PROTECTED]> 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? 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. 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 -- http://mail.python.org/mailman/listinfo/python-list