[EMAIL PROTECTED] writes: > Bill Atkins wrote: >> [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. > > 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.
There is another essay in TMM-M that discusses the difference between essential complexity and accidental complexity. You might think Python is really swell, and I might think Common Lisp is really swell, but at the heart of it there is still what Brooks calls "essential complexity" - the difficulty of mapping a complicated real-world situation into a model a computer can handle. So I think using Python or Lisp will help get rid of a lot of the accidental complexity that would arise from using C or C++, but it can only do so much; there is still a lot of complexity involved even in projects that are written in very high-level languages. IMHO. >>> 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. Sure, agreed. > 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. > -- 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