book review: the mythical man month

(⌒▽⌒)☆: 3 min. read

This was the content of one of my internal sharings I did within my team. Reviewing one of the classic books in software engineering.

title: The Mythical Man Month

author: Frank Brooks

After spending quite a bit in the software industry, this book always comes up in the recommended readings from other software engineers. I've always procrastinated on reading it but I finally did it after spending ~4 months on it.

What does the book cover?

The mythical man-month is a series of essays written by Frank Brooks on the complexities of software engineering and how software projects even with well meaning intentions can get delayed and go past their budget. The term Brook's Law is coined from this book.

For today's sharing, I'll just focus on one essay, its title sake "The Mythical Man month" and its key points.

the essay starts of with listing why some software projects go awry.

it gives these points:

  1. estimation techniques are poorly developed (we are always optimistic that something will work out for the future me)
  2. we often confuse effort with progress
  3. schedules are not monitored with utmost discipline
  4. when shit hits the fan, we add more manpower to the project ("Like dousing a fire with gasoline")

from here on i'll just quote several things that i thought made sense / hilarious:

As human makers of things, the incompleteness and inconsistencies of our ideas become clear only during implementation.

i found this above quote really true, especially when dealing with unknown unknowns. The only way to find the known unknowns is really to implement something and see where it leads to.

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.

found this quote true to a certain extent as some software work cannot be split cleanly such that people can work on them independently.

The bearing of a child takes nine months, no matter how many women are assigned.

lol

He goes on to justify why adding more people to a software project makes things worse. He said that adding an additional person increases the intercommunication level of effort by n⋅(n−1)2\frac{n\cdot(n-1)}{2}

So team-of-3 requires three times the intercommunication of team-of-2.

And team-of-4 requires six times the intercommunication of team-of-2.

so any gains gotten from task completion is wiped out by the increase in communication burden.

The later parts of the book attempts to provide suggestions to deal with the problems above.

Thoughts on the whole book:

This book was first published in 1975, so its surprising that it remains relevant after these few years. There are certain gems in the book but honestly this book was a slog to get through, especially since quite a few suggestions from this book have already been integrated into our industry. (Brooks mentioned about the composition of a surgical team which is essentially an Agile Team now).

Would I recommend to read through it? Honestly, go buy the audio book or skim through it quickly to get the key points. However I would say that his writing style is quite eloquent and draws you in to read.

Also, I think the fact that my brain has been already destroyed by modern media as it caused me to be quite impatient to sit and finish the book 😓.