Many times when I peruse a book that has stood the test of time, its precious pearls of wisdom remain clearly visible, waiting to be harvested and put to good use.

However, I cannot say the same about "The Mythical Man Month." I will concede that Brook's Law still holds true, and managers today still trip over this very principle.

Nevertheless, much of his advice has fallen short in the face of the more recent agile development movement and the even more recent devops movement. In the end, he was still advocating a kind of waterfall approach to development, which has been repeatedly found lacking.

Additionally, his writing gave the impression of someone who was overly enamored with his own ideas. In my opinion, "The Mythical Man Month" ultimately failed to live up to expectations, although I can understand why it was once a highly praised book.

I think it would be better if someone were to extract the genuine nuggets of wisdom from "The Mythical Man Month" and write a new book that takes into account the current state of the art and has a less self-congratulatory tone.

In the context of the history of software engineering and management best practices for effectively building software systems and managing projects and teams of all sizes, this book holds incalculable value.

It is highly recommended for every software engineer who has an interest in constructing software systems at a meta-level, which refers to the technical and social systems that assist in building software systems.

Alternatively, those who wish to gain a profound understanding of these processes will also find this book extremely beneficial.

Remarkably, since the writing of this book, only the specific methods and tools mentioned have undergone changes.

The majority of the higher-level discussion regarding the software architecture and management processes appears to be timeless, remaining relevant and applicable even in the ever-evolving field of software engineering.

This book serves as a valuable resource that provides insights and knowledge that can be applied to various software engineering projects and teams, regardless of their size or complexity.

This article presents a series of thought-provoking and impressive ideas that seem to hold many timeless insights.

While it may be a bit less action-oriented and lucid than Peopleware, it is still well worth reading.

It emphasizes concepts such as acting with unity and hierarchy, where authority stems from the momentum of accomplishment.

Builders are not mere monkeys, and the center gains authority by delegating power.

Conceptual integrity leads to ease of use, and communication is crucial.

Constraints can actually conduct innovation, and there is a distinction between the critical path and less important termites.

The approach of designing and growing rather than simply building is advocated.

A dual-ladder-equal-prestige organization is proposed, as well as the matrix management of functional specialists.

Probabilistic and deterministic aspects are considered, along with the idea that pure thought-stuff is infinitely malleable.

The mention of a scaffold or STDs of extra work, sequential constraints, and sine cera adds depth to the discussion.

Skepticism versus pessimism is explored, and it is noted that software is not like a building.

Some aristocracy may need no apology, and the roles of the surgeon and co-pilot are relevant.

System program building is seen as a process where metastable entropy is decreasing, and termites rather than tornadoes cause delay.

The idea, implementation, and interaction all reside in the mind of the maker, and a total-system, user-oriented attitude is essential.

Finally, the concepts of unleashing constraints and vehicles of opportunity and opportunity space are introduced.

Overall, this article offers a wealth of ideas for further consideration and exploration in the field of software development and beyond.

I did not find any real value in the book.

The ideas that were stated in it seemed to be quite obvious and lacked depth.

It felt as if the author was simply rehashing common knowledge without adding anything new or interesting.

As a result, I quickly lost interest and gave up reading it halfway through.

I had hoped to gain some new insights or perspectives from the book, but unfortunately, it failed to deliver.

Perhaps it was written for a different audience or with a different purpose in mind.

Nevertheless, for me, it was a disappointment and a waste of my time.

I will now look for other books that can offer me more value and intellectual stimulation.

This is a classic within the field of computing.

Any programmer, systems analyst, or information systems project manager who is truly competent will have read this book.

Considering all the changes that have occurred since the book was written, it is astonishing how well it has endured.

I assume that for the young programmer, the recent college graduate, the lessons from the development of one of the early mainframe computer systems may not appear relevant.

However, as pointed out in the additional chapters included in the twentieth anniversary editions, a significant portion of what seem like technical issues are actually management problems.

Faster computers and higher level languages, when combined with new software engineering techniques, cannot compensate for poor management.

So, in actuality, this is a book about management rather than programming itself.

This is a relief because the world is充斥着 management tomes, but there are very few excellent books on managing software projects.

I have been working in the IT field for a considerable period of time, wearing many different hats. Recently, I finally managed to get around to reading the MMM. What truly amazes me is that despite the fact that this book was written 40 years ago, I don't think any of my colleagues have ever read it. The problems described within its pages are ones that I have witnessed time and time again. It's quite astonishing how relevant it still is today. I am now looking forward to applying the concepts and ideas presented in the book and seeing the success that can be achieved with these so-called "old" ideas. I firmly believe that there is a wealth of knowledge and wisdom to be gained from this classic text, and I am excited to put it into practice and see the results.

Still Applies

