Short, sweet, and delightful, this is a collection of loosely-linked essays on computer project management.

In the edition I read, some parts date back to 1975, while others are as recent as the mid-1990s. Many of the ideas in this book have now become common knowledge. For instance, "the second system effect" and "adding engineers to a late project makes it later" are both widely recognized.

However, some details have not aged well. Brooks spends a significant amount of time discussing overlay size as a complexity/space/speed tradeoff, but this is not a very relevant example today. In the past, core memory was scarce, and programmers would use statically-defined overlays to run one chunk of code and then load the next. But this is now obsolete, having become so in the early 1970s. Brooks is aware of this, and in his discussion of the Second System Effect, he remarks wryly that OS/360 had one of the best overlay managers ever built - best because it was the last, and the last because by the time it was developed, it was already a solution to an obsolete problem.

Some of the ideas in the book seem interesting and have never been tried. Brooks suggests organizing an engineering team like a surgical team, with a clear tech lead and a set of assistants with specialized skills, such as a test engineer and a writer. He also advises having a language lawyer on call, shared between teams.

Brooks further proposes conceptualizing "tech lead" and "project manager" as counterparts to a movie's director and producer, with coordinate roles and no firm hierarchy. He suggests rotating people between these roles and ensuring they have comparable pay, social status, and office furniture. It seems that the industry is moving in this direction, as Google and other companies have "technical leads" who form a separate hierarchy from people managers. Given that this book was for many years "assigned reading" at Google, I suspect this is not a coincidence.

The prose is delightful but has an old-fashioned feel to it. Programmers are referred to as "men," and they have offices with carpets. The book is also strikingly Christian, with the author making asides about how engineering is man's counterpart to God's joy of creation. There is even a short, playful chapter on "project management lessons from the Tower of Babel - the second engineering project in the bible, and the first engineering management fiasco."

Overall, this is a fascinating book that offers valuable insights into computer project management, despite some of its age-related flaws.

A classical, but still actual book for software engineers.

This book has withstood the test of time and remains highly relevant in the ever-evolving field of software engineering. It offers valuable insights and principles that have been proven to be effective over the years.

The concepts presented in the book are not only applicable to traditional software development but also to modern technologies and methodologies. It provides a solid foundation for software engineers to build upon and helps them to develop high-quality software systems.

Whether you are a beginner or an experienced software engineer, this book is a must-read. It will expand your knowledge, enhance your skills, and inspire you to think differently about software development.

In conclusion, this classical book is a valuable asset for software engineers and should be on every software engineer's bookshelf.

Having just completed ‘The Mythical Man-Month’, I was truly astounded. Even though it was written way back in August 1995, a significant number of the concepts and ideas it presents remain highly relevant today.

As a professional Software Developer with nearly four years of hands-on experience and a total of five years immersed in the field of Software Development, this book seemed like a vivid testament to the inner workings of this profession in bygone days. It's almost as if it was meticulously crafted as a diary, destined to be perused by future generations who are curious about the methods and processes used to build software in the past.

If you find yourself with some spare moments, I wholeheartedly recommend delving into this book. You'll be pleasantly surprised to discover how many of the concepts it contains still hold true and are applicable in the present day. I have an unwavering passion for gleaning knowledge from others' experiences, and reading a book that was written with the noble intention of sharing the past with the new generation is truly a remarkable experience. It's indeed a great read that offers valuable insights and lessons for all those interested in the field of Software Development.

The quality of this book is truly beyond question, and I find myself at a loss for words when trying to express its excellence.

Initially, I began reading this book upon the recommendation of the Professors in the curricular unit that shares the same name as the book's theme: Software Engineering. To my surprise, it didn't take long for this book to become something truly special. It was not just another ordinary read; rather, it was a source of enjoyment and inspiration.

What makes this book even more remarkable is that it is a technical book, and yet it has managed to captivate me in a way that only a few books can. Having had the privilege of reading the Anniversary Edition, I was delighted to discover that it not only contains the original chapters but also four new ones. In my opinion, these new chapters are some of the best in the book, standing shoulder to shoulder with the chapter that shares the same name as the title.

While some of the concepts presented in the book were not entirely new to me, they still served to consolidate my existing knowledge. However, there were also many other aspects that offered a completely new perspective. After reading this book, I can firmly say that I am a more well-rounded programmer. It's not because it teaches specific programming languages like A, B, or C, but rather because it delves deep into the fundamentals of programming, covering the proper way to program in terms of organization and structure.

This book is an absolute must-read for every programmer, team manager, and anyone whose passion or work is related to software. There is only one small point in the book, related to AI, that I don't entirely agree with. However, I will refrain from revealing it here to allow future readers to be either surprised or not by it and then engage in further discussions with me. Overall, I loved this book and wholeheartedly recommend it to anyone interested in the field of software engineering.

