[EMAIL PROTECTED] (Alex Martelli) writes: > 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?
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 -- http://mail.python.org/mailman/listinfo/python-list