HW8: Mythical Man Month

Mythical Man-Month - Does adding more labor to a project linearly reduce the time to completion? Or does it do the opposite, particularly to an already late project? In his book Mythical Man-Month, by Frederick P. Brooks, Jr., explores this myth in the context of software engineering projects.

Brooks introduces the concept of a man-month as follows: “cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.”

So why, then, aren’t men and months interchangeable? Well, they are in some contexts like picking cotton or folding laundry. That’s because these tasks are, for the most part, performed independently from “co-workers.” Software engineering is a different ballgame.

According to Brooks, this lies in its highly collaborative nature. Sure, software engineers work on tasks independently much of the time. However, it’s crucial for the integrity of the product that engineers communicate regularly with any co-workers whose code communicates with their code. When more people are added to a software project, the complexity of those communications within the team spikes. New hires also require extensive training. Once they’re trained, they add to the tally of hands included day-to-day communications, hands that must be kept in the loop, hands whose work can delay or interfere with the work of others. I watched a really neat video to supplement reading the book which compared this to clinking wine glasses (giving cheers). When there are just a few glasses, everyone can easily reach the other, but when there are dozens, things get…messy. And take much longer.

This brings us to Brooks’s Law: “Adding manpower to a late software project makes it later.” There are sequential constraints (like debugging) that simply cannot be reduced with more hands. When the schedule is already off and you add more labor, this combined with the aforementioned increase in communication complexity gives rise to this law.

Brooks suggests several ways to work with all of this in mind. One that I found particularly interesting - the main focus of chapter three - is the surgical approach proposed by Harlan Mills. In this approach, instead of all team members working on the same problem, one “chief programmer” does the “cutting” while everyone supports him with all the tools he needs. This is called the “surgical approach” because of how important that single, lead set of eyes are in surgery. Imagine if everyone in the operating room was trying to cut at the patient? Not only would there be non one to assist with tools but room for noncohesive cuts would skyrocket.

The main surgeon is equivalent to the chief programmer. He and his copilot oversee all of the code, making sure it falls into the design. This supports something Brooks calls conceptual integrity: keeping the vision of the product pure. He even calls conceptual integrity the most important consideration in system design. To maintain the company “why,” features should reflect one set of design ideas at the cost of omitting certain off-hand features.

Of course, these issues become more and more important as the scale of a project increases - up to, think, Google scale. If it’s possible within the scope of a project to keep a team at ten sharp minds, this is commonly believed the best way to go with the mythical man-month in mind. Fortunately, this applies to our teams for the final project. We’re not building a full-on software project, but these principles apply to other computer science projects as well. With just three people, we haven’t had a hard time keeping everyone on the same page so far. :)

• 2021 11
• 2020 22