The Mythical Man-Month commences with great vigor, presenting a harmonious blend of excellent humor, captivating story-telling, and even more remarkable analogies and metaphors. What's most fascinating is that the assertions made by Frederick Brooks over 40 years ago still hold true today. However, despite this, the book has not fared well with the passage of time.

Chapters 5 - 8 and 9 - 15 seem extremely outdated. I'll provide some reasoning below, but the essence is that the middle part is largely skippable. Worse still, the religious undertones become a bit excessive in this section. And to make its outdated nature even more blatant, the sexism is rampant, as Brooks deliberately uses "he" for every pronoun. Granted, nearly all programmers were males at that time, so his usage wasn't exactly misleading. But when reading it in this era, it gives the impression that the book is intended to be sexist.

Aside from the questionable pronoun usage, the first four chapters, chapter 7, and the final chapters remain truly insightful. They mainly detail how and why software development is so costly (even today), and why adding more engineers to a project is unlikely to linearly increase productivity.

The key takeaway is that the biggest challenges in software development stem from 1) communication and organization, and 2) managing added complexity. In some respects, I think I've always been aware of this. But these chapters articulated it very clearly and convincingly.

It makes me wonder why engineering interviews place such a heavy emphasis on problem-solving and hardly any on communication and organization skills, or the ability to manage growing complexity.

I would highly recommend chapters 1 - 4, 7, and 16+. Here's a summary of why I would skip the rest:

Chapter 5 can be encapsulated by Ernest Hemingway's famous quote: "The first draft of everything is shit." Brooks offers some detailed explanations as to why the first draft of every program is subpar and how to prepare for and design around it. Chapter 11 mostly reiterates this.

Chapter 6 describes how cumbersome the OS/360 manual became. Although it provides insights due to its laughably outdated nature, manuals have mostly been replaced by auto-generated websites. But back in the days of OS/360, when engineers arrived at work, a stack of pages would be waiting on their desks. These pages represented the changes made to the system the previous day, and the engineer was expected to locate the relevant pages in the five-foot-tall manual and replace them with the new ones. Brooks chronicles the difficulties of maintaining such a manual and how switching to a microfiche manual had both advantages and disadvantages.

Chapter 10 discusses important documents for a software organization. While these may be relevant in a major enterprise setting, they seemed rather out of place in a startup environment.

Chapter 13 explains the characteristics of a good testing framework, essentially emphasizing the importance of unit tests and integration tests. This is now taken for granted in the modern workplace as every company at least recognizes its significance.

Chapter 14 similarly expounds on the importance of milestones, or major goals with clearly distinguishable and verifiable endpoints. Again, this is a given in the modern workplace. Kanban, Agile, and every other Software Development Life Cycle largely revolve around this.

Chapter 15 spells out the importance of documentation. But looking into the future, Brooks预见 this becoming obsolete, admitting that newer languages of the time, like Ada, allowed for code to be almost human-readable. Nowadays, code is often human-readable enough that most programmers prefer for it to be "self-documenting." It's always a matter of debate whether the code written is actually self-documenting. But as languages become increasingly declarative and systems are better designed, the importance of documentation is constantly diminishing.

Książka o zarządzaniu projektami IT napisana aż 40 lat temu. Przerażające jest to, jak bardzo jest aktualna. Wiele problemów opisywanych przez Brooksa nie zniknęło do dzisiaj, a techniki radzenia sobie z nimi są nadal stosowane, choć często pod innymi nazwami.

Oczywiście nie da się ukryć, że sporo informacji w książce jest już bardzo przestarzała. Na przykład, developer powinien tak przygotować program na kartce, by nie zabierać cennego czasu na współdzielonej maszynie. Pojawia się też "nowatorskie" podejście do zaprzestania używania GOTO, choć według autora może być trochę zbyt stanowczo postawione. Co więcej, jako przykłady zastosowań podawane są nieznane systemy lub nieużywane języki.

Stąd pod względem merytorycznym książka może pozostawić pewien niedosyt. Jednak nadal warto ją przeczytać, aby zobaczyć jak wiele się (nie)zmieniło na przestrzeni tych 40 lat. Może ona dać nam perspektywę i pozwolić nam lepiej zrozumieć aktualne problemy i rozwiązania w zarządzaniu projektami IT.

Dated and lacking in excitement, this book seems to have been a long-drawn-out affair for me. I believe I began reading it in 2014 and only managed to plow through to the end this year.

There are undoubtedly some great concepts within its pages that have spread and had an impact on numerous other works, so I can't fault it for being the source. However, I found that most of the chapters didn't have much applicability to modern software development in general.

The eponymous chapter was perhaps the most influential, although I think it would be more beneficial for project managers to peruse than developers. Some of the other sections did contain valuable gems of working advice, but many felt repetitive due to the advancements in technology and methodology within software engineering.

