I read this article a long time ago, and I truly believe that it should be required reading for all engineering managers and project managers.

Engineering managers play a crucial role in leading and coordinating teams to achieve engineering goals. They need to have a deep understanding of technical aspects, as well as excellent leadership and management skills. Project managers, on the other hand, are responsible for the successful delivery of projects within the defined scope, time, and budget.

This article likely contains valuable insights and best practices that can help both engineering managers and project managers enhance their skills and performance. It may cover topics such as team building, project planning and execution, risk management, and communication. By reading and implementing the ideas presented in this article, managers can improve their ability to lead teams, manage projects effectively, and achieve better results.

In conclusion, I highly recommend this article to all engineering managers and project managers. It has the potential to be a valuable resource that can help them succeed in their roles and drive the success of their organizations.

It took me an incredibly long time to finally get around to reading this book.

To put it briefly: software ought to be user-friendly; and one cannot achieve that without conceptual integrity; and it's impossible to have conceptual integrity when too many individuals have a say in the architecture. Brooks' reasoning is extremely sound, and he makes references to the (limited) research that was available regarding these topics back in the 1960s.

Moreover, his writing is lucid. Here is one of my favorite passages:

When one hears of disastrous schedule slippage in a project, he imagines that a series of major calamities must have befallen it. Usually, however, the disaster is due to termites, not tornadoes; and the schedule has slipped imperceptibly but inexorably.

In conclusion, there is far more to this book than just the statement "Adding manpower to a late software project makes it later." It offers valuable insights and considerations that are still relevant today in the field of software development and project management.

This famous and legendary book has truly piqued my curiosity about what lies within its pages.

It delves into the nature of software development, with a primary focus on the software project management perspective. Despite being an older book, mainly based on software projects that took place from the 1950s to the 1970s, a significant portion of its content remains highly relevant in today's software projects.

No matter what role you play, whether you're a programmer, an architect, a project manager, or a researcher, reading this book can be extremely beneficial. It provides you with a fundamental thinking framework regarding the nature of software.

One of the valuable lessons it offers pertains to managing people and time in software projects. The author asserts that one cannot directly substitute man and month. In other non-software construction projects, if the goal is to build faster, adding more people is a viable option. However, this does not hold true for software projects. If more new people are added in the middle of a project, there are learning curves and communication overhead that need to be accounted for. As a result, the man-month does not increase linearly.

Another notable lesson is presented in a chapter titled "No Silver Bullet," which states that there is no single technique that can improve the software development process by an order of magnitude within a decade. This proposition is extensively discussed in the book.

Most of the chapters are relatively short, with only a few being longer. Nevertheless, the author employs numerous metaphors, which, as a non-native speaker, I find challenging to fully understand the content. Many of the terminologies are also from the old era, with which I am not entirely familiar. The type of software projects presented is a system product, such as an operating system. At the end of the book, the author shares his views two decades after its publication. I wholeheartedly recommend this book.

There are some really good nuggets of information in this book, and there are also some things that still hold true to this day. I'm not a software engineer, so a good portion of the content was pure drudgery for me. However, I'm not sure if I should fault the book for that. Maybe it's just because I don't have the background knowledge in software engineering. Overall, I would rate this book a 3.7 out of 5. It has its strengths and weaknesses, but it's still a valuable read for those who are interested in the field of software engineering.

Everybody should read this book, not just programmers or project managers.

It is an easy and enjoyable read. There are a total of 9 chapters, but you only need to read 3 of them. You will quickly figure out which ones they are.

When the author starts presenting equations, it is advisable to skip over those parts. What makes this book unique is that while most software books use building construction metaphors, he employs cooking metaphors instead.

The unconscious gender bias, which was typical of that era, is almost comical. He constantly mentions how many "men" are required to complete a project.

I am often astonished by the number of software professionals who have never read this book, never heard of Brook's Law or Second System Syndrome, and as a result, they suffer.

It is truly a pity that such valuable knowledge and insights remain unknown to so many in the field. This book has the potential to transform the way software projects are managed and developed.

Whether you are a beginner or an experienced professional, it is highly recommended that you pick up this book and give it a read. You will not be disappointed.

I spent a great deal of time pondering over leaving a review for this book.

At one point, I was on the verge of simply giving it a one-star review and moving on, but I felt compelled to say something.

This book was hands down the most difficult one I have ever endeavored to read.

If you have an affinity for computer science history, that alone is not a sufficient reason for this to be the book for you.

To be completely honest, I have no idea who else would actually enjoy reading this.

It was so excruciatingly boring that I literally had to halt my reading halfway through.

I then went on to read the entire Harry Potter book series.

