This book is truly a remarkable phenomenon within the software engineering circles.

Back in its heyday, it was extremely insightful, introducing numerous concepts and bringing about significant changes that have now become almost second nature.

However, the book has now become severely outdated. With the passage of time, its practical value has diminished considerably. Apart from a few select chapters such as "Mythical Man-Month" and "Surgical team", it doesn't offer much that is useful for contemporary readers.

It can be regarded as a relic of its era, interesting to peruse simply to understand how the field functioned in the past. In those days, C was regarded as a high-level language, and engineers often had personal offices and secretaries.

Nevertheless, aside from this historical perspective, its practical application in the present is rather limited.

I could not read all the content of this book.

Most of it is extremely outdated. One of the central examples utilized throughout the book is OS/360, a computer that only a small group of people will be able to recognize. There are continuous examples of truly outdated technologies, languages, and procedures that will bore even the most enthusiastic reader. Even some of the proposed organizational structures are now obsolete.

However, there are a few hidden treasures within the book, and one can understand why this book was significant in 1975. But 40 years later, this book lacks any practical necessity. I would suggest that anyone interested in reading this book should obtain another agile book with a more recent background and better examples.

"The Mythical Man-Month" is a good historical book about Software Engineering, but it is no longer a reference one. I give it one star because it is the minimum, and another star for its historical significance.

04/23/11

Dr. Brooks, who is the founder of our department, has more than enough reason for us to read his book. His contributions to the field are significant and his work serves as an inspiration for many. The recent extension to our department building was named after him, which is a great honor.

Apparently, the money for the building came as an anonymous donation from an alumnus. However, the condition was that it be named after Dr. Brooks. This shows the kind of respect he has won from several people. His influence and impact on the department and the field as a whole are undeniable. We are fortunate to have such a remarkable figure as the founder of our department.

Reading his book not only allows us to gain knowledge and insights into his work but also gives us a deeper understanding of his vision and ideas. It is an opportunity to learn from one of the best in the field and to be inspired by his achievements. We should all take the time to read his book and appreciate the contributions he has made.

Except for the blatant sexism, it was a rather good book. It presents a series of experiences that one gradually acquires while working in the software industry. Although it is a bit outdated, for example, we no longer have printed manuals and don't have to deal with the troubles of constantly updating them, many of the wisdoms from this book still hold value.

The entire book never uses a female pronoun. Ever. It gives the impression that engineers, managers, technical leads, and clients are always only male. Additionally, there is this:

'A team of two, with one leader , is often the best use of minds. [Note God's plan for marriage.]' Did you really have to incorporate your conservative, outdated, and patriarchal views in a non-fiction book about computer science?

The bearing of a child takes nine months, no matter how many women are assigned. This is a well-known fact that cannot be changed. Similarly, many software tasks have a similar characteristic. The reason for this is the sequential nature of debugging.

Debugging is an essential part of software development, and it often requires a step-by-step approach. Each step builds on the previous one, and any mistakes or errors in the earlier steps can have a significant impact on the later ones.

Therefore, even if more people are assigned to a software task, it may not necessarily speed up the process. The sequential nature of debugging means that each step must be completed accurately before moving on to the next one.

In conclusion, just like the bearing of a child, many software tasks have a fixed time frame due to the sequential nature of debugging. It is important for software developers to understand this and plan their projects accordingly.

The book is truly good. It contains a wealth of valuable information and interesting ideas that can capture the reader's attention.

However, it does have a minor drawback. It is a little outdated. Some of the concepts and examples presented in the book may not be as relevant or applicable in today's rapidly changing world.

Despite this, the book still has its merits. It can provide a historical perspective and serve as a foundation for further learning and exploration.

Perhaps with a few updates and revisions, the book could be made even more useful and engaging for modern readers.

Overall, while the book may not be perfect, it is still worth reading for those who are interested in the subject matter.

Nonfiction is extremely relevant to my actual job.

I was truly amazed to find that these essays, which were written several decades ago, remain so accurate.

As I am currently in the process of planning how to develop better software and meet schedules more effectively, I have decided to incorporate some of these ideas into my life.

The insights and wisdom contained within these essays can provide valuable guidance and inspiration as I strive to improve my work and achieve better results.

By applying these concepts, I hope to enhance the quality of the software I create and ensure that it meets the needs and expectations of our users.

Furthermore, I believe that these ideas will also help me to manage my time more efficiently and stay on track with our project schedules.

