HW12: Mythical Man Month

MMM

The Mythical Man Month, written by Frederick P. Brooks in the mid 70’s, gets straight to the heart of flaws in the way people then, and to some degree now, may think about software development.  Much like his No Silver Bullet, Brooks uses colorful language and analogies to describe the development process and its flaws. The term tar pit still evokes an image of floundering dinosaurs in their “mortal struggle” and Brooks uses this term to describe the current state of large-system programming; teams struggling to meet deadlines, budgets, goals. The five reasons Brooks outlines as causes for these failings are poorly developed estimating techniques, assumptions about manpower and months being interchangeable, lack of stubbornness, bad schedules, and poor responses to schedule slippage.

Approximate?

Admittedly, I have put little thought into the development process in large scale efforts of software engineering despite having been involved in non-software related government projects for things such as buildings or robotics platforms. So common were the delayed acceptance dates of these things that it seemed like the standard thought process was something like, ‘if the estimated date of completion is 1 year, plan for 2 and believe 3 is still probable’. The most common reasons given for these delays were manpower and budget or some combination of the two. While part of my experience is undoubtedly related to working with the government, from what I’ve come to understand, these types of delays are not uncommon and they seem to be ‘baked into the cake’, so to speak. Apparently, the process is complicated.

Manpower & Teams

Figures from Mythical Man Month
article from PC Mag Vol 2, Num 4, 1983

While all of these were interesting to read about, manpower and months being interchangeable was what really piqued my interest. I have worked extensively in team environments, albeit not in  

software development but the key concepts are more or less the same, and the bell curve figures Brooks supplies showing manpower increases after a certain point having a negative impact on the project were reaffirming. I’d never seen the concept spelled out in such a meticulous manner.

Delineating between projects with unrelated tasks where manpower could indeed have a positive impact and projects that required complex interactions was the key point of this to me. Additionally, the fact that many tasks must be completed before the next task plays a role as Brooks aptly pointed out, “the bearing of a child takes nine months, no matter how many women are assigned”. It seems like this can be partially mitigated by a well thought out development plan. This would help partition the project into pieces that could be largely developed separately.

Brooks also writes about a ‘surgical team’ and this resonated with me quite a bit. I’ve seen many teams underperform largely due to lack of a structured team and poorly defined responsibilities within a team. This also relates to the idea that a single design philosophy is often the best approach to development. As Brooks notes, this structured approach improves team dynamics, and more importantly, leads to projects being built more efficiently.

Conclusion

The general idea I came away with from the first four chapters of The Mythical Man Month was that a well thought out, structured approach to system development is the best approach to completing large scale projects. This may not be the case in every situation but it's likely the best starting point for most large projects.