HW12: Mythical Man Month

            I found Brooks’ detailing of what he calls the “joys of the craft” to be quite relatable because I’ve experienced what he talked about in all of my programming classes so far, especially the section about the “sheer joy of making things.” I had never programmed anything before attending college, so when I successfully coded my first Python program I felt excited, and it’s satisfying now to be able to look back and see how my programming skills have evolved over time. I also found his section about the “woes of the craft” to be spot on with what I have gone through in my programming classes. Having no prior experience in programming, the learning curve for me was steep. There have been times where I understood a concept immediately and implemented it in a program and times where I stayed up late into the morning trying to comprehend something. For me, the labor certainly has been painstakingly tedious at times, but as Brooks states, “the joys far outweigh the woes.”

            The first thing Brooks states in his second chapter is the reason that most software projects are impaired is because of lack of calendar time. He then provides five reasons that he believes are the causes of disastrous programming. Of the reasons provided, the one that stands out most is the belief that adding manpower when a schedule slip occurs will make matters worse. I found this to be quite baffling at first, as so far I have worked quite well in the teams I’ve been a part of, both assigned and voluntary. One would think that more people working on a project would mean that a project gets finished faster. However, although it seems like a natural reaction to add more members to a team when work falls behind, I can see the reasoning behind Brooks’ assertion. So far in this semester, we have learned about communication failures leading to disastrous results in software design. Brooks’ analogy of adding more people to a project being like adding gasoline to a fire seems accurate. People are flawed, and the more people there are working together, the more likely something will not be properly communicated.

            Considering the points made regarding excess manpower being detrimental to a project, it stands to reason that Harlan Mills’ notion of a “surgical team” is a candid response to the natural response of falling behind schedule. His analogy of having ten people assigned to one team with a hierarchy of job responsibilities is similar to the pair programming in the lab of the first programming class I took. From what I have experienced, tracking and managing a workload is far easier when the work is divided among group members and everyone has a specialized role rather than everyone doing a portion of everything, as more minds working on a single role will likely lead to a communication failure.

            Brooks makes the assertion that a programming team is like an aristocracy, not a democracy. He states that either one or very few minds must dictate the design of a system to maintain conceptual integrity. I agree with the points that Brooks has made in that projects will be better off with members operating as a sort of surgical team with specialized roles to minimize errors in communication.