In conclusion, I am excited to explore and implement these ideas in my work, and I look forward to seeing the positive impact they will have on my career and on the software we develop.

Still Relevant Almost 50 Years Later

An article that was written nearly 50 years ago continues to hold great significance and relevance in today's world. Despite the passage of time, the ideas and concepts presented within it have withstood the test of time and remain applicable to our modern society.

The article may have addressed various aspects such as social, political, or economic issues that are still prevalent today. It could have offered insights and perspectives that are just as valid now as they were back then. Perhaps it provided solutions or proposed changes that are still being considered and debated.

Even though the world has changed significantly in the past 50 years, the fundamental human nature and the challenges we face have remained somewhat constant. This is why the article can still resonate with readers and offer valuable lessons and inspiration. It serves as a reminder that some things never change and that we can learn from the past to shape a better future.

In conclusion, the fact that an article written almost 50 years ago is still relevant today is a testament to its quality and importance. It shows that great ideas have the power to transcend time and continue to have an impact on generations to come.

I have a great passion for reading "old" books. The very fact that they were penned a long time ago yet remain relevant is a testament to their true worth.

However, this particular book didn't quite meet my expectations as much as I had hoped. Perhaps it was because I had set my sights too high based on the numerous glowing reviews from many people I hold in high regard. I understand that its content still holds significance today. But there are certain parts that have become outdated. And there are also some parts that, although still relevant, require us to "translate" them into the context of our modern times. Additionally, some aspects have been more comprehensively explained by other books such as Management 3.0, Leading Lean Software Development, The Manager's Path, The Pragmatic Programmer, and the like (which almost surely have MM-M as a reference, I'm aware).

Considering its historical contribution, I would award it 5 stars. I highly recommend it to every professional in the field of software development who desires to understand our past and realize that many of the "new" concepts that emerged in the 90's or 2000's, like "Agile" and the "Spotify Model", aren't actually that novel. Their roots can be traced back to the 70's or even earlier. It's both disheartening and thrilling to know that in terms of how to better organize software projects, we haven't evolved as much as we might have liked. Disappointing because as individuals and as a community of professionals, we always strive for progress. Yet, it's exciting because it serves as a powerful reminder that building software is an extremely challenging endeavor.

I read this for a work bookclub.

It is definitely outdated as it seems to be from a bygone era. However, there are still some interesting bits that can be gleaned from it.

One thing that really bothered me was the author's assumption that every engineer or manager was a "he". This kind of gendered language is not only inaccurate in today's diverse workplace but also exclusionary.

Another strange aspect was the weird amount of biblical references. While I don't have anything against religious references in general, they seemed out of place in this context and didn't really add much to the overall argument or discussion.

Despite these flaws, I still think there were some valuable insights in the book that could be useful for our work bookclub discussions. It's important to be able to look past the outdated and problematic aspects and focus on the parts that can help us grow and learn.

The book shows its age in numerous places.

It can be quite challenging to persevere through the sections that depict the status quo almost 50 years ago.

However, some of these parts enable us to recognize how far the field has advanced since then.

The reason I have awarded 4 stars is that there are many valuable bits of information within this book.

These are the things that have endured the test of time.

The book is truly ahead of its era with some of the observations made within its pages.

It offers insights and knowledge that are still relevant and useful today, despite being written so long ago.

Even though there are parts that may seem a bit outdated, the overall value of the book cannot be ignored.

It provides a fascinating look into the past and shows us how much progress has been made in the field.

Overall, it is a great read for anyone interested in the subject matter.

This book presented some truly insightful ideas when it comes to software engineering practices. However, it is important to note that a significant portion of the book has become outdated and is no longer relevant in today's context.

The author delved into certain specific details of the situations he had faced. For instance, he talked about the practices where developers would plan how they would allocate the debugging computers among themselves. This was a relevant concern back then, but with the advancements in technology, modern machines have far greater capabilities compared to the computers of the 70s.

Consequently, this book is in desperate need of an update to accurately reflect the current state of affairs. The main lessons I gleaned from this book are that software engineering practices must be adaptable to address the changing and often unknown requirements of the software. Additionally, adding more engineers to a project that is already behind schedule is not a prudent approach. Moreover, maintaining documentation can be a challenging task, so it might be a good idea to include paragraphs of documentation directly within the code itself. This would help prevent the code from getting out of sync with its documentation.