Finally, I managed to muster up the mental energy and the courage to complete this book.

If you are even remotely considering reading this, I strongly advise you NOT to!

Trust me on this one, you will thank me later.

I recently re-read this book after recommending it to a colleague. It was mainly out of nostalgia, and I initially planned to just read a few of the more popular essays, such as "The Tar Pit." However, I ended up reading the entire book again and was still amazed by how fresh and insightful it remained, even after over 40 years since its publication. The prose is dense with ideas, yet it is brilliantly clear and often witty. As I now read contemporary writing, whether it's blogs or even books, I deeply lament the loss of this art.

Apart from his bold statements, most notably Brooks' Law, which has been cited to the point of becoming a cliché, what struck me the most this time around was the extent to which his enthusiasm for building systems and leading teams came through. You might expect a grizzled veteran of massive IBM projects to be somewhat jaded, but I personally found his descriptions of what builders love about building to be quite beautiful. If I can be half as enamored with my craft at his age, I'll consider myself lucky.

In my humble opinion, this book ranks right up there with Peopleware and Psychology of Computer Programming as absolutely essential reading for technical leaders. The specific references, even from the 20th anniversary section, are dated (anyone out there a fan of MS Works?). However, 80% of the points made are still as relevant as ever. In fact, the obsolete sections serve as a sobering reminder that your Macbook is essentially a supercomputer that you can bring on the train for your own exclusive use. I'm so grateful that I no longer have to worry about the size of my functions in memory and can use beautiful, interpreted languages like Ruby at web scale, for example, to run this website ;-)

Some reviewers have pointed out the use of only male pronouns, which can be exclusionary. Interestingly, there were actually far more women programmers in 1975 (before the PC era), so I have to assume that this is simply a stodgy style convention (and it was not used in the 1995 add-on chapters). Additionally, there are some religious undertones scattered throughout the book, but they didn't detract from the ideas for me.

Highly, highly recommended. It's a great book to read with your team to share war stories and gain valuable insights into the world of building systems and leading teams.

Boring, in the weeds, and for the most part obsolete.

I managed to get through about three-quarters of it before skipping to the summary at the end. If only I had known about the summary earlier, I would have skipped even sooner. I would most definitely not recommend it.

Notes:

Why is programming fun? What delights can its practitioner expect as a reward?

First is the sheer joy of making things. Just as a child takes delight in his mud pie, so does an adult enjoy building things, especially those of his own design. I believe this delight must be an image of God's delight in creating things, as seen in the distinctness and newness of each leaf and each snowflake.

The programmer, like the poet, works only slightly removed from pure thought-stuff. He constructs his castles in the air, from air, creating through the exertion of the imagination.

The computer also resembles the magic of legend in this regard. If even one character or one pause in the incantation is not strictly in the proper form, the magic simply doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most challenging part of learning to program.

I like the advice given by P. Fagg, an experienced hardware engineer: "Take no small slips." That is, allow sufficient time in the new schedule to ensure that the work can be done carefully and thoroughly, and that rescheduling will not have to be done again.

"If a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming."

The surgeon model of software development:

"A proposal by Harlan Mills offers a fresh and creative solution. Mills suggests that each segment of a large job be tackled by a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member hacking away at the problem, one does the cutting and the others provide him with every support that will enhance his effectiveness and productivity."

A team could consist of:

- the surgeon

- the copilot: does work delegated by the surgeon

- the administrator: interfaces with clients and management, handles the bills, etc.

- the editor: polishes the documentation by the surgeon

- the clerk: maintains records

- the toolsmith: provides file-editing, text-editing, and interactive debugging services, etc.

- the tester: does the testing

- the language lawyer: consultant for the deep lore of a programming language

"The second system effect": for your first major project, you'll play it safe to ensure you can do it. For your second major project, you'll have an inflated sense of confidence and numerous ideas for thrills that you passed over for your first project. Of all the projects you'll undertake, this second one is the most perilous.

Excerpt from The Man Who Sold the Moon:

Coster buried his face in his hands and then looked up. "I know it. I know what needs to be done—but every time I attempt to tackle a technical problem, some bloody fool wants me to make a decision about trucks—or telephones—or some damn thing. I'm sorry, Mr. Harriman. I thought I could do it."

Harriman said very gently, "Don't let it throw you, Bob. You haven't had much sleep lately, have you? Here's what we'll do—we'll pull a fast one on Ferguson. I'll take that desk you're at for a few days and set up something to protect you from such things. I want that brain of yours focused on reaction vectors, fuel efficiencies, and design stresses, not on contracts for trucks." Harriman stepped to the door, looked around the outer office, and spotted a man who might or might not be the office's chief clerk. "Hey you! Come here."

