The Mythical Man-Month News & Views Book Review

The Mythical Man-Month: Essays on Software Engineering Frederick P. Brooks by Chris Larsen, Principal Consultant Management Process Integrators, Inc. (Scottsdale, Arizona) Originally published in News & Views January 1996 issue. Copyright 1996 STC-Philadelphia Metro Chapter. For permission to reprint this article, contact the Managing Editor.

It's been 20 years since Frederick P. Brooks, Jr. published the classic The Mythical Man-Month: Essays on Software Engineering. In this pragmatic, lucid book, Brooks takes apart many of the project management myths that arose from his significant experience in the then youthful software industry. In particular, he lays into the illusion that throwing more people at a project will hasten its completion. With examples, humor, and solid logic, Brooks shows how such myths actually bring disaster and delay to software projects. You can't interchange time and people His musings apply just as well to the management of documentation projects. How many times have managers who oversee documentation projects thought of shortening a schedule by getting more people? It's an easy fallacy to fall into, but Brooks makes clear the real effects of thinking that people are exactly interchangeable with time. According to Brooks, "more software projects have gone awry for lack of calendar time than all other causes combined." He gives several reasons. First, Brooks blames poor estimating techniques that mistakenly "confuse effort with progress." Because of the uncertainty of the estimate, managers lack the "courteous stubbornness" to stand by what may seem like an overlong timeline to others. When schedules slip, the inclination to apply more manpower kicks in, which is like "dousing fire with gasoline," causing a cycle of regenerating disaster. The foundational error, of course, is assuming that people are exactly interchangeable with time. As Brooks points out, this formula holds true only with projects in which the members have no need to communicate with one another, as in cotton picking. In projects with sequential tasks and dependencies, however, this idea of interchangeability falls apart immediately. "The effort of communication," says Brooks, "must be added to the amount of work to be done. . . Three workers require three times as much pairwise intercommunication as two; four require six times as much as two." The communication time (not to mention training time) sucks up any benefit gained from partitioning tasks to more people. So, what's the answer? Brooks endorses a cure in which product development is carried out by an organizational structure that resembles a surgical team, in which a few experts design and execute the entire core of the project and additional staff support their efforts in specific ways. The only way this can work, according to Brooks, is through achieving "conceptual integrity" in a project from the beginning. The most important expression of such integrity occurs through the specification, "which is a computer manual plus performance specifications. . . one of the first documents generated in proposing a new product, and the last document finished." Documentation is key Brooks goes on to voice eloquent support for documentation, listing the items that users need in order see a map of the forest and not just the trees: a program's purpose, environment, options, logic, "running time," and so forth. And behold: "Most of this document needs to be drafted before the program is written, for it embodies basic planning decisions." As technical communicators, we need to hear more of this kind of support from the engineering side. Although Brooks' context--large programming projects on big-iron computers--has transformed into the distributed computing we know today, Brooks' logic and clear thinking blows away the fog that still threatens to engulf project management.

Return to . . .

[News & Views] [STC-PMC Home] [STC Home Page]
Last updated: November 6, 1996 (wq)