Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Science

Fred Brooks wins Turing Award (Nobel of Computing) 64

Posted by jimjag from the nice-guys-do-win dept.
pjones writes "Many of us know Fred Brooks from his book, Mythical Man-Month: Essays on Software Engineering, and from his coining of the term "computer architecture." He is also famous for Brook's Law which every manager should learn and be forced to repeat daily. So it's good news to report that Brookes has been awarded the Turing Prize from ACM. Brook also managed the development of the IBM 360 Operating System." I also heartily recommend Computer Architecture: Concepts and Evolution which he co-wrote. An excellent look at how the efforts of the '60s influenced later developments.
This discussion has been archived. No new comments can be posted.

Fred Brooks wins Turing Award (Nobel of Computing) More

Fred Brooks wins Turing Award (Nobel of Computing)

Comments Filter:

  • Re:Let's give him the Turing treatment! (Score:1)

    by Anonymous Coward
    Ah, yes. Homosexuals are "foolish" and "self-destructive". It's nice to know that there are homophobic gun nuts running around loose in our society. Gives me a sort of warm and fuzzy feeling, ya know? Look, you can hate gays as much as you want. That's your business. It's sort of like country clubs that don't let blacks in. We bemoan them and ask what place they serve in an enlightened, civilized society, but at the end of the day, it's their choice. But none of this changes the fact that many of the pioneers of computer science, software, and the open-source movement have in fact been homosexual. If this bothers you, you might want to realign yourself with a more heterosexual-friendly environment, such as the drywall industry (for example).

  • Fred Brooks is a great inspiration to me. (Score:1)

    by Anonymous Coward
    I was lucky enough to take Fred Brooks' graduate software engineering course. I can still hear his charming Southern drawl recounting the timeless lessons of his legendary "Mythical Man Month". Dr Brooks looked the part of the suit wearing, true blue, IBM "big iron" man. But Dr. Brooks was a not so secret Unix fan. Rumor had it that he had his own dedicated channel to the VAXes running unix. He often spoke with great admiration of unix as the new way to do things. He was also very excited about the advances in microprocessors. Congratulations, Dr. Brooks.
  • Seeing how Brooks's writings go against the thinkings of your average Linux zealot ("Throw more hackers at it!"), I find it curious to find this article trumpeted here.
  • I'm afraid I've had a very similiar experience. I've only been looking for one year, though.


  • At first I thought it said that Fred Durst had won the Turing Award.

    Had me pretty scared for a second there.

    Michael Chisari
  • Let's have an end to tiresome political correctness. Turing blabbed his "darkest secret"
    to a pair of bobbies who had come to his house
    to solve a burglary, and subsequently offed himself in a particularly theatrical way that
    there is strong evidence he'd been fascinated with
    since his teens.

    Next time you want a martyr, try to pick one whose
    foolishness and self-destructive streak is less
    obvious.

  • Brooks's Law still applies to free software projects. They just handle it differently. This was the topic of the keynote presentation that Alan Cox gave at the Ottawa Linux Symposium [ottalinuxsymposium.org] last summer. In essence, if I recall it correctly, he said that free software projects work around it by using communication structures quite different than in commercial development.

    Free software projects still tend to have one prime architect who has final say over what goes into the project and what doesn't (e.g. Linux for Linux). These architects tend to be supported by a small team of core developers, an arrangement which recalls the "surgical" team model in MMM.

    The size of project teams is limited by the n-squared communications cost. Cox suggested that the useful limit is about six people. More than that, and they spend more time talking than working. Free software projects tend to live to this limitation by aggressive modularization. Whenever a project gets too big, it fissions into a group of smaller subprojects with well-defined interfaces. He gave the GNOME project as a good example of this, as well as the Linux kernel.

    Free software projects do have a different communication and training style than the commercial development that Brooks focused on. In free software, you're encouraged to contact directly the person who can answer your question, instead of passing messages up and down the management heirarchy to get permission to do so. Training is somewhat reduced, since new contributors are expected to read the source code before jumping in. One method that Cox mentioned was that an experienced developer will give a new contributor some small individual piece to work - in effect, a new subproject.

    Still, as noted elsewhere in this discussion, the biggest advantage free software has in this regard is flexible deadlines. Projects aren't done until they really are done, since there's typically no sales department or management to set a deadline.

    You can listen to the keynote in MP3 at ftp://ftp.ottawalinuxsymposi um.org/ols1999/keynote.mp3 [ottawalinuxsymposium.org].

  • This man is brilliant, intimidating and relentless. He's also one of the coolest professors I've had, so it comes as no surprise that he wins the Turing Award for his momentous contributions to the computer industry.

    I'm looking forward to this coming semester (I'm taking another computer architecture class under him) already. =)
  • "bad spelling and grammar gets on my nerves."
    Then why didn't you get on him for saying "different than" instead of "different from"?
  • Time for a new moderation category "trolling for dollars -3 points"?
  • I was commenting on the editorial, not the man.
  • Perhaps you're right (I don't know, I haven't read the biography but I believe there is some debate on Turing's death), but was it really necessary to be so vitriolic?

    Turing is one of this century's true geniuses. I would prefer to remember Alan Turing for his incredible scientific achievements, and regret his tragically early death (by whatever method), rather than dwell on his probable suicide.

  • I actually submitted the article citing Brooks' Law with the apost. after the s as we do in English, but it was copyedited to the wrong site at /. The link which cites Brooks's Law is not correct English but is not a terrible mistake for a non-native speaker, such as the keeper of that site, to be making.
  • I disagree. I believe OSS wins because it does better at parallizing those tasks that can be parallized, not because it lacks deadlines.

    You should have looked at Cox's argument more before posting this, because he addresses it. He says that free software is "always late", in that it's already not there to do the function that the programmer -- the "leader" -- wants. In this, he accepts wholesale the view (from ESR) that free software always scratches an itch (and, perhaps more contentiously, the programmer's own itch).

  • I am starting to wonder if we are having two different conversations here. :-)

    Well, wouldn't be the first time for me. Now I see. Thanks for the clarification.

  • No offense to Dr. Brooks was intended (I've never met him myself).

    -Nathan Whitehead

  • uh... (Score:1)

    by delmoi ( 26744 )
    Well, I belive the poster was calling ESR both homophobic AND gun-toting. This is not incorect, and does not nessesitate equating the two.

    "Suble Mind control? why do html buttons say submit?",
  • I first read MMM over twenty years ago.

    Since then, I have been looking for any sign that any manager I worked for had even heard of the book. So far, no joy.

    Which is really scary, considering who my present employer is.
  • If OSS is so much better at finding and eliminating bugs then why is Mozilla still a buggy mess that doesn't stay up more than 15 minutes in my normal usage? There is something wrong here. I do not see that 10,000 eyes are better than a dozen unless the 10,000 eyes are we versed in the design and function of the program being examined. I also think that OSS will not go very far without good Open Source Design documentation and practice. Some reverse engineering tools to extract at least some design elements would be a good start. But the source hides too much of the fundamental decisions and considerations governing a project as these have often been factored in in relatively invisible ways by the time implementation is reasonably far along. It is often not easy for even highly skilled programmer/designers to extract design criteria and decisions from raw source. Without a good understanding of the requirements there is no way to certify that a program behaves as it should. Not blowing up is a nice start but only the most coarse measure of correctness.


  • You misquote me. I said that I don't believe Open Source will go far without also including open source design documentation. I brought up a point worth considering about how far the source code alone can take us. Instead of responding to the point you chose to take it out of context.

    I said nothing about formal proofs of correctness. I merely point out that it is difficult to impossible to program and debug well without good specifications of what the program should do. This is surely a perfectly straight-forward point. Well not so surely since in my 20 years of software engineering (although I think we often should not call it that) I've certainly run into a lot of folks (including myself at sometimes) who don't get that at all.

    Can I ask when Mozilla will be done? And exactly why do we make browsers so complex that they may be arguably more complicated than the Linux kernel as was claimed? Is this a sign of something being more than slightly out of kilter?
  • If you're in Canada, or feel like spending $CDN just for fun, here's a couple of his books at chapters.ca:

    Mythi cal Man Month [chapters.ca]

    Compu ter Architecture (Vol 1) [chapters.ca]

    Just FYI, I already have em both... :)

  • Ok, who else noted the affiliate ID in the links this person gave? You don't suppose that the poster will get commission if you buy the books by clicking the links, do you?

    It's an interesting idea, making money by providing useful links.

    However, something tells me it should be discouraged on Slashdot, or else all we'll see will be people posting links to any product they think is vaguely connected to a post. I wonder how many affiliated links were posted to the Lego Mindstorm articles...

  • The best thing about the book is that some of the things mentioned seem so obvious ONCE you've read it. It's like the on-the-tip-of-the-tongue feeling (for me, atleast).
  • The apostrophes are in the wrong place.

    The man's name is "Fred Brooks", and it is his law... therefore, the apostrophe should come after the "s". (i.e., it is "Brooks' Law" or "Brooks's Law".)

    In fact, TNHD defines it as... Brooks's Law. (Follow the link on the page.)

    Sorry about a flame over a technicality, but bad spelling and grammar gets on my nerves.
  • I believe that the award to Dr Brooks was long overdue. He was a pioneering force behind the modernisation of computer technology.

    I believe that we are uncosciously honouring there brilliance, commitment and dedication everytime we use a computer today. That, I think is the greatest honour, a far greater honour than any award one can receive.

    Here [acm.org] is a list of other great people who were honoured with the A. M. Turing award

  • Definitely agree, I had Brooks for Advanced Computer Architecture. He gave you a real feel for why certain bottlenecks in Computer Architectures exist and how to find them. Another First for Brooks from what I understand was he started the first Computer Science Program, prior to that point Comp-Sci was taught primarily in Math Departments.

  • Re:Turing Test Award (Score:2)

    by Anonymous Coward
    Oh, tsk, tsk. Lack of social skills? Hardly. :)

    Dr. Brooks is the quintessential Southern gentleman... he's the founder and still head of the CS dept here at UNC, and it's been my pleasure to have taken several classes from him, ranging from Advanced Architecture Design (where we got to be the guinea pigs for the text that became Computer Architecture - only class I've ever used APL in) to Professional Ethics and one in Academic Teaching.

    Truly one of the Good People on this planet.

    -Jason Smith (who is too lazy to fix the problems with his /. account)

  • Let's give him the Turing treatment! (Score:2)

    by Anonymous Coward
    Let's have his government play off his darkest secret, break him down & kill him...uh, I mean drive him to suicide...yeah, that's it.
  • "Brook also managed the development of the IBM 360 Operating System."

    Note that while manager of the 360 project it was Dr. Brooks who specified that a byte would consist of 8 bits. Whether or not you agree with his decision, it's hard to argue that this has not had a huge impact on the computer field.

    Tanner Lovelace
    UNC Chapel Hill
  • Hi there;

    I actually wrote an (albeit crappy) essay on the topic of wether Bazaars obeyed Brooks' Law or not. Or, more accurately, wether they obeyed the Law of Diminishing Returns.

    I submitted it to Slashdot ... but I'm not ESR, now am I :)

    Check it out at:

    http://www.kanga.nu/~claw/docs/extess/ [kanga.nu]

  • Seriously.

    Until you have read The Mythical Man Month you won't understand why things keep on not working out. You won't understand why Microsoft can throw thousands of programmers at something and come out with a POS. You won't understand why the quality of Open Source shocked Eric Raymond. And you won't appreciate Eric Raymond's "loophole" to Brooks law - primary development does not scale, debugging does.

    Seriously, if you want to understand how this industry works, read this books. Then start reading other classics like Code Complete. They are classic for a reason, and if you think that you know it but you have not read them, odds are you probably don't really know it...

    Cheers,
    Ben
  • It's always indicative when someone resorts to the tired rhetorical device of complaining about "political correctness." In this case, your interpretation of the circumstances of Turing's demise is speculative, Eric. See for example this exchange [sciam.com] in the letters section of a recent Scientific American. There is no disputing, however, the persecution he was subjected to by the British authorities, which may or may not have had a direct bearing on his death.

    But all this is aside from the main point, which is Turing's indisputable professional and scientific contributions. That is where the emphasis should properly be placed.

    --------
  • If OSS is so much better at finding and eliminating bugs then why is Mozilla still a buggy mess that doesn't stay up more than 15 minutes in my normal usage?

    Because Mozilla is not done yet. I never stated that OSS was a cure-all -- indeed, I pointed out it most certainly is not. No matter what development methods you use, implementing the requirements of the Mozilla project is a huge job, arguably much more complex then the Linux kernel. Linux is almost ten years old; Mozilla is barely two. Do you expect miracles?

    I wouldn't call Mozilla a buggy mess, either. Progress in Mozilla has been quite dramatic lately, and bugs are being found and fixed at a rapid rate.

    I also think that OSS will not go very far...

    Perhaps you haven't noticed, but it already has gone quite far.

    Without a good understanding of the requirements there is no way to certify that a program behaves as it should.

    OSS typically focuses on more informal measures of testing, rather then formal proofs of correctness. OSS is hardly alone in that respect. Most widely distributed software is more concerned about getting the job done then satisfying the criteria assigned by a third-year CS professor.
  • Me: I disagree. I believe OSS wins because it does better at parallizing those tasks that can be parallized, not because it lacks deadlines.

    You: You should have looked at Cox's argument more before posting this, because he addresses it. He says that free software is "always late", in that it's already not there to do the function that the programmer -- the "leader" -- wants.

    I am starting to wonder if we are having two different conversations here. :-)

    I still don't think this is invalidating Brooks's Law in any way, shape, or form. If 500 developers all decide they want to implement the printf() library from scratch, I am pretty sure you are going to see a mess, no matter how they work together, or how badly they itch to do so.

    In the context of Brooks's Law, OSS works mainly because it finds the areas where the Law doesn't apply (i.e., testing and debugging, mainly), and distributes the workload there. Additionally, the lack of pressure from outside the development team keep Brooks's Law from coming into play (no manager to throw 10 new programmers your way).

    The key here is, Brooks's Law is as potent as ever -- Open Source development finds ways to work around it that closed source development cannot use.
  • I said that I don't believe Open Source will go far without also including open source design documentation.

    I've wondered the same, but various projects seem to be show that you can have a working system without design documentation. It flys in the face of conventional software engineering wisdom, true, but it works.

    I have done a little thinking and asking here, and have determined the following: The people doing the hacking seem to know where they are going intuitively. Mailing list discussions contain not only the design goals reached, but the decision-making process that lead up to it. OSS projects start out small, with a few developers, and grow exponentially as design goals become more obvious and modularization increases. It all seems very haphazard, but it does seem to work.

    There is also no rule that says you cannot establish requirements, engineer a design, and then develop everything, all in an Open Source manner. However, it seems that the fewer people involved in those early stages, the better. Otherwise, you spend too much time fighting over which way the inevitable design trade-offs are going to go.

    Can I ask when Mozilla will be done?

    As I am fond of saying: Software is never done, it is only released. OSS does well because it not only accepts this, but embraces it.

    And exactly why do we make browsers so complex that they may be arguably more complicated than the Linux kernel as was claimed?

    The reason is that the browsing experience we have come to know and love is very high cohesion phenomenon. That is a fancy way of saying all the pieces of the browser get caught up in each other. An OS kernel is a fairly modularizable thing. Not so for a browser.

    Of course, the requirement to have the mail and news functions done before the core browser can be released is slowing things down. That was the way they wanted to do things, and I'm not going to attack them for it at this point. :-)
  • Still, as noted elsewhere in this discussion, the biggest advantage free software has in this regard is flexible deadlines. Projects aren't done until they really are done, since there's typically no sales department or management to set a deadline.

    I disagree. I believe OSS wins because it does better at parallizing those tasks that can be parallized, not because it lacks deadlines.

    In most cases, the deadlines are self-imposed and easily movable, but that does not make Brooks's Law invalid. If Linus wants Linux 2.4 to be out next week, throwing 50 more people at him is going to make things worse. Just because we can say "Oh, well, we didn't make the deadline, no big deal" does not mean the deadline was not missed.

    If a project really doesn't have a deadline, then throwing more people at it is still going to slow it down. You just don't have as obvious a yard stick to measure it with.

    It is true that, because OSS projects usually don't have unrealistic pressure from sales and management, there is no temptation to throw more programmers at them to meet an arbitrary deadline. This just means OSS developers understand Brooks's law, and don't try to fight it. It is still there.
  • I agree with a lot of what you've said. I just hope that people become more knowledgable about how Open Source really works so they can temper their expectations accordingly. Mozilla has garnerned a lot of negative news because of the delay in putting out a product (regardless of the fact that they had to start over with a new code base midway through the project), jwz quitting on them and casting his own negative cloud over the project, etc. Future projects will suffer the same negative perceptions if the reality of Open Source isn't promulgated correctly.

  • You were quoting me out of context on that. I wasn't saying that open source is going to take over the world this year. I was saying that if the premises of Extreme Programming and the analysis of what makes open source tick that Eric Raymond and Karl Fogel have done are correct, then open source will outstrip the competition in the long run. Something I didn't state, and I should rightly be criticized for, as you did, is that it will only happen in games where open source projects are actually playing. That said, I am not certain that all open source projects live up to the ideal Raymond and Fogel have described.
  • When people say that Brook's Law and Open Source are somehow in opposition, they haven't really read MMM:

    1) "The best cure for any project is time", or something to that effect. Open Source projects are not subject to an arbitrary ship date, so they can take whatever time needed to get it right.

    2) Testing *is* an easily parallelized task, and since Brooks advocates devoting a full third of the project schedule to it, an Open Source project can make up a lot of time here.

    3) As you point out above, it's usually a small core of people who do the most work on a given project -- but they are almost invariably the *right* people. Due to the open nature of the process, talent and skill (and interest) can flow to where the need is. In contrast, a commercial company probably wouldn't reassign a programmer until there was a recognized problem. Of course, (1) they would have to recognize the problem, (2) know who the right programmers are, and (3) the programmers would have to get up to speed, since they wouldn't likely have prior access to the source.

    I don't think Open Source projects are immune, but *nix systems have the advantage of being composed of a lot of small applications with well documented interfaces rather than a few large ones. The Linux kernel, Apache, and Perl are all of a manageable size, while a single large app like Mozilla arguably has some problems.

  • Sorry for the grammatical mistakes. Typing too fast; skipped the preview ("ahh, it's probably OK"). :)


    ---

  • From the article:

    "Brooks will be cited for his landmark contributions to computer architecture, operating systems and software engineering -- contributions that have stood the test of time and shaped the way people think about computing, the association said in announcing Brooks' selection."

    Was there an actual point you wanted to make?

    ---

  • I don't if that was meant to be funny or not but if it wasn't please read the 20th anniversary edition of Mythical Man Month and you'll realize that this man deserves all the writing awards we can give him.
    Mythical Man Month should be required reading for every software manager and developer because it points out the fallacies in our reasoning that we are too blind to see as coders and gives good ideas on how to manage real software projects.

    PS: He didn't actually win a Nobel award. He won the Turing award which is unofficially regarded by most as the Nobel award for computing.
  • It's kind of nice when truly prestigous awards (like the Turing, unlike the Oscars) get awarded to people who deserve them (like the Turing winners, unlike the Oscar winners).

    My hat is off to the man. As someone who used to work in a protein engineering lab, I was surprised to find that, "Brooks and his students built the first molecular graphics system on which a new protein structure was solved." This effectively makes him a pioneer in (at least!) two fields.

  • Yeah, I hate that. I do that sometimes and always seem to regret it :)

  • A few people have asked something along the lines of "doesn't Brooks' Law invalidate Bazaar-style development?" At first, it may seem that way - one of the basic tenets upon which it's based is "given enough eyes, all bugs are shallow". So could it be that the bazaar doesn't work at all - that maybe the cathedral is the right model after all?

    I say not. First of all, one must recognize the difference between the "bazaar" of interested hackers contributing over the Internet in an informal environment, and the "human wave" of countless corporate programmers that characterizes corporate development.

    Basically, my point is that what the bazaar is about is not sheer number of developers - even in the most developer-friendly projects, there is usually a shortage of competent developers. It's about openness - allowing other people free access to your code. Corporate human-wave projects, by contrast, abound with NDAs and trade secrets; in a closed environment, Brooks' Law applies strongly and projects with developer overkill tend to go down the drain. But bazaar-style projects suffer less from it - behold Linux, Apache, Perl and other projects that, while open (both in the sense of free code and of welcoming new developers) tend to have a well-defined developer core and a well-organized working scheme.

  • Open Source and Brooks's Law (Score:3)

    by DragonHawk ( 21256 ) on Saturday January 08, 2000 @01:29PM (#1390853) Homepage Journal
    It is ironic that Brook's law seems to take a lot of starch out of the percieved benefits of open sourcing a project, especially a project that already has had a head start.

    Actually, one of the points Eric Raymond makes in favor of Open Source Software is that OSS helps reduce the limitations of Brooks's Law.

    Brooks's Law says: Adding manpower to a late software project makes it later. This is often stated more formally as: Programmer time is not fungible. If a program takes one programmer one day to write, it does not nessicarily follow that two programmers can do the job in half the time.

    Mr. Brooks makes the observation that, in matters of programming, which is essentially codifying thought, the overhead of communication is very significant. Two cotton-pickers can pick twice as much cotton because they can work on separate parts of the field, but a program module can only be worked on by one designer.

    Eric Raymond has observed that testing and debugging is fungible. "Given enough eyeballs, all bugs are shallow." With a couple hundred people looking at the code, testing it, and tracking down and fixing bugs, you can reduce test time dramatically. Since Brooks also observed that test time is often the single largest task out of the total time you need to devote to a project's development, this is very significant.

    OSS still needs a central coordinator for each module. Someone to handle the design and make decisions as to what code gets accepted and what gets rejected. Take Linux: Linus Torvalds and Alan Cox spend as much, if not more, time filtering patches and making design decisions as they do writing code. But OSS allows the actual work of testing and fixing to be done by others.

    OSS is not a cure-all. It hardly scales perfectly, but it does scale better then closed development does.

    Oh, and BTW, it is "Brooks", with an "S" on the end. Not "Brook". :-)

  • Re:Let's give him the Turing treatment! (Score:3)

    by the way ( 22503 ) on Saturday January 08, 2000 @01:27PM (#1390854)
    I think you're being a little unfair. I don't think it's that hard to see how Turing's situation could lead to poor judgement.

    His great work (along with that of Flowers) was a major contributor to the Allies' war success (look at the Allies losses after the Germans upgraded from the Enigma machine if you don't believe this). And yet, he could never speak a word of this to anyone due to the secrecy that remained until the 70's.

    During his trial (he was charged with being homosexual, for those that don't know) his record as a war hero, I believe, would have allowed him to get off all charges. But no-one spoke up.

    Furthermore, he suffered from a stutter which caused those who didn't know who he was to not take him seriously.

    What would it be like to be a genius and war hero who was only known to most of your countrymen as an immoral freak? I'm not sure it's so clear that he had a 'self-destructive streak'... and he was certainly no fool (although he was, no doubt, eccentric).

    But all this aside, how does he fit as a martyr, particularly for geeks? He is responsible for starting our revolution. Along with Godel, he developed the foundation of our understanding of computation. He had the belief in the ability of computers to do more than 'just compute', that caused people to rethink their assumptions about the role of computers in the world. He worked hard for the public good, and achieved much. Despite all this, he was trodden down by the institutions for something that most now believe is not criminal, and not a personal choice.

    Try and remember how you felt in your darkest and loneliest hour. Life can be difficult, and we do not always act rationally in such situations. We should not judge Turing's life and impact on just the most 'theatrical' events.

  • Re:Man-month Postulate and Cathedral and Bazaar (Score:3)

    by amyzing ( 45302 ) on Saturday January 08, 2000 @09:09PM (#1390855)
    Hmmm. Interesting and well-considered comment, but some of the quotes, at least, are more than a bit skewed (well, quoting the Halloween document's criticism of open-source initiative is almost funny).

    Specifically, in response to the quote that attempts to explain Brooks in simpler terms, there is an implicit flaw--while these projects might take one programmer 12 months, but would not be completed in one month if twelve programmers were assigned, it might be the case that two could finish in six months, or that three could finish in four. One programmer might not be the ideal number for the project. In fact, more programmers might even finish more quickly, depending upon how the project fits into other releases with which it must be coordinated.

    The open source paradigm adds programmers where parallelism is possible. To break things down, it's design, code, test, fix ... design isn't easily divisible (at least the large-scale ought to be done by one person; the module designs might be done by as many people as there are programmers, but there's some loss there for coordination, and adding more programmers than there are modules immediately invokes Brooks' Law, which is really about the fact that once all the slots are filled, extra manpower is overhead, not advantage). Depending on the design, modules might be coded by more than one person, and *certainly* testing and fixing can be parallelized efficiently.

    The ability of open source to test massively is both one of its greatest time savers (more on the order of: open source code is typically higher quality, because it's been tested more thoroughly, including broader code and design reviews) and one of the things that leverages initiative, in direct contradiction of Halloween I. Win2K isn't likely to have IPv6; Linux does. There are a multitude of other examples; for any given computer-use problem, there is probably a standards-based, well-tested open source solution that is going to be more effective than a proprietary solution. IRC is going to spearhead the whole concept of live chat years before vendors implement their own solutions (which is not to claim that IRC is that much better; IRC 2, though, is likely to be--IRC is the one thrown away, but the proprietary folks haven't managed to learn from its mistakes).

    Where open source tends to fall down is not in lack of innovation, but in a failure to achieve the same level of limited function and high glitz as proprietary solutions. In cooking terms, open source is nutritionally balanced, tasty, digestible, and healthy, but poorly presented; proprietary is fast food, with extreme good looks and little value as nutrition (and probably a somewhat chemical aftertaste as well).

    Mind, Brooks is my *hero*, and I have an autographed copy; I think MMM is brilliant. But he doesn't argue that only one programmer should ever be assigned to a project, and I believe that there is less contradiction between the open source model and Brooks' Law than ESR argues in CatB. Where open source shines is in the testing and revision cycle (and in the ownership of the code by programmers, not by managers ... if someone in charge of a module doesn't get anything useful from an extra programmer, she can ignore him; in a managed software development cycle, everyone has to justify their paychecks, possibly by reducing someone else's productivity noisily).

  • Re:The Mythical Man Month (Score:3)

    by mochaone ( 59034 ) on Saturday January 08, 2000 @11:52AM (#1390856)
    I guess the people who started the Mozilla project weren't aware of Brook's law.


    It is ironic that Brook's law seems to take a lot of starch out of the percieved benefits of open sourcing a project, especially a project that already has had a head start. We're seeing a lot of companies throwing code on the altar of Open Source but I wonder, based on Brook's law, if much will come out of it. Will we be relegated to a bunch of projects running late like Mozilla?

  • Some things are relearned by every generation (Score:3)

    by dsplat ( 73054 ) on Saturday January 08, 2000 @12:15PM (#1390857)
    Brooks pointed out the problem of setting arbitrary limits on a particular programmer's code in Mythical Man Month. He was talking about setting limits on size primarily. And he noted that they caught programmers "throwing things over the fence" into somebody else's code. Now I am reading the newly published Extreme Programming Explained by Kent Beck. He describes a fear of touching another programmer's code as a factor in slowing down many projects.

    By the way, it is worth comparing Extreme Programming with Eric Raymond's comments in The Cathedral and the Bazaar and Karl Fogel's in his new book Open Source Development with CVS. If Beck is right that Extreme Programming can flatten the cost curve on changes over time from exponential to logarithmic, and if he is right about the essential characteristics that make Extreme Programming work, then the open source community beat him to it. It would be a sure indicator that open source is going to outstrip everything else in the long run. It is worth the effort to read Marc Stiegler's book Earthweb too for a view of how realtime online collaboration could potentially reduce turn-around time on many activities. He has a web site [the-earthweb.com] related to the book. Okay, you have your reading list for the week guys.

  • Man-month Postulate and Cathedral and Bazaar (Score:4)

    by Anonymous Coward on Saturday January 08, 2000 @06:04PM (#1390858)

    From A Second Look at the Cathedral and Bazaar by Nikolai Bezroukov, First Monday, volume 4, number 12 (December 1999) http://firstmonday.org/issues/issue4_12/bezroukov/ index.html

    Brooks' Law does not apply to Internet-based distributed development.

    "The most common lie is that with which one lies to oneself; lying to others is relatively an exception."

    - Fredrich Nietzsche

    One of the most indefensible ideas of CatB is that Brooks' Law [softpanorama.org] is non-applicable in the Internet-based distributed development environment as exemplified by Linux. From CatB (Italics in quotes are mine; original italics, if any, are bold italics):

    "In
    The Mythical Man-Month, Fred Brooks observed that programmer time is not fungible; adding developers to a late software project makes it later. He argued that the complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly. This claim has since become known as "Brooks's Law" and is widely regarded as a truism. But if Brooks's Law were the whole picture, Linux would be impossible."

    This belief that programmer time scales differently as soon as programmers are connected to the Internet and are working on open source projects is repeated elsewhere in a different form:

    "Perhaps in the end the
    open-source culture will triumph not because cooperation is morally right or software "hoarding" is morally wrong (assuming you believe the latter, which neither Linus nor I do), but simply because the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem."

    First I would like to stress that the famous book The Mythical Man-Month has acquired the status of a classic in the software engineering field. The book is definitely, by several orders of magnitude, more important than CatB; this critique will not harm the book. Many other concepts, phrases and even chapter titles from that famous book have become part of software engineering terminology. I can mention "the second-system effect", "ten pounds in a five-pound sack", "plan to throw one away", "How does a project get to be a year late?...one day at a time". In the early 60s while working as a project manager of Operating System/360 (OS/360), Frederick Brooks observed the diminishing output of multiple developers and that the man-month concept is but a myth. It is as true in 1999 as it was in 1975 when the book was first published.

    The real problem with the CatB statement is that due to the popularity of CatB this statement could discourage OSS community from reading and studying The Mythical Man-Month, one of the few computer science books that has remained current decades after its initial publication. Actually the term "Brooks' Law" is usually formulated as "Adding manpower to a late software project makes it later". The term "mythical man-month" (or "mythical man-month concept") is usually used to identify the concept of diminishing output of multiple developers even if all work on a given project from the very start. One of the best explanations of this concept was given by Ray Duncan in his Dr. Dobbs review [ercb.com] of The Mythical Man-Month:

    "What is a mythical man-month anyway? Consider a moderately complex software application from the early microcomputer era, such as the primordial version of Lotus 1-2-3, Ashton-Tate dBASE, or Wordstar. Assume that such a program might take one very smart, highly-motivated, expert programmer approximately a year to design, code, debug, and document. In other words, 12 man-months. Imagine that market pressures are such that we want to get the program finished in a month, rather than a year. What is the solution? You might say, "get 12 experienced coders, divide up the work, let them all flog away for one month, and the problem will be solved. It's still 12 man-months, right?

    Alas, time cannot be warped so easily. Dr. Brooks observed that man-months are not - so to speak - factorable, associative, or commutative. 1 programmer * 12 months does not equal 12 programmers * 1 month. The performance of programming teams, in other words, does not "scale" in a linear fashion any more than the performance of multi-processor computer systems. He found, in fact, that when you throw additional programmers at a project that is late, you are only likely to make it more late. The way to get a project back on schedule is to remove promised-but-not-yet-completed features, rather than multiplying worker bees.

    When you stop to think about it, this phenomenon is easy to understand. There is inescapable overhead to yoking up programmers in parallel. The members of the team must "waste time" attending meetings, drafting project plans, exchanging EMAIL, negotiating interfaces, enduring performance reviews, and so on. In any team of more than a few people, at least one member will be dedicated to "supervising" the others, while another member will be devoted to housekeeping functions such as managing builds, updating Gantt charts, and coordinating everyone's calendar. At Microsoft, there's at least one team member that just designs T-shirts for the rest of the team to wear. And as the team grows, there is a combinatorial explosion such that the percentage of effort devoted to communication and administration becomes larger and larger."

    Most top-level software professionals are more like artists, in spite of the technical nature of their specialty. It is not a coincidence that another classic book on programming is entitled The Art of Computer Programming. [softpanorama.org] Communication, personality and political problems definitely creep into any project, as any manager of a sizable programming project can attest. These problems certainly drag productivity down.

    It's simply naive to assume that for the same team Internet connectivity can improve performance in comparison with, say, LAN connectivity or using the same mainframe. Moreover, if we are assume the same level of developers, geographically compact teams will always have an edge over distributed Internet-connected teams. Open source uses the Internet to connect a geographically distributed pool of talent. In turn, it potentially raises the quality of that pool in the absence of geographical barriers. Reducing the effects of distance does not eliminate other constraints under which such projects operate, but can dramatically increase the quality of the pool of developers. That's the only advantage that I see.

    I believe that the illusion of the non-applicability of "mythical man-month postulate" and Brooks' law is limited only to projects for which a fully functional prototype already exists and most or all architectural problems are solved. This may have been the case for Linux, which is essentially an open source re-implementation of Unix. With some reservations, it is probably applicable for all systems for which both the specification (Posix in case of Linux) and reference implementation (say FreeBSD or Solaris) already exist and are available to all developers. As was pointed out in the Halloween-I document:

    "The easiest way to get coordinated behavior from a large, semi-organized mob is to point them at a known target. Having the taillights provides concreteness to a fuzzy vision. In such situations, having a taillight to follow is a proxy for having strong central leadership. Of course, once this implicit organizing principle is no longer available (once a project has achieved "parity" with the state-of-the-art), the level of management necessary to push towards new frontiers becomes massive. This is possibly the single most interesting hurdle to face the Linux community now that they've achieved parity with the state of the art in UNIX in any respects."

  • Turing Test Award (Score:5)

    by YoJ ( 20860 ) on Saturday January 08, 2000 @11:15AM (#1390859) Journal
    Jan. 8, 2000 - The ACM has just announced that the emminent computer scientist Fred Brooks has won the Turing Test Award. Alan Turing is the originator of the celebrated "Turing test" in which a judge must distinguish between a computer program and a real human being.

    The actual test took place last week, with Donald Knuth playing the role of the judge. After 10 grueling hours of questioning, Knuth declared that Fred Brooks was virtually indistinguishable from a computer program.

    "It gives me great pleasure to accept this award on behalf of computer scientists everywhere. /* Fix up speech here, add some thank-you's and stuff. Re-check grammar. */," said Dr. Brooks on being presented with his prize. "I have always had a knack for fast arithmetic, and a lifetime of dealing with computers has made me doubt if I was human myself." Some members of the press commented that Dr. Brook's lack of social skills couldn't have hurt his chances either.

    Fred Brooks is the first human to legitimately pass the Turing test. Last month a man known only as HemostheRobotMan claimed to have passed the Turing test, but was later disqualified after he was found using a Palm Pilot hidden in his shorts. Fred Brooks caused a stir when he said, "I need to change my batteries." It turns out he was merely hungry.

    -Nathan Whitehead

  • The Mythical Man Month (Score:5)

    by Tim Behrendsen ( 89573 ) on Saturday January 08, 2000 @10:46AM (#1390860)

    I remember when I first read MMM about 8 years ago. I was totally blown away. Finally, here was a guy who truly understood and put into words all the problems I had experience while developing software.

    Why is it so hard? Why is there no silver bullet? Why can't you predict how long software will take to develop? Why does adding manpower to a late software project make it later? (yes, he coined that phrase). The book answers these questions and more.

    Probably the biggest insight I took from the book is that the what kills timelines software projects more than anything else is communication overhead. Reducing the communication requirements between groups working on software is the single most important thing you can do during software development.

    If you haven't read this book, get it now (particularly the new 20th anniversary edition, released several years ago). It's not perfect; some of his examples are dated (it's from 20+ years ago) and even he admits some of the ideas have not panned out. But anyone who has developed large software projects with large groups of people will find themselves nodding "Yes! Yes!" more often then not.


    ---

Slashdot Top Deals

Parts that positively cannot be assembled in improper order will be.

Close