The Mythical Man-Month
Reason Book was Chosen:
This is one of the 5 books that Jason suggested I read. I believe he also knows the author of this book.My Thoughts
The Mythical Man-Month covers two overriding topics relevant to large software projects:
- The correct balance of people working on the project and time
- Balancing the management of a project that consists of a singular goal while employing multiple minds.
For the first topic, author Frederick P. Brooks, Jr. introduces us to seemingly straightforward Brooks Law:
adding manpower to a late software project makes it later.
It’s counterintuitive. Ask the average person what they’d do if they were behind on a big software project. My guess is that the majority would say to simply add more people. This can be for a number of reasons, one of the main ones being that adding a person mid-project requires training to get that person up to speed. It also requires excellent communication, something that becomes more and more difficult the larger the group becomes.
The second main topic of the book deals with the type of roles that should be present for a large project. For instance, each project should have an architect, and that person’s role is to be the user’s agent.
This was a really helpful book in thinking through the development of a project within a large group. I was surprised at my reaction while reading The Mythical Man-Month. I have worked in web development and have been a one-person shop for the past 10 years. I continually bristled at the descriptions of the complexity of the types of projects described in the book. It was quite clear to me that I should continue as a one-person shop as this book did not make me want to manage large projects. I like the direct contact with the client and the actual work. I hesitated even sharing that, but it was such a strong reaction that it was eye-opening to me.
The power of this book is that it is written about software projects, but it can really cover any type of project where multiple people are involved. Written in 1975 about a rapidly-changing field, it has stood the test of time and even has some updates and self-examination in the final chapter (written in 1995). Some parts were dated, but the majority of the book covered important principles applicable as much today as in 1975. If you manage large projects, especially in the software realm, this is the book for you.