The man looked startled, got up, came to the door, and said, "Yes?"

"I want that desk in the corner and all the stuff on it moved to an empty office on this floor, right away."

He oversaw getting Coster and his other desk moved into another office, made sure the phone in the new office was disconnected, and, as an afterthought, had a couch moved in there too. "We'll install a projector, a drafting machine, bookcases, and other junk like that tonight," he told Coster. "Just make a list of anything you need—to work on engineering." He went back to the nominal chief-engineer's office and happily got to work trying to figure out where the organization stood and what was wrong with it.

Some four hours later, he took Berkeley in to meet Coster. The chief engineer was asleep at his desk, his head cradled on his arms. Harriman started to back out, but Coster roused. "Oh! Sorry," he said, blushing. "I must have dozed off."

"That's why I brought you the couch," said Harriman. "It's more restful. Bob, meet Jock Berkeley. He's your new slave. You remain chief engineer and the top, undisputed boss. Jock is Lord High Everything Else. From now on, you've got absolutely nothing to worry about—except for the little detail of building a Moon ship."

They shook hands. "Just one thing I ask, Mr. Coster," Berkeley said seriously. "Bypass me all you want to—you'll have to run the technical show—but for God's sake, record it so I'll know what's going on. I'm going to have a switch placed on your desk that will operate a sealed recorder at my desk."

"Fine!" Coster was looking, Harriman thought, younger already.

"And if you want something that is not technical, don't do it yourself. Just flip a switch and whistle; it'll get done!" Berkeley glanced at Harriman. "The Boss says he wants to talk with you about the real job. I'll leave you and get busy." He left.

Harriman sat down; Coster followed suit and said, "Whew!" "Feel better?"

"I like the looks of that fellow Berkeley."

"That's good; he's your twin brother from now on. Stop worrying; I've used him before. You'll think you're living in a well-run hospital."

"On a large project, the manager needs to keep two or three top programmers as a technical cavalry that can ride to the rescue wherever the battle is fiercest."

Sometimes the top talent is best utilized as coders rather than managers, so it's crucial to make coding just as attractive as management. Therefore, have equivalent rungs in the hierarchy for coders and management, with equal pay, office space, and support staff. Movement from coding to management is not "promotion" but "transference." There could still be a prestige element, so transferring from a management rung to an equivalent coder rung might need to come with a pay raise.

"How does a project get to be a year late? One day at a time."

"What we do not understand we do not possess." - Goethe

"The programming project converges more slowly the closer one gets to the end, whereas one expects it to converge faster as one approaches the end."

"Partitioning a task among multiple people requires additional communication effort—training and intercommunication." Thus, if you add more people to a team, the benefit of a greater rate of progress will be offset by the new work created by training the new people and redividing the workload.

"My rule of thumb is 1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing."

"Brooks's Law: Adding manpower to a late software project makes it even later."

"Fixing a defect has a substantial (20 to 50 percent) chance of introducing another."

"System debugging, like astronomy, has always been done mainly at night."

I first read this book during my college years and then revisited it after several years of professional coding experience.

Although there are indeed some sections that seem a bit outdated, like the concept of having an analog of a surgical team for coding, many of the suggestions have withstood the test of time.

The two most well-known ones are "no silver bullets" and "adding developers to a late project makes it later." The former implies that no new technology or technique will bring an order of magnitude difference in productivity compared to 10 years ago. This is particularly crucial when dealing with vendors or those who are overly enthusiastic about promoting a new language or process ideology. I believe this nicely complements Robert Glass's观点 that the quality of developers is the most significant factor differentiating productive teams. The second point is more straightforward. The cost of integrating new developers into a project often exceeds the value they can deliver within a reasonable time frame.

There are also some less frequently mentioned lessons that can be learned from the book. For instance, long before the Agile methodology emerged, this book advocated an iterative approach instead of the traditional waterfall development. My favorite lesson in the book is about conceptual integrity. In essence, Brooks is referring to the idea that a piece of software should focus on doing one thing well. If it attempts to fulfill multiple roles, it will likely end up being a poor fit for all of them rather than a good fit for just one. As an example, he mentions several cathedrals that took centuries to build. Those cathedrals that were influenced by egotistical architects in the middle or later stages of construction lack aesthetic consistency and are therefore less appealing than those that adhered to the original style.

Brooks also suggests establishing two independent career tracks for developers. In many organizations, developers are pressured to move into management after reaching a certain level. However, Brooks contends that this is a mistake and that in many cases, it is better to allow some developers to remain in a development role. This requires ensuring that their titles and compensation are on par with those in the management track.

