I recently read The Mythical Man-Month: Essays on Software Engineering.

Cover image of 'The Mythical Man-Month: Essays on Software Engineering'

The title of the book refers to the unit of effort man-month. It is used by (I want to think ‘old’) metrics to estimate and schedule software development. As Brooks explains in his book, while cost varies on the product of a number of people and number of months, progress does not. It would do it if tasks in software development could be partitioned between individuals with no communication among them. When you take into consideration, the need of communication between parts, the effort increases as n(n-1)/2. The famous Brook’s Law appeared in this book as an oversimplifying but eloquent way to capture the problem:

Adding manpower to a late software project makes it later

If you are interested in reading about the importance of communication in software development, I recommend you to read Agile Software Development: The Cooperative Game. This book contains the most sensible discussion on the nature of software development that I have ever read. Cockburn defends that software development is a cooperative game of invention and communication.

Returning to the The Mythical Man-Month book, Another thing I loved is how it talks about the human factor in software development. In the chapter The surgical team, Fred Brooks says the following:

The conclusion is simple: if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming

When I read this sentence, I was totally amazed. Notice that the author was the project manager of the massive software system of IBM System/360 (OS/360). So more than three decades ago, a software developer with experience in developing huge programs, didn’t emphasize the need of ceremony and heavyweight recipes for software development. Instead, he could clearly see what many people can’t today. He proposed that the most expert programmers should act as surgeons leading a surgical team. The rest of the team should assist them to maximize their effectiveness with the core tasks of writing the specs, designing, coding and testing.

Fred Brooks mentions a 1968 study that concludes that the best programmers are ten times more productive that the worst ones. Robert L. Glass in Facts and Fallacies of Software Engineering talks about numbers ranging from 5 times better to 28 times better. Ignoring this fact is, in my opinion, the source of many deep problems in the Spanish software development industry today. Companies don’t see technical talent as an asset to make more money, but simply like something academical.

Although these were the topics I enjoyed most, the book covers many other software development principles which are totally valid today: the importance of prototyping and the wicked nature of the discipline, the dangers of over-designing, the need of cohesive teams with good communication mechanisms’ The visionary condition of the author was proved again with his famous article No silver bullet, which stated that nothing in the next 10 years (from 1986) would provide one order of magnitude improvement in software development. The article is included in the book by the way.

In conclusion, it is a book that I totally recommend. The principles it talks about are totally valid today, and I enjoyed reading about them considering the time the book was written. I am simply amazed by the fact that 34 years ago, someone was able to recapitulate so many true and concise ideas on software engineering, even before that software engineering, as a discipline, existed.