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

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.

---