The Mythical Man-Month Ch 7-9

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
Chapter 7 discussed the Tower of Babel, linking it to how communication is pivotal to programming projects. Lack of communication and organization often causes large projects to fail. It is suggested that teams should communicate informally to interpret documents, though regular project meetings, and through a workbook. The project workbook is a structure that's imposed on all documents that are produced for the project, ensuring a formal structure and control of distribution. Each programmer should be allowed to see all information with timely updating.

Organization is used to reduce the amount of communication and coordination required, and often consists of a tree-like structure of authority and responsibility. To be effective, each sub-tree needs a mission, producer (assembles team, divides work, establishes the schedule, and communications outside of the team), technical director (conceives design and sketches internal structure), schedule, and interface definitions between the parts.

A tree-like organization of authority and responsibility. Source: support.novell.com

Chapter 8 discussed actual data regarding the estimating of tasks. Effort was described as a power of size and given a quantifiable equation. Finally, various data were discussed, including Portman's data (each job takes twice as long as expected), Aron's data regarding programmer productivity on large systems, Harr's data (productivity falls into two categories: control programs at about 600 words/man-year and language translators at about 2200 words/man-year), OS/360 data that confirmed Harr's data, and Corbato's data (data is comparable in terms of the kind of effort included). By looking at these various estimation data, two major conclusions were made: 1) productivity seems constant in terms of elementary statements, and 2) programming productivity may be increased by 5 times when a high-level language is used.

Finally, chapter 9 discussed how space, cost, size, and time factor into a programming project. Size control is very important, as unnecessary size can be bad. As for space, more function of the program results in more space, but function must be traded for size. This limits the range of functionality. Also, there are space-time trade-offs, whereby more space results in a faster program. Finally, the author emphasizes that representation of data or tables is a must, insisting that it will save time.


Discussion
These chapters brought up some very interesting ideas. For one, I agree that communication and organization are  necessary for a successful project, as many people have to be able to work together to meet a single goal: releasing a unified, working product on time. Therefore, constant communication should be maintained. The data of estimation that was discussed seemed rather dull and uninteresting, but the conclusions that the data led to seem like they could be put to good use. Even the trade-offs discussed in chapter 9 could be useful, so that programmers and designers can keep in mind what should be limited when designing a product