[EMAIL PROTECTED] 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. His thesis is that adding programmers to an already-in-progress project will cause a delay, because the new programmers must be brought up to speed. It does not matter if the project is eight weeks late or has only been active for a month. This issue still remains: The two new men, however competent and however quickly trained, will require training in the task by one of the experienced men. If this takes a month, 3 man-months will have been devoted to work not in the original estimate. (p. 24, TMM-M) Brooks's Law mentions only late projects, but the rest of his discussion applies to adding programmers in the middle of *any* project. Is this really so radical an idea? > 2. There has to be a mechanism where an organization can add > developers - even if it is only for new projects. Python advocates Obviously. > would say that getting developers up to speed on Python is easy > because: > > - it fits most programmers brains i.e. it is similar enough to > languages that most programmers have experience with and the > differences are usually perceived to beneficial (exception: > people from a Java/C/C++ background often perceive dynamic > typing as a misfeature and have to struggle with it) > - the language is small and simple > - "magic" is somewhat frowned upon in the Python community i.e. > most code can be taken at face value without needing to learn a > framework, mini-language, etc. (but I think that the Python > community could do better on this point) These are not things I look for in a programming language. > > I'm sure that smarter people can think of more points. > >> Fair enough. But what does Python offer above any garbage-collected >> language that makes it so scalable? > > See above point - you can more easily bring programmers online in your > organization because most programmers find Python easily learnable. > And, as a bonus, it is actually a pretty flexible, powerful language. > > Cheers, > Brian > -- 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
