Slashdot Mirror
Fred Brooks wins Turing Award (Nobel of Computing)
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.
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 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
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/
-- The opinions expressed are not necessarily those of the fictional entity who may or may not have expressed them
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
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
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.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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.
Hates people who have stupid little sigs
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.
The net will not be what we demand, but what we make it. Build it well.
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.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
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.
To the editors: your English is as bad as your Perl. Please go back to grade school.
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".
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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).
... 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.
... 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).
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
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
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?
Hates people who have stupid little sigs
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 related to the book. Okay, you have your reading list for the week guys.
The net will not be what we demand, but what we make it. Build it well.
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.
One of the most indefensible ideas of CatB is that Brooks' Law 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):
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:
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 of The Mythical Man-Month:
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. 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 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
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.
---