Despite the fact that many of the technology-specific examples in the book are outdated, Mythical Man Month is still a recommended read for every developer.

In 1995, in the preface for the 20th anniversary reprint of “The Mythical Man-Month”, the author Fred Brooks asserted that the fundamental insights in the book remained relevant. More than a decade later, Mary Poppendieck recalled, “A classic book has endured over time. That shows there has been very little change in the past 30 years.” Perhaps this is a useful reminder for us to turn the pages of this precious book and reflect on whether project managers are still following the pitfalls pointed out decades ago.

Surprisingly, to this day, I still find it very uncomfortable to work with projects that require estimating how many Man-Months (or using another unit like “person-days”), even though I know very well that such estimates are just that... estimates. And here is what Brooks said more than 40 years ago: “Man and Month (or person and time) are not interchangeable. Be careful with the concept of Man-Month. Adding people to a late project only makes it later.” At that time, some people may not have agreed, but today, what is known as “Brooks’ Law” has been carefully observed by many project managers.

Although focusing on issues related to people in software project management, Brooks went much further to discuss in detail issues related to tools, methods, processes, or organizations in order to seek a thorough and comprehensive understanding in the field of project management and software development. “The Mythical Man-Month” has become a classic perhaps because readers not only gain an overall perspective but also a very profound and timeless perspective from an experienced person in the industry. Each time it is read, the reader’s thinking is refreshed.

For those who practice Agile, this is an extremely important reference book. Long before the Agile decade, Brooks used reasoning to make judgments that are no different from what is presented in the Manifesto and the principles of Agile:

People determine everything, and tools only serve to help people do their work better (the Agile Manifesto says: individuals and interactions over processes and tools).

Man and Month (or person and time) are not interchangeable. Care must be taken when using Man-Month as a measure for estimation and planning (Agile avoids rigidly estimating MM and focuses on adaptive techniques in planning).

Conceptual Integrity: the integrity of the concept is the core of the quality issue (Agile and Lean call it self-quality or “self-integrity”).

No Silver Bullet: there is no perfect process that can immediately increase the labor productivity of programmers (Agile emphasizes flexibility, adaptability, and variability to suit actual conditions, and the productivity of the team is improved through the process of adaptation, learning, and continuous improvement).

Incremental Build (incremental construction) is better (Agile: growth and iteration).

Empowerment and decentralization (Agile calls this mechanism by the concepts of self-organizing teams and cross-functional teams).

The Waterfall model is wrong! (since it is clear that Man-Month is mythical, then this proposition is an inevitable consequence).

Perhaps the worst feature of the book is that it has receded a bit into the past. When the information technology background is quite different from today, specific technical issues may no longer be close to the readers of the 21st century. It seems a bit difficult to read. But this in turn highlights the timeless truths that do not depend on the context or technological platform, from which we can draw useful lessons. Therefore, this nearly 40-year-old book (first published in 1975) is not only a required additional reading material for students majoring in Software Engineering but also a bedside book chosen by software project managers.

This book was first published in 1975.

Surprisingly, some of its topics remain highly relevant even today.

Not many software books can make such a claim.

Regarding the topics that have become outdated, they served as an interesting window to the past.

They provided a snapshot of the various issues that the industry was striving to solve at that time.

Contemplating the differences between the way things were then, such as printing documentation, using go-to statements, and having machine-specific operating systems, and the way they are now was a rather entertaining exercise.

As for the critiques of sexism, I chose to evaluate them through the lens of history.

It is truly remarkable how society and the industry have advanced to a point where an all-male team seems highly unlikely.

I also noticed that the religious remarks made by the author here and there were somewhat out of place.

However, they are just a speck of dust in what is otherwise a brilliant book.

Overall, this book offers a unique perspective on the evolution of the software industry and is well worth a read.

The best book I’ve read in software project management is from 1975.

It was a time when the field of software project management was still in its infancy, yet this particular book managed to provide profound insights and practical guidance that are still relevant today.

The author's approach was unique, as they combined real-world experiences with theoretical knowledge to present a comprehensive framework for managing software projects.

The book covered a wide range of topics, including project planning, scheduling, resource allocation, risk management, and quality control.

What made it stand out was the clarity of its explanations and the numerous examples and case studies that were used to illustrate key concepts.

Even after all these years, this book remains a must-read for anyone involved in software project management. It serves as a reminder that the fundamental principles of project management have not changed, and that by understanding and applying these principles, we can increase the likelihood of project success.

Whether you are a seasoned project manager or just starting out in the field, this book is sure to provide you with valuable lessons and inspiration.