Frederick P. Brooks is what I’d call a true pioneer.

Without any existing knowledge and only his own experience in the “tar pit” (as himself call this software development world), he distilled some universal truths of the Software Engineering world. So, the Mythical Man-Month is a summary of his ideas.

This book is a night stand book, that is, you cannot hope to end it in a few days. You have to read slowly, thinking as a 60s software developer, with their limited tools and machines to fully understand this book.

Its content can be seen as obvious, but is interesting seeing the thought process that made the bases of what we call now Software Engineering. Things like how to plan a software project, team specialization, the use of high languages over efficiency, a strict and well-done documentation, etc. are described with some detail in the book with real world examples of Brooks or men of his time.

Of course many readers stop reading after ending chapter 2 where the author explains that software projects are different compared to other projects because you cannot increase development speed introducing more members to the developing team. You’ll need to teach them the project internals, increasing the overall time cost of the project. But I think every chapter has its teaching.

For example, in chapter 3, “The surgical team”, Brooks compares a surgical team where every member has a specialized tasks to his idea of software developing team. Nowadays it is very common to see many jobs for “full-stack developers”, what in my opinion is completely mistaken. You cannot expect to be fully competent in dozens of disciplines (and technologies).

Other interesting chapter for me is “The documentary hypothesis” where Brooks defends the idea of having formal documents for each project like objectives, specifications, schedule, etc. In the agile startup world this is simply wasted time, the old idea of “only the code is what is important” has returned very strong this days because of the culture of skyrocketing your career and rockstar programmer. This two ideas are a bit naïve and against the software engineering principles of software quality and maintainability.

The last thing I want to note about this book is that Brooks even defines the two careers in the software world: programmers and management. Where many people see both of them as opposite careers, Brooks sees them as complementary positions of the organization but encouraging employees to stay in “the technical ladder” by paying them more. Yes, take a look to chapter “Plan the organization for a change”.

To conclude this post, Brooks' book is a window to the past that teach us many principles of Software Engineering with real examples. I recommend its lecture to every undergraduate student of Computer Science or Software Engineering degrees. Many of the problems of nowadays software developing organizations can be seen in this book pages. I encourage every software developer or software engineer to read this book and learn the basic principles of Software Engineering.