The strange religious undertones and the peculiar treatment of women don't do it any favors either. Statements like "A team of two, with one leader, is often the best use of minds. [Note God's plan for marriage.]" are, quite frankly, an odd way to back up your ideas.

I suppose there is some historical significance here, and the contents might be more useful if the reader is operating in a field of software where progress hasn't been as rapid. For me, unfortunately, it just wasn't worth the time investment.

I read The Mythical Man-Month by Fred Brooks, and I must say, it feels like old wisdom.

In today's landscape, I would keep the concept that communication is a significant factor for success. When many people work together, they need to talk and organize, and this takes time.

The "second-system effect" is also important. Brooks says that when people build something for the second time, they try to make it perfect and add too many things, which makes it worse.

The book feels old, but there are still some useful lessons today. Software projects still have delays, mistakes, and bad planning. I have recently read The Pragmatic Programmer, which I believe remains very actionable today. While The Mythical Man-Month helps you understand how it all started, you can find better resources for its topics nowadays.

However, it's important to note that the ideas in The Mythical Man-Month are still relevant in some ways. For example, the importance of communication and the need to avoid overcomplicating things are still valid.

In conclusion, while The Mythical Man-Month may not be the most up-to-date resource on software development, it still has some valuable lessons to offer. It's worth reading, especially if you're interested in the history of the field.

The first part of the book dates back to 1975.

Most of the general ideas put forward by the author are indeed interesting. However, he is concentrating on extremely large teams that were dealing with now highly outdated technology, such as developing operating systems and compilers, and solving a very different set of problems. Fortunately, this part was rather short, so it didn't take too much time to go through. I would rate it 2 out of 5.

The second part of the book is a summary of the original and the author's reflections after 20 years.

This was significantly easier to read as the thoughts from 1995 are more relatable. After receiving 20 years' worth of feedback, Brooks also modified some of his opinions regarding the matters described in the original book. This was fascinating to read from a historical perspective. I would give this part a rating of 4 out of 5.

Overall, the book provides an interesting look at the evolution of ideas in the field over a 20-year period.

This book delves into the topic of how teamwork is accomplished in software development.

It expounds that architecture, implementation, and realization can operate in parallel. Additionally, it details how to divide time in software development for planning, coding, and testing.

There is also an explanation regarding the failure of the legendary Tower of Babel building construction. Documentation, including how we move forward and backward, and so on - everything else can be found in chapter 18 where all the summaries are written.

This comprehensive exploration provides valuable insights into the various aspects of software development teamwork, covering not only the technical processes but also historical analogies and the importance of proper documentation. It serves as a useful guide for those involved in or interested in the field of software development, offering practical advice and a deeper understanding of the complex interplay of different elements within a software development project.

This work holds more historical significance rather than being a commonly referred book in the present day. Nevertheless, I am glad that I had the opportunity to read it.

I concur with the viewpoints expressed in these two reviews. In particular, the aspects regarding the default male programmer and the overextended Christian perspective are quite notable. Interestingly, this overextension actually leads Brooks to misstate one of his examples.

Nonetheless, I was truly enamored by the positive and pragmatic message that "There is no royal road, but there is a road." I wholeheartedly support both components of this statement. It emphasizes that while there may not be an easy or privileged path to success, there is always a way forward. This message serves as a source of inspiration and motivation, encouraging us to persevere in the face of challenges and to believe that with determination and effort, we can achieve our goals.

Overall, despite its flaws, this book offers valuable insights and a memorable message that can resonate with readers even today.

Dated, unapproachable, and in some ways misogynistic (systemic but unintentional, I'm sure).

I truly understand why this is still the #2 most popular programming book on Safari Books Online (right after Clean Code).

Probably more than half of the lessons and suggestions don't make sense in the modern world of high-level languages, agile software development, and continual development/release.

For instance, in today's programming landscape, the emphasis is on rapid iteration and flexibility, rather than the more rigid approaches advocated in the book.

However, other lessons are still widely applicable. In fact, they are so widely applicable that they are near-universal knowledge already.

Things like self-documenting code being the ideal, adding manpower at the last minute not saving you, and a well-defined specification reducing bugs are all concepts that are still relevant.

I'll echo what some others have said in that I found the last 1/4 of the book (Chapt 16+) the most valuable.

There are still some nuggets of wisdom here, such as the idea of building a computer program rather than growing one.

Or that single line about comments needing to tell *why* you did something, not how you did it.

There are also really strange and downright jarring moments. System development is apparently just like the Holy Trinity. Really? Really?? In what way is system development like The Father, Son, and Holy Ghost? This kind of comparison seems out of place and rather odd.

Overall, while the book has its flaws, it still has some value, especially in the later chapters.