Working in IT for quite a while now with lots of hats, I finally got around to reading the MMM. What amazes me is that while this book was written 40 years ago it, I don't think any of my other ever read it. So many problems described I have seen over and over. Looking forward to appling and seeing success with some "old" ideas.

I honest to God loved this book in a way I haven't loved a book, especially a nonfiction, nonphilosophy book, in years.

From the very first page to the last, Brooks manages to capture something truly special. Even when certain aspects might seem a bit outdated, like references to secretaries and punch cards, or perhaps not entirely 100% correct, there is still a core essence that shines through.

And this essence isn't just applicable to programming or software development. It has a much broader reach and can be applied to the management of almost anything. Although software development may have its own unique characteristics, the principles Brooks presents are universal.

As he so eloquently put it in my favorite quote from the book, which I had heard at least a decade before reading it:

Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary.

No such faith comforts the software engineer.

This book is an easy and enjoyable read, consisting of short essays that are accessible to the layperson. However, it becomes even more enriching if you have some passing familiarity with project management and/or software development. I cannot recommend it highly enough. In fact, I fully expect my friends to not be at all surprised when I start recommending it to them nonstop.

Update: Thanks to my sister for gifting me a gift card to procure this from a local bookstore (a big shoutout to McNally Jackson). They were amazing and ensured I got a great copy even during these crazy times. This book is still as relevant and impactful as ever. As Brooks discusses near the end, while it's a book about software, its true focus is on people. And that's what makes it so special.

To only a fraction of the human race does God give the privilege of earning one's bread doing what one would have gladly pursued free, for passion. I am very thankful.

Though a bit dated, this collection of essays remains highly relevant for software developers and technological project managers.

Brooks, with his extensive real-world experience in constructing complex systems, is brimming with insights into precisely where the pitfalls are located.

This book would prove beneficial for anyone desiring to think more effectively regarding software design, planning, and project management.

I've perused a few negative reviews of this book, and most seem to be rating Brooks himself rather than addressing concerns about the actual text content.

So, here are a few of my unsolicited opinions on these matters:

Yes, Brooks is a devout Christian who views software development as a vocation - an act of subcreation, befitting creative beings made in God's image. I perceive this as a positive aspect, not a drawback. If you are offended by Christianity, you will likely have the opposite view.

Yes, Brooks employs "he" and "his" when referring to software developers. There is a significant precedent for using masculine pronouns to refer to humans of any gender in English prose. Doing otherwise would have been especially cumbersome in the 1970s and 1980s, when the vast majority of software developers were male. Believe it or not, this was not intentionally sexist. Whether it was systemically sexist is another question.

Regarding the content: Yes, many of the concepts Brooks discusses are now taken for granted in the IT industry. (And he is one of the primary reasons for this.)

Still relevant but somewhat baroque.

This description implies that something has maintained its significance or importance in a particular context, yet it also exhibits characteristics that might be considered overly elaborate or ornate.

Perhaps it refers to a work of art, a piece of literature, or a particular style of architecture. While it continues to hold value and capture the interest of people, its baroque nature may make it seem a bit excessive or overdone to some.

However, this very quality can also be what makes it unique and captivating. The baroque elements add a certain grandeur and complexity that can draw viewers or readers in and hold their attention.

In a world where simplicity and minimalism are often favored, something that is still relevant but somewhat baroque can offer a refreshing alternative. It reminds us that there is beauty and value in the elaborate and the ornamental, and that sometimes, going beyond the ordinary can lead to truly remarkable experiences.

Throughout my career, I have been repeatedly recommended "The Mythical Man-Month".

I read it, and I have to say that this should NOT be on anyone's reading list in the 21st century. It is incredibly outdated. From the way of approaching planning, to how to think about a team structure, to the lack of women in the workforce, and even to the religious undertones, it is simply not in line with the modern era.

I didn't like it, nor did I find it useful. Some of my favorite (ridiculous) bits include:

- A team has one Pilot (the main engineer, who is also in charge of hiring, processes, admin, and all the things) and a copilot (essentially his shadow), and they are the only ones who write code. There is also an engineer who purely does infrastructure, one who purely knows the programming languages in use, one technical writer, and around 6 various secretary roles.

- The argument that the Tower of Babel failed because of a lack of organization and communication, whereas the stories say that "an omnipotent being intervened to make it impossible to have organization and communication".

- Brooks is a big advocate of architects and dividing architecture from implementation ownership. There can be consultation but not actually shared accountability or team decisions.

- How cumbersome the OS/360 manual became. Do I care? No.

- The importance of IDE and how much high-level languages simplify development and add certainty.

Please skip this book. It doesn't breed meaningful education in today's ecosystems.

