The Mythical Man-Month is a book written in 1975 by Frederick Brooks based on his days working in OS/360 in IBM.
The book’s main topic is how we manage and estimate software developments.
Besides being written 47 years ago, it maintains some of the foundations of why software development fails and enumerates the most common errors.
The first chapters talk about how a poor technique of estimating times in development can make a project fail, costing a lot more money or being canceled definitely.
From my perspective, it is a little sad that this oldest book describes the exact same problems that some companies continuously have.
That’s why if you’re involved in one way or the other with software development this is a very recommended lecture to locate and attack those problems in project management.
Man-Month
One of the major discussions in the book is to solve the question of how many developers you need to complete the job.
To start, it proposes the law of Brooks, which says: “Adding human resources to a delayed project will delay it more”.
It based his thesis on the nature of the software development task, that most of them are dependent on one another, making communication and the coordination of the team more difficult.
Indeed, this is the principal foundation of Brooks to say that more men don’t mean a shorter development time, making an analogy with the architecture and the story of the Babel tower.
The principal foundations for the correct development of software depend on the communication and the homologation of the work.
The role of documentation
Another pillar of the software development listed by Brooks is the documentation of the project.
Not only the technical one but also for all the other aspects of the project like objectives, specifications, schedule, budget, organization chart, and space locations.
All of this is in order to solve the fundamental questions of the project such as what, when, how much, who, and where.
This approach can only work properly if the team seriously answers these questions.
One of the most important phrases for me that I read in this book is: “The specifications of the project should be so specific that the team can’t lie to themselves”.
And that is one of the more important enemies of the projects, the human factor, and the infundated positive thinking inclusive when the project is stalling and needs urgent restructuring.
No “Silver Bullet”
The silver bullet papers of Brooks are an angular point of his work, especially now that many years have passed.
It describes how it doesn’t exist a single development tool, in either technology or management technique, which itself promises even one order of magnitude improvement within a decade in productivity, reliability, or simplicity.
The main idea of Brooks is that the hardware advances in giant steps year to year, but the software development techniques don’t make that improvement over the ages.
The reason why is curious at this point of history is that the paper lists some technologies that in the future can be a “silver bullet” that improves software development, such as high language levels languages, object-oriented programming, environment tools, or workstations.
And inclusive, some of those technologies are still in development like AI programming, and graphical programming.
Concussions
Besides the time, some parts of The Mythical Man-Month problems still affect software development at all levels, and some teams keep falling with the same rock.
Some of the development problems like the memory or the access to proper workstation had been eliminated for the majority of the people and projects, but other things like the graphics that propose how more people involved in a project can delay a project deserve at least a little of attention.
This book is one of the pillars of software engineering and can make you as a team member or manager someone prepared for the hard work of finishing a big software development.
But more important than just reading it, it is important to start implementing these ideas, as I said at the start of the review, it is sad that after 47 you can see companies with the same problems, as Brooks once said:
“This is the bible of software engineering” because “everyone quotes it, some people read it, but hardly anyone practices it.”
