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.

Comments

The bazaar vs. Brooks' Law?

[Kaufmann]

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

[DragonHawk]

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!

[the way]

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

[amyzing]

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

[mochaone]

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

[dsplat]

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.

Man-month Postulate and Cathedral and Bazaar

[Anonymous Coward]

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 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 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. 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

[YoJ]

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

[Tim Behrendsen]

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.

---