{ 4.5 stars } This book is not a modern edition, yet it is filled with an abundance of useful information that every programmer should be aware of. It涵盖了programmers can utilize in their real lives. Whether it is for group work within a company or even as an individual. The knowledge and insights provided in this book have truly convinced me. It has not only given me self-confidence but also inspired me. What sets this book apart is that it doesn't just fill your mind with codes. Instead, it offers mental strength and motivation for self-learning. It serves as a valuable resource that encourages programmers to expand their skills and knowledge independently. Overall, I highly recommend this book to anyone in the programming field.

Since my knowledge about programming is extremely limited, perhaps it could be written on the back of a postcard and wouldn't be of much value. Therefore, I don't have anything particularly worthwhile to say about the software engineering aspect of this collection of essays on software engineering.

Moreover, Brooks was writing in the 1960s, partly based on experiences from the 1950s. I assume this means that I'll be making some claims regarding wider applicability in terms of project management, people management, and understanding the nature of tasks.

I read the 20th anniversary edition, which I remember as not being inexpensive. To justify the price, it is laid out in an expansive manner with numerous black and white pictures of prehistoric beasts stuck in a tar pit, the Tower of Babel, werewolves, and other such things that come to mind as metaphors to explain the experience of certain projects. There isn't one of a burning Zeppelin, but perhaps that will be corrected in a future edition.

I'll now provide brief summaries of the essays:

The Tar Pit -

The Mythical Man Month - If a project is behind schedule, adding more manpower will only further delay it, especially if the nature of the project requires communication between team members.

The Surgical Team - A project team is best organized with fixed and exclusive roles, each member focused on one task, similar to a surgical team. This approach is scalable if a large project can be divided into appropriate parts.

Aristocracy, Democracy, & System design - Be like the Cathedral builders of Rheims, accepting the creativity of implementing someone else's vision to achieve overall harmony.

The Second System effect - The designer of their first system will be cautious and lean, but their second system tends to be filled with elaborate details and pet ideas.

passing the word - I think this was about project documentation.

Why did the Tower of Babel Fall - Communication problems, and also, don't unnecessarily vex God.

Calling the Shot -

ten pounds in a five pound sack -

The documentary hypothesis -

plan to throw one away - More or less what it says.

sharp tools - Meh, computer stuff, those things will never catch on.

the whole and the parts - As above, and get off my lawn.

hatching a catastrophe - "How does a project get to be a year late?..One day at a time" (p.246).

the other face -

no silver bullet - Good news for werewolves, there are no silver bullets.

Then the main points are repeated briefly on pp230-250, eliminating the need for the rest of the book.

I had marked a couple of pages in the No Silver Bullet chapter the first time I read it, but it was another person who read it, and I couldn't see or imagine what had caught his attention. I'm apparently dead to myself, which is probably for the best. You know, this skull isn't big enough for the two of us, and all that.

The above may sound rather grudging, especially the chapters that seemed too insubstantial to deserve anything more than a question mark. However, I found this book very exciting the first time around (and not just because of the picture of prehistoric mega fauna stuck in a tarpit). There are two reasons for this. Firstly, as he acknowledges, it is a book about software programming, so its theme is people working in teams to deliver a service product for end users. He happened to be familiar with software, but my second reason is that this is a wisdom book, and that wisdom is widely applicable - any organization delivering a product or service to end users (who may or may not be the people paying). Clearly, the downside of a wisdom text is that it is apocryphal, but I'm old and ugly enough to live with that. Indeed, as with wisdom literature, I found it as much reassuring as instructive. I had noticed that adding people to a late project doesn't speed up delivery any more than adding extra women to assist in a pregnancy, but I wouldn't have dared admit it against the 'common-sense' orthodoxy around me. In fact, the additional labor not only caused me extra work but also brought me to tears in a small meeting room. Brooks approvingly cites other writers (pp276-7) that the nature of work is not technological but sociological, hence, perhaps, the lasting appeal of working for oneself.

Also, his point about end users influenced my thinking. He says that the point of programming is not to make a program that can do something or other but to satisfy the user (or the purchaser, not necessarily the same person), which for me was quite a paradigm shift from providing a definable technical service to customer satisfaction. Indeed, one can nuance this, especially when thinking about public services where you have multiple parties expecting different outputs from a service.

So perhaps I can't fairly recommend this book widely. The fruits I picked from it may not appeal to the tastes of others. Indeed, you may not find anything new or interesting there, especially if you are a thoughtful anthropologist of the workplace.

On software, his support for the thrice noble microfiche may be too old-fashioned for contemporary tastes, and generally, for all readers, all the workers in this book and all the presumed workers, united, all around the world, are men. This, for someone who was working not just in the 1950s but also into the 1970s and 1980s, strikes me as interestingly thoughtless.