For good reasons many people recommend book “The Mythical Man-Month: Essays on Software Engineering” when it comes to management of software projects. Reason is that it is one of the classical books on this matter. Recently I was also recommended this book. After reading it I realized that I grasped no new ideas or things that I did not know before. It is not because book is not good enough, but rather because it is very old and many other publications, I’ve read, have provided me with lots of up-to-date information. Not to mention, that many of these publications have been influenced by exactly this book.

Same was true for other person flying in same plane with Brooks, author of book:

The plane droned through the night toward LaGuardia. Clouds and darkness veiled all interesting sights. The document I was studying was pedestrian. I was not, however, bored. The stranger sitting next to me was reading The Mythical Man-Month, and I was waiting to see if by word or sign he would react. Finally as we taxied toward the gate, I could wait no longer:
“How is that book? Do you recommend it?”
“Hmph! Nothing in it I didn’t know already.” I decided not to introduce myself.

On the other hand, I got some insights into how software development looked like back in 70th.

Yes, I spelled it right. Book survived many years, mainly “because building things, including software, has always been as much about people as it has been about materials or technology – and people don’t change much in only 25 [35] years.”

I think that the strongest generalization from the book is this one:

“Assigning more programmers to a project running behind schedule, may make it even more late.”

To the topic, but not that much related. In book there is mentioning of Conway’s Law, which could sound like this:

“Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.”

The other day I came across nice article called “Seeing the team in the code”. As per me lack of opened and frequent technical communication between developers, like code reviews, could make source code not really what team wants it to be. On the other hand, it could help make code less coupled, if everything is made by contract. Conway’s law sounds like fun, but each joke is based on truth behind. There is even Microsoft research paper on this: http://research.microsoft.com/pubs/70535/tr-2008-11.pdf. (Not easy to read or to follow.)

I would recommend this book in two cases: you have little or no clue of how development and management of big software projects is done OR if you want to just make sure you are familiar with this work to have more coherent view on the topic. In case you are average developer, who frequently reads recent books or posts on management/leadership/etc in software it is very likely that you will not enjoy this book. I also did not enjoy it very much, I probably fall into case number 2.

Thanks for reading…