The Mythical Man-Month by Frederick Brooks

A brief review

This book is an institution in the technology industry and I can see why it’s highly recommended, as it recounts issues that have plagued the software industry for the last 30 years.

The book was written in the 1970s under the pen of Fred Brook based on his experience managing OS/360 development at IBM during the 1960s.
Some of the central ideas I highlight from this book are the reasons and rationale why software development is so expensive (even today) and why adding more engineers to a project is unlikely to linearly accelerate productivity.
Another idea I highlight is that most problems in software development stem from communication and organization, as well as managing additional complexity.
The latter raises an idea that I see as widespread in the industry (and in my opinion, it clarifies why there are giant companies that do well and others that don’t), why do engineering interviews selected mainly based on problem-solving? and next to nothing with base in communication and organization skills (with both the complexity of the current project the increasing complexity of the future).

The first draft of every program we make is going to be bad, it’s important to know this, prepare for it, and design around that draft.

I realize how lucky I am for not having to deal with printed manuals that document what has been done in the project, if many times carrying out this type of documentation is extremely complex and cumbersome, replacing physical sheets within a manual makes me the most tedious thing I could face. I am glad to know that although there are alternatives such as microfiches, they aren’t perfect (nothing is) since although they solve problems, they also create new challenges.

Similarly, it should be noted that thanks to the syntax of programming languages, which are increasingly readable by the human eye, many programmers prefer that the code created be self-documented, so the idea is handled that the importance of documentation is steadily diminishing as languages ​​become more and more declarative and systems are better and better designed.

The importance of having a good testing framework is extremely relevant, even to the extent that today any company whose work is in this industry cannot afford not to establish unit and integration tests.

The book explains the importance of the main goals with clearly established and verifiable points such as agile methodologies mainly revolve around this life cycle, where the developer performs the iterative extraction allows the refinement of the product requirements to be created.
Since the client doesn’t know what she/he wants, she/he must have a faithful copy of the project under development, which must be correctly loaded and must include a small test case that can be used routinely to detect problems and/or requirements by the user.

Productivity follows quality (in the same way) productivity falls again when one pursues extreme quality.

Without a doubt, this is a good book that exposes practical solutions to problems that seem to be deeply rooted in the technology industry; highly recommended for anyone interested in being part of this industry.