The Mythical Man-Month Ch 1-3

Reference Information
Title: The Mythical Man-Month
Author: Frederick P. Brooks
Publisher: Addison-Wesley

Summary
This reading mostly discussed programming practices by relating them to some fairly well-known concept.

Chapter 1 discussed the concept of a tar pit, relating large-system programming to it. This is justified by saying that the accumulation of many simultaneous, interacting factors in large-system programming increasingly slows the motion of its progress. The transition of program to programming product to programming system to to programming systems product was described. The author then presented both the joys and woes of programming, including its appeal to creativity and the dullness of debugging.

Chapter 2 discussed the Man-Month and just why it is mythical instead of true. The man-month is a trade-off between manpower and months, a unit of effort used for estimating and scheduling, leading one to believe that more man power leads to a shorter programming time. However, the author emphasizes that this is not true, due to sequential constraints. On the contrary, adding more people to a project can actually lengthen the amount of time to complete it, due to time needed for training and restructuring the development process for more team members. The author proposed a rule of thumb for project scheduling (1/3 planning, 1/6 coding, 1/4 component tests, 1/4 system tests of the completed project).

Chapter 3 proposed a new programming team structure, likening it to a surgical team. While smaller, smarter teams are generally preferred, they are impractical for large programming endeavors. However, for a team of 10 people, the surgical team setup is proposed, whereby there is one main programmer (i.e. the surgeon) that does the design and coding. He is supported by a team that consists of a copilot that shares in the design and coding, an administrator that handles managerial type things, an editor that transforms the surgeon's manuscripts into production documents, the clerk that's maintains technical records, two secretaries for helping project correspondence, a toolsmith for creating and maintaining helpful tools, a tester for devising test cases, and a language lawyer for finding unique, efficient ways to use the programming language for tricky things. For larger groups, it was proposed that this team should be enacted, just scaled up and with a coordinator between the main programmers.

An actual surgical team.

Discussion
This book seems to be pretty interesting so far. I like the discussions about programming practices, and the proposed solutions seem like they could be very helpful to keep in mind for managing large programming projects. I found the surgical team analogy to be a little strange, but it does make a kind of sense. I think that many of the suggested solutions to problems that the book discussed could be helpful to implement in future programming projects or even our current capstone project. The scheduling issues and team structure issues in particular seem like they could be very useful to apply.