HW12: Mythical Man Month

+Readings:

>Reflections:

Chapters 1 through 4 of Mythical Man Month by Computer Science Professor Frederick Brooks of the University of North Carolina at Chapel Hill revel in topics ranging from the joys of programming to the challenge of determining what makes a good programmer versus a weak one. The main concept of Chapter 2 is Brooks’ Law of the Mythical Man Month.

A man month, according to Brooks, is a unit of measurement that is often used in software engineering to measure the amount of time a project will take if one person is working on it for a month. Interesting concept - since it depends so much on the actual man (or woman!) themselves. According to the Agile Manifesto, software developers must trust each other to get work done: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” (Agile Manifesto, clause 5). Perhaps this is the kind of worker Brooks refers to in man-month-units. I used to find it hard to just blindly trust that others in the team will get work done without some micromanaging, but I think the last couple of years have taught me that encouraging people to work hard right from the very beginning and setting an example are usually enough to spur self-motivation. 

The Mythical Man Month is mythical, according to Brooks, because it is not a reliable unit of measurement for software engineering. If you have a problem that cannot be solved in one Man Month, adding more men to the project will surely slow it down (Brooks 17). He claims that, because the medium with which we work with is intangible, adding more people to a project does not speed up the process of coming up with a solution (also, is there a spelling error on page 13’s quote or is it just me??). I really enjoyed how Brooks explains the connections between programmers, the medium of software, and how optimistic we are about working through problems:

“The programmer builds from pure thought-stuff: concepts and very flexible representations thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified” (Brooks 16)

I also think the point he makes about our ideas being defective is a good one - because we work with “pure thought-stuff”, we are more likely to introduce errors in our programs because there are errors in our thought processes (especially if you are trying to get an entire team the think the same way). 

Even though Brooks seems to indicate that there are many flaws to software engineering techniques and some of those flaws are actually not correctable (like in Brooks’s No Silver Bullet) nor will ever be correctable, he remains optimistic about our progress. How could you not?? The feats that have been accomplished with software in the last 50 years are magnificent!

I’ll end with a nice quote: “Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists” (Brooks 14). Yes we are!