Takeaways on The Mythical Man-Month book

After finishing up reading the classic book The Mythical Man-Month from Frederick Brooks, it was astonishing to realize that most of his ideas are still sharp today in the field of software engineering. Apart from very few topics that somehow changed nowadays, I would like to point out my three favorites topics from his essays that are still relevant today and I personally have experienced in my career.

Adding manpower to a late project makes it later

Brooks argues that it is generally a bad idea to add more people to a project that is already late. He has some convincing arguments:

• Whenever a new member joins the team, we need to share the existing knowledge, otherwise this person cannot contribute. It has a side effect that must be carefully considered: The once active and productive developer, has to stop her development tasks to take a training role, delaying the project even more.
• Whenever the team grows, the communication overhead also increases, meaning that new channels of communication will be created and the team will have to keep up.

Good cooking takes time

During some development tasks, we usually know that we can never rush it, specially when building what is meant to be foundation of a program. On the other hand, a business has to ship new features as fast as possible, causing the task rush inevitable in most cases.

Brooks makes a good analogy with cooking. He suggests that if you want to have proper meal with nice taste, good appearance and nicely done, you have to give the necessary time for the chef to prepare. Otherwise you will end up with some disastrous food, burned in one side and raw in the other. That analogy fits really well for certain software development tasks. We must understand what is critical to the system, putting more thought on its design and implementation. Rushing its completion can cause a lot of issues in the long-term of the project.

Small, Sharp Teams

Brooks really nails it down with this analogy. He uses a surgical team of doctors to point out how a small and multidisciplinary team makes progress more effectively.

I personally have experienced that. Once working on an iOS app, I had by my side a backend developer and a UI Designer. We three sat down and decided how the screens would look like, how the data structure would be shaped and how the API between the app and backend should look. This approach was unbelievable effective. In sprints of two weeks we always had a new app release including new features and bug fix.

It all comes down to communication

There are many other great arguments in the book where Brooks talks extensively, but at the end of the reading what is clear is that communication is the key for a project success. You might have the 10x rockstar developer, but if they cannot communicate well with your team, the project is likely to fail.

This book has survived the toughest of all challenges: Time. It was originally published in 1975 and at the time of this writing it is still rock solid. This is a must-read for anyone interested in software engineering and project success.