Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition

I read this book twenty years or so ago and I have given away several copies of it to others who manage groups of professionals engaged in scientific research and analyses. Although Dr. Brooks writes specifically about his experiences with software development, I feel that a reader could easily replace references to programming or software with the more generic "project" to imagine how Brooks' experiences might apply to their own work. The Mythical Man-Month is a very thoughtful treatment on the structuring of work groups and of the importance of communication within and among teams working on projects.

There are a million little insights into human nature contained in this book. Specifically, the nature of the sort of humans who want to do well, care about doing well, but need the space, time and environment to do well (which is not everyone, but this percentage of the professional community is MUCH greater than most managers seem to believe). It is remarkable how well this book has aged. We continue to invent new methodologies and structural fads in the software and computing industry -- and we continue to stub our toes and rediscover much of what is in this book.

I am a retired computer programmer, 86 years old, a career therein dating from a chance occurrence in 1956, and having been laid off from U.S.Defense Dept. work finally in 1987, when the Cold War ended. I was actively involved in working with the big computer at a Navy base, and involved in choosing a replacement for IBM 7090, so I heard a lot of feedback from aerospace contractors who got the System 360 about which the author is writing. After our assessment of available machines, we chose not to go on with IBM, but got another vendor. I have heard about this book intermittently through the years, always intending to acquire it. When I lately found out about the 1995 edition, I acquired it and read it with great interest. A very good exposition of the nuts and bolts that exist behind large projects. From my experience, as employed by the U.S. government and then by a contractor to it, I concur with all his conclusions, and welcome the 1995 additional material in which he clarifies some matters. Good reading and good advice. Must have!

I love this book. I think it came out before Agile & Scrum took off. However there are so many wonderful concepts about organizing large technically complex projects. So much of what he talks about is just good project planning--forget software development. I am in the chapter now where they are discussing how it is better to have a project which adheres to the original well planned form for a project--rather than sloppily stringing a bunch of updated ideas together with the original base. It is a philosophy which can be related to everyday life--not just software development.

I read the original version when it was published and it's been immensely helpful for years. And now it's updated and even better. If you read and understand this book the you know why your phone and Windows operating system needs to get updates every few days, and why this situation will never change. And it you are interviewing anyone for a software related job then asking, "What do you think about Fred Brooks Mythical Man-Month?" is a great interview question. Anyone rating this book at 3 stars or less will never work for me. I agree with the other commentators here who recommend this book to people in other fields - it describes the complexities of all development tasks although it's very specific to the hardware and software field.

A great book that tells you everything your project manager and lead architect are doing wrong, leading to the depressing realization that there is nothing you can do. Timeless wisdom.

I first experienced this text in 1990s computer science classes, and did not pay it much attention due to the archaic technology references. I recently reread it after pawing through Apollo 11 (50th Anniversary) and other 1960s technology, with new respect for his effort. Many of his ideas that were new knowledge then are norms today. So many gems, just a few: - Psychological safety is an important aspect of creativity - Programmers also hated writing documentation in the 1960s - If you are working in an "accidental" or supporting technology area vs. the actual value-added portion, be prepared for that to go away He did change his thinking regarding compartmentalization, which is clearly stated in the updated edition. One has to get past 1960s details (IBM OS/360, male references) and be a thinking enough person to see the ideas rather than just the words to gain value from this book. Someone at DuckDuckGo is also a fan, it hits on mm-m. Great book, and best wishes to Dr. Brooks.

In the first chapter or so the Mythical Man Month is covered which truly is something every manager, especially within engineering, ought to have in the back of their mind. However, after that the book takes a curious low level turn talking about details around tooling and issues around developing operating systems which for most people would not be relevant at all in these times. As such I would rather recommend reading a more up to date summary of the book than this original.

=== Excellent insights into software === IMHO, Brooks has distilled fundamental truths; you might find his ideas slightly outdated; but all will agree Brooks offers at least excellent insights. To list but a few: build times determine programmer work cycle; agreement on high-level goals is essential; dev tools make a huge difference; visualizing code is a hard problem; programmers are optimists. === Superbly edited === If you've a background in editing (developmental down to line), you will be impressed by this text. "Perfection is achieved, "said Saint-Exupery, "when there's nothing left to take away"; and that is absolutely the case here. Every point is pertinent to the thesis, every sentence is necessary, every phrase concise. (I cannot say the same of Brooks's follow-on book, "Design of Design".) === Classy === Brooks was the project manager for the OS/300, a $5B endeavor that IBM bet its future on, an engineering effort of the highest magnitude, and a spectacular success. But whenever he mentions an aspect or feature where he feels OS/300 excelled, he always gives complete credit to whomever designed that aspect or implemented that feature; and whenever he mentions an area where he feels OS/300 fell short, he takes complete personal responsibility for the shortcoming.

While it would do well to have another refresh from 1995 given the massive changes in software engineering, design, product, and process many of the books most salient points remain valid and proven in 2020. This level of persistent insight in spite of massive technological evolution is shocking and belies the prescience of the first principled approach to deconstructing building software as a discipline. A non exhaustive list of these points includes iterative design and dev informed by user testing, the value and importance of design both for builders and users, and the roles of the architect and the implementor which in many ways also foreshadows the advent of product management as a discipline. Thoroughly enjoyed and would massively enjoy reading a refresh.

I read this book twenty years or so ago and I have given away several copies of it to others who manage groups of professionals engaged in scientific research and analyses. Although Dr. Brooks writes specifically about his experiences with software development, I feel that a reader could easily replace references to programming or software with the more generic "project" to imagine how Brooks' experiences might apply to their own work. The Mythical Man-Month is a very thoughtful treatment on the structuring of work groups and of the importance of communication within and among teams working on projects.

There are a million little insights into human nature contained in this book. Specifically, the nature of the sort of humans who want to do well, care about doing well, but need the space, time and environment to do well (which is not everyone, but this percentage of the professional community is MUCH greater than most managers seem to believe). It is remarkable how well this book has aged. We continue to invent new methodologies and structural fads in the software and computing industry -- and we continue to stub our toes and rediscover much of what is in this book.

I am a retired computer programmer, 86 years old, a career therein dating from a chance occurrence in 1956, and having been laid off from U.S.Defense Dept. work finally in 1987, when the Cold War ended. I was actively involved in working with the big computer at a Navy base, and involved in choosing a replacement for IBM 7090, so I heard a lot of feedback from aerospace contractors who got the System 360 about which the author is writing. After our assessment of available machines, we chose not to go on with IBM, but got another vendor. I have heard about this book intermittently through the years, always intending to acquire it. When I lately found out about the 1995 edition, I acquired it and read it with great interest. A very good exposition of the nuts and bolts that exist behind large projects. From my experience, as employed by the U.S. government and then by a contractor to it, I concur with all his conclusions, and welcome the 1995 additional material in which he clarifies some matters. Good reading and good advice. Must have!

I love this book. I think it came out before Agile & Scrum took off. However there are so many wonderful concepts about organizing large technically complex projects. So much of what he talks about is just good project planning--forget software development. I am in the chapter now where they are discussing how it is better to have a project which adheres to the original well planned form for a project--rather than sloppily stringing a bunch of updated ideas together with the original base. It is a philosophy which can be related to everyday life--not just software development.

I read the original version when it was published and it's been immensely helpful for years. And now it's updated and even better. If you read and understand this book the you know why your phone and Windows operating system needs to get updates every few days, and why this situation will never change. And it you are interviewing anyone for a software related job then asking, "What do you think about Fred Brooks Mythical Man-Month?" is a great interview question. Anyone rating this book at 3 stars or less will never work for me. I agree with the other commentators here who recommend this book to people in other fields - it describes the complexities of all development tasks although it's very specific to the hardware and software field.

A great book that tells you everything your project manager and lead architect are doing wrong, leading to the depressing realization that there is nothing you can do. Timeless wisdom.

I first experienced this text in 1990s computer science classes, and did not pay it much attention due to the archaic technology references. I recently reread it after pawing through Apollo 11 (50th Anniversary) and other 1960s technology, with new respect for his effort. Many of his ideas that were new knowledge then are norms today. So many gems, just a few: - Psychological safety is an important aspect of creativity - Programmers also hated writing documentation in the 1960s - If you are working in an "accidental" or supporting technology area vs. the actual value-added portion, be prepared for that to go away He did change his thinking regarding compartmentalization, which is clearly stated in the updated edition. One has to get past 1960s details (IBM OS/360, male references) and be a thinking enough person to see the ideas rather than just the words to gain value from this book. Someone at DuckDuckGo is also a fan, it hits on mm-m. Great book, and best wishes to Dr. Brooks.

In the first chapter or so the Mythical Man Month is covered which truly is something every manager, especially within engineering, ought to have in the back of their mind. However, after that the book takes a curious low level turn talking about details around tooling and issues around developing operating systems which for most people would not be relevant at all in these times. As such I would rather recommend reading a more up to date summary of the book than this original.

=== Excellent insights into software === IMHO, Brooks has distilled fundamental truths; you might find his ideas slightly outdated; but all will agree Brooks offers at least excellent insights. To list but a few: build times determine programmer work cycle; agreement on high-level goals is essential; dev tools make a huge difference; visualizing code is a hard problem; programmers are optimists. === Superbly edited === If you've a background in editing (developmental down to line), you will be impressed by this text. "Perfection is achieved, "said Saint-Exupery, "when there's nothing left to take away"; and that is absolutely the case here. Every point is pertinent to the thesis, every sentence is necessary, every phrase concise. (I cannot say the same of Brooks's follow-on book, "Design of Design".) === Classy === Brooks was the project manager for the OS/300, a $5B endeavor that IBM bet its future on, an engineering effort of the highest magnitude, and a spectacular success. But whenever he mentions an aspect or feature where he feels OS/300 excelled, he always gives complete credit to whomever designed that aspect or implemented that feature; and whenever he mentions an area where he feels OS/300 fell short, he takes complete personal responsibility for the shortcoming.

While it would do well to have another refresh from 1995 given the massive changes in software engineering, design, product, and process many of the books most salient points remain valid and proven in 2020. This level of persistent insight in spite of massive technological evolution is shocking and belies the prescience of the first principled approach to deconstructing building software as a discipline. A non exhaustive list of these points includes iterative design and dev informed by user testing, the value and importance of design both for builders and users, and the roles of the architect and the implementor which in many ways also foreshadows the advent of product management as a discipline. Thoroughly enjoyed and would massively enjoy reading a refresh.

I am currently a information security student taking my MIS Capstone class. This book was an optional assignment. It is insightful though, it is references to the beginning of software development and much as changed it still is a great book. I would recommend it to those wanting to learn about project management or the software development process.

Yes, it's dated. Yes, you should still read it. The exercise of applying the 1970's world to now mentally should be enlightening. It might be a tougher book to grok for people who were not actually alive in the 1970s. I love how the terminology is all different today but the issues are unchanged.

The first half of the book is a case study of the development of OS/360 in the 1970s: what the problems were, what was tried, what worked and what didn't. While I (and probably many others) snicker at the state of technology then compared to what it is now, I feel that the lessons Brooks learned (and happily relays to the reader) are still relevant and valuable. You certainly will have to abstract the methodology to the current technology we have today, but managerial lessons, as I said, are still relevant, mostly because people haven't changed that much. Basically, adding more people to already-late projects makes things worse. All of the communication and documentation that goes along with large projects are 100% necessary, and the documentation should be about 90% complete before coding starts. I think a wiki would solve both of these issues in one shot, but that's me. The last half of the book is mostly an inner dialogue by Brooks about what he thinks of the lessons he preached, what other people in the industry have said about his book, and his responses to it. I think this is a definite must-read for anyone that programs on large software projects or manages large software projects. Brooks comes right out and says at the beginning that other engineering disciplines already know about all of the project management overhead, which I agree with, because I am in one of those other disciplines. Apparently the programming people don't see it necessary to teach project management as part of a bachelor's degree program, which might explain a lot of the larger programs in the past few decades. I have to admit though, the entire computer industry, both hardware and software, has been through a tumultuous and extraordinarily rapid history. Other disciplines have a much longer history book from which to reflect and design better processes, management or otherwise. Finally, the prose is dry sometimes awkward, which I suppose is typical of the professor types with delusions of eloquence. Despite that, I thought it was overall an easy read, though not as humorous and engaging as some of the other software books I've been through.

Fred Brooks was a software engineer at IBM for some decades and later chair of the UNC CS department. His experience and study makes this recounting invaluable. I felt like I highlighted a sentence on every other page. You must get the second edition and if you read nothing else in it (though it is a short book), you must read the 18th and 19th chapters. The 18th chapter is a summary of all prior chapters while the 19th chapter reflects on the book 20 years later in 1995 -- what changed and what hadn't.

Originally written in the 70's and revised in the 90's, this collection of essays still has relevance to anyone who manages IT. The clear description of the many pitfalls that trap software implementation projects and solid approaches to address them make this a valuable resource. It also provides historical context for the evolution of IT practice: One essay suggests the need for a code librarian, a suggestion that has evolved into tools like subversion and CVS. There are many dated examples. Some illuminate the huge increase is computing power while others a due to the focus of some essays on system, rather than application, software. These can be skipped, and the essay-based structure of the book makes that easy. As someone who directs a group that maintains 180 application, both insourced and outsourced, I think this is a must read.

The Mythical Man-Month is Frederick Brooks' seminal collection of essays vis-a-vis software engineering. From the title, one would imagine that the tome's unifying thesis revolves around the discredited idea that adding more engineers to a project will enable the project to be completed in fewer months, or, to put it another way, that the length of a project's schedule is a linear function of the number of workers assigned to that project. Using graphs based on mathematical formulas and on research conducted by other specialists, Brooks neatly dismantles the person-month myth - demonstrating, in fact, that in many projects (particularly if complex interrelationships are required or if the project is behind schedule), adding more bodies often increases the time required for completion. Despite what the title suggests, however, the above-mentioned topic is but one of many covered by this work. Other topics include the distinction between the "essential" and "accidental" elements of software design; the distinction between building a computer program vs. designing a "programming a systems product" (and the ninefold difference in complexity and time between the two); the quest for software engineering's elusive "silver bullet"; the importance of documentation; the surprisingly small percentage of time that actual writing of code occupies on the timeline of a typical software-development project (as contrasted with time needed for testing and debugging); large teams vs. small "surgical teams" (and why the latter isn't always the answer for all projects); the "buy versus build" dilemma; and many others. Much of the material in the first several chapters of the book appears obsolete (although there are still valuable principles that can be gleaned). However, in chapter 19 (a kind of "retrospective" chapter added 20 years after the original publication date), Brooks amends much of the out-of-date material, e.g., his earlier views on program size and space metrics (rendered all but irrelevant in this age of multi-gigabyte memory), and the degree to which the (albeit hard-to-predict) personal computer explosion and the growth of the Internet. However, even since the time of the book's revision (1995), further explosions have taken place in the computing industry - most notably with regards to Web 2.0, the ubiquity of data-driven Web applications (these even obsoleting many shrink-wrapped products), Web services, and development methodologies such as Agile and XP - that even chapter 19 may seem a little out-of-date to the modern developer. In spite of this, the principles of the book are still applicable: the chapters on estimation, team size, and the dismantling of the person-month myth are enough to make this tome required reading for developers and managers alike - especially the latter.

The Mythical Man-Month is an classic of computer science for a reason. It is not so much that its solutions to software design problems are still relevant — they are frequently decades out of date. Rather, it is a classic for its description of enduring software design *problems*. It’s description of the limits of intra-group communications, the effect of organizational structure on design, and the need for prototyping are still informative, even after nearly forty-five years. It is not the end-all and be-all on its topic by any means, but anyone interested in computer science and even project management will find it worth their time.

The book was in good condition, except nearly every single sentence in the entire book had been underlined. Oddly the only sentences not underlined were the sentences related to the importance of testing.

If you work with any aspect of software (design, construction, support, management) you must read this. So many other books and authors refer to this work that you are at a disadvantage if you don't read it. I was misinformed about the structure of the work before I read it. I assumed that the work was entirely about the Mythical Man-Month problem. It is not. That is only one chapter of the book. Each chapter covers one area and is generally short, to the point and full of nuggets of wisdom. This release is an update to the orginal printing of the book. That is good because some of the original essays are a bit out of date. For example, he stresses that PL/I is the best language for development. Its hardly used at all for new software nowadays. In the new added chapters, Brooks, takes a look back at what he predicted and takes an honest assessment of what he proposed. That is refreshing.

I first read this at my first job out of college 19 years ago. My second journey through the pages of Books' classic, this time the 20th Anniversary Edition, was far more enjoyable. I know much more about the art and science of software now, yet almost every page still held a nugget of wisdom. This book is wonderful no matter where you are in your career. With each reread - even if it's just a chapter or two - the words seem to have been written yesterday by someone you work with. The first time I borrowed it from the library, this time I read the kindle version and keep a paper copy at work when I need some help to back up my philosophies on software engineering. Brooks writes in in a style so even the non-technical can understand, however I don't recommend giving it as a gift to a boss hoping to make him or her "see the light." The core take away is that communication is key to any project's success and gets more difficult the more people involved, specifically by the formula n(n-1)/2. It also addresses many aspects of software that aren't immediately obvious such as: bugs tend to show up the longer a product is live. That runs counter to what many - especially users - think of "mature" software, but a good thing to keep in mind as you "go live" and shift all your developers to other projects.

I read this book some 5 years into my career, and it was like deja-vu. So many of the follies in the world of computers and software projects I had either committed or experienced or been witness to were mentioned I felt why people still blindly march into the dark hell of project failure, when this book has been around for more than 20 years! The biggest point I found was this: adding people to a project only makes it more late. Yet find me a Project Manager who believes otherwise and I will show you 100 others who do not! The only quibble I have with the book is that the author sees it fit to litter the book with religious quotes and observation, about the might of God and His grace - there is a time for religion and there is a time for software engineering pearls of wisdom - and the two should not be mixed.

This was one of the first software engineering books I ever purchased (Not the 20th Anniversary Edition). It is still one of my favorite software books and I re-read it every year or so. Some of Brooks' solutions to common problems are showing their age but the issues he raises are timeless. Some of my favorite chapters are: The Tar Pit - every project I have ever worked on has been a Tar Pit at some point, even the best ones. Brooks shows why this happens. The Mythical Man-Month - the source of the quote "The bearing a child takes nine months, no matter how many women are assigned." and the observation that adding more programmers to a project can actually delay its completion. The sources of scheduling woes were identified by Brooks long ago but we still live with them. The Second System Effect - it amazes me how many times I've seen this happen and still don't realize it until it's almost too late. I need to read this chapter more often. Why Did the Tower of Babel Fail? It's all about communication. The wisdom in this book has become so ingrained in our industry that people quote it without even realizing it.. Brooks is a great writer and makes this an easy read. You could read this book in a couple of days but work a life-time to appreciate its value.

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.

Cover most aspects of modern day software engineering (yes it is engineering). Even the original edition is so relevant! I agree with the author on No Silver Bullet. Really enjoyed the deep dive into why there is no silver bullet.

This book is a classic for a reason. And when the Anniversary Edition was released, rather than revising the existing essays, the author chose to add some new essays, and a bit of an addendum to sort of bring the book up to date. I didn't like this approach. I would have rather had the original essays updated. Leaving the old essays in tact in their original form may be valuable from a nostalgia standpoint, but from a practical standpoint, it makes the reading redundant. It's still a good book, and every software professional should probably read it.

As a non-technical founder of a technical company, this was incredibly helpful to gain insight into the workflow and thought processes of our project manager and developers.

This classic on software engineering made its mark as a study of how to manage large complex projects. Most of the book applies to management in general rather than to software engineering in particular. Here are two examples of the more general insights the author, former IBM manager Frederick P. Brooks, gives readers: an instance of a straightforward insight immediately applicable, and another one we obtain by carefully (!) reading the text. Brooks looks at different types of projects; large projects that can be split into many simple independent tasks will be completed faster if we add more staff to carry them out. However, engineering projects are seldom so simple. Developing software for a new machine requires the machine, which is itself being developed, as well as documentation, which is being prepared! All these tasks relate to each other and require all participants to communicate with each other. The number of communication lines within a team grows exponentially with respect to the number of team members. At some point, adding more men and women actually delays project completion, shattering the myth of the man-month. However we must be careful as we read the Mythical Man Month. This book was written in the seventies about the author's experiences in the sixties, so to understand Brooks correctly, we've got to read him carefully. For instance, Brooks praises PERT charts, saying outright that "there is no substitute" for them. I can't believe this is a blanket endorsement for mindlessly turning out slides and charts by using Microsoft Project! Brooks didn't have MS Project or PowerPoint in the sixties: PERT charts were carefully drawn, often by hand, they were expensive, and they were prepared after thinking things through. We find the true insight a little further down page 156: "The preparation of a PERT chart is the most valuable part of its use". Some of the book is of course more relevant to software engineering. For instance, Brooks's correct 1986 prediction that off-the-shelf, shrink-wrapped software would become the standard way to implement solutions. Just look at Microsoft Office or at SAP's R/3 to see the truth of this. (I'd even say that because powerful software is now so cheap, we've created a glut of output.) Read properly, The Mythical Man Month remains as insightful today as in the seventies and eighties. Brooks's style is friendly but professional and business like. Budding project managers will find many useful insights. Vincent Poirier, Tokyo

Oddly, I was reminded of this classic work whilst reading Chris Date's otherwise quite unremarkable tome, "The Third Manifesto". Date and Darwen cite this classic text admiringly. And this may be the most important contribution to have emerged from their efforts. Having toiled in the Information Technology field for decades, I was, of course, familiar with many of the gems of wisdom that were first articulated by Brooks in this classic book. But it was a true joy and revelation finally to read the book itself from cover to cover. Among the pearls of wisdom contained within these pages are the following: Adding people to a late software project tends to make it later. While it takes one woman nine months to give birth, nine women cannot accomplish the same task in one month. (Hence, the concept of the mythical man month. People and time are not interchangeable commodities.) The factor most dispositive of success in software engineering is conceptual integrity. The first duty of the manager is create a concise and precise written plan. Communication, and its attendant, organization, require as much skill and careful consideration as any other aspect of technical project leadership. There are many, many more wonderful insights contained within the corpus of this outstanding book. While dated, no doubt, the truths that emerge from careful consideration of this important work are that overcoming problems of human interaction are really paramount to success in any task as complicated as software engineering and that the discipline of software engineering is perhaps one of the most wonderfully rewarding career paths open to creative and serious folks even today. This outstanding book rightly deserves an honored place in the library of any person who would succeed in a career in information technology now, or in the future. Yes, it deals with human factors that some may argue can be overcome by technology. But, as Brooks so cogently demonstrates in his wonderful essay on the "silver bullet", the search for the final solution to the problem of software engineering is very much like the hope to slay the mythical werewolf with a silver bullet in that it is a search for an enigma to deal with a chimera. It can't realistically hope to succeed. Finally, in assessing the timeless importance of this classic, we are reminded of the sage advise of that great philosopher, Arnold Schwarzenegger, that, when working with people, everything is political. Yes, the human factors always do matter. And Dr. Brooks has illuminated those human factors of software engineering in a manner both satisfying and edifying. Pick up this timeless classic. Absorb the teachings. And watch your productivity and effectiveness in the discipline soar. God bless.

This is a classic on the topic of software project management. Although the book is quite old, it is surprising that many of the concepts discussed are still applicable to date, particularly around the people aspect. Concepts such as throwing more people onto a late project, will only make it even later meeting the schedule etc. This book is also foundational to the software engineering field and the difference between it and computer science, where the author draws some good parallels around how chemical engineering and chemistry are different. The engineering practices place a bigger emphasis on processes and ensuring consistent outcomes of quality and cost. One major drawback in the book is, because it is old, focuses a lot on resources (hardware and software) that does not apply to the same extent today, as well as the languages (higher level today). I found the book Peopleware to be superior than this one in the area of software people management. Nevertheless, this is a classic that must be read.

As most IT professionals would know, The Mythical Man-Month has for decades been one of the absolute must reads for managers, project managers and other professionals engaged in software development. And eventhough the book was first published some 44 years ago, it still offers valuable insights and notably documentation for software professionals. My only regret is that I didn't read this 20+ years ago.

Reading this as part of a technical book club, we've found this book hit and miss for today's day and age. While it contains some high quality nuggets of wisdom that stand the test of time, some chapters just feel too outdated to mean much. Furthermore, concepts like "Architects" need translation and interpretation in today's world. Agile methodologies seem at odds with the team structures and delivery disciplines outlined here. Altogether, it's a worthwhile read. You'll find memorable chapters filled with prose worthy of internalization and memorization. Just don't expect it to be a manual.

This was the first book I read when taking a job with a project management component for a software development team. My boss at the time recommended it as one of the best books to introduce how software project management was different from traditional project management. He was right, applying the principles in this book helped me to better support my team via resource allocation and planning. I would highly recommend this to anyone entering the software development field, whether as a project manager, developer, or other member on the team.

I did indeed like this book and certainly would recommend it as reading material for software engineering managers and supervisors. Since it was originally written about 20 years ago, it is a bit out of date but is very interesting. As it is said "...you don't know where you are going unless you know where you have come...". I particularly found the mention of "...implementing a counter in transistors..." definitely showed the age of the book :-). However, It is very direct and not drawn out, my favourite part of the book is the very concise but yet detailed summary of the book. A definite winner...

There have been many, many books on software project management lately, but this one still is one of the best. Perhaps the context of older simpler technology helps illustrate the principles more clearly. While some new technologies have an impact on projects, particularly the encapsulation aspect of object-oriented design that allows for real code-reuse, the fundamentals don't change. Further, Brooks shows us why there can never be a "Silver Bullet" that will revolutionize the art. He covers in great detail critical elements such as team structure, development process, conceptual integrity, and scheduling issues (including the myth of the man-month, for which the book is named). Further, since he draws on experience from classic projects such as IBM's OS/360, the book has interesting history as well. My only issue is that with recent increases in power of PCs and languages, many "projects" are now of such scope that they need only involve a single developer, in which case a different paradigm is needed.

This book has been extensively reviewed, so what it there to add? From my perspective, two things. First, if you aspire to being a professional in the software industry and have not read this book, then you must read this book. Of particular interest are Brooks reflections on the past 20 years in this edition. And, secondly, for those that criticize this book as being outdated, I suggest that understanding the history of our profession and the fundamental concepts that Brooks discusses is essential. To paraphrase Santayana, Those who do not understand the past are condemned to repeat it.

I've been working in the software field for just over 10 years now. I generally steer away from computer books that don't deal directly with a particular technology. This book, however, belongs on every shelf in every organization that does software development. I read the first few chapters about a year ago and then purchased my own copy last week since my co-workers were raving about it. I got through the first few chapters again last night and realized once more the importance of this book. As we see the advent of web-enabled computing, we as software engineers also see the increasing preasure to deliver more functionality in less and less time. I believe the concepts in this book will help organizations and firms to stay focused in their software engineering efforts despite all the hoopla (which I rather enjoy) surrounding the web.

A factual and accurate description of what goes wrong when a committee designs software. Also the practical solution. It should be read by every software, firmware or hardware architect and the managers above them. I was hired to get a project out of the "Systems Integration" phase where it had been stuck and burning $ for 18 months. Following this book delivered the project.

This book is a classic on Software Engineering and one of the most often quoted ones. Fred Brooks experienced first hand the development of a huge-scale software development project, the IBM/360, and has learned valuable lessons which he shares in the book. If you're interested in computer science history you will enjoy the description of the pains and joys of software development some decades ago. The article "No Silver Bullet" included at the end of the book is in my opinion the best essay on Software Engineering ever.

This is a classic collection of essays by Frederick Brooks based mostly on the IBM OS/360 project back in 1975. The interesting and surprising fact is that although the technology has improved tremendously for the last two decades, most elements & challenges we face in Software development projects today are nothing different to what it was 20yrs before. Example: throwing more people to a late/troubled project making it delay further. This is the core concept he highlights throughout the book; men and months are not interchangeable. Certain chapters are somewhat outdated especially in the scenarios where he talkes about software development in '70s with low level programming languages, assemblers, punch cards etc. However, the views, the concepts and the lessons are still valid for today's projects. The extra burden on reading definitely offset the value you get and the lessons learn after reading this book. Thus makes it a good investment

This is a classic book for information technology (IT) professionals...It describes many of the common problems encountered when managing complex IT projects... In this context, an example is described wherein adding additional resources to an ongoing project team may not always reduce its project's cycle time and in fact may increase it due to adverse impacts by inexperienced team members...As a non-IT person I found the book very interesting and useful in pointing me to various topics which impact IT project management...As a result, I think it is a good introductory read for anyone.

Textbook was delivered as expected

As everyone else has already said, this remains a classic of software and systems engineering. One thing I have noticed is how the systems engineering elements hold up with time. In my snarkier moments, I like to think that a lot of systems engineering, at least at the beginning, was just software engineering with the serial numbers filed off.

Bought as gift

Almost everyone who works on projects with the IT industry is familiar with Brooks' Law (cited in the review title). But all too few people have read this seminal book on project management and software engineering. Containing resources such as an explanation of Brooks' Law, an incredibly useful breakdown of what kind of documentation should accompany a product, and the new chapters which examine what's changed since the book was first released. The whole world would be saved a great deal of chaos if beginning project managers would start with this fine book.

This is a classic that I read for the first time ages ago. I have loaned my copy out many times until it vanished so I ordered a new one for my self. A great compendium of wisdom about doing projects, even projects that are not software related. Brooks most famous quote seems most applicable for the federal government folks today. "Putting more people on a late project will make it later."

excellent

The one constant in the technology world is change. The biggest complaint that I have as a reader of technology books is that their material seems outdated by the time you pick it up off the shelf. It is nothing less than amazing that a book originally written almost 40 years ago is still applicable today. I can't count how many times while reading the book that I forgot how old the material is and found myself stunned when Brooks throws in a reference to System 360 as if it were a recent release. The central idea behind the book is that as software projects grow, you have to change your approach to managing them. The myth is that you can scale a project linearly. Every resource you add to a project does not shorten development time by a constant rate. In fact, in many cases it could lengthen it. I've seen the result of ignoring this warning a number of times (not pretty). I've also had the privilege of working on a team that respected the axiom. Brooks' idea of the surgical team metaphor for software development is intriguing. I have yet to see it fully implemented as he describes but I've come close to it with a core group of "lead" developers pairing with junior developers to augment their abilities. To the point, this should be the first book you read before taking the helm of a software project.

The classic book on project management. This was written a long time ago, so some of the later chapters are dated, but the first 3 chapters are MUST reading for anyone who wants to manage software engineering. Really takes apart the idea of the man-month and deals with the reality of dividing up work amongst a team.

This is an excellent compendium of knowledge about software development, particularly in relation to project management and efficient team organization. Though it covers more topics than just those, it really demystifies and sheds light on why managing software development is so different and so much more difficult than any other industry. If you have any interest in philosophy, computer science, or good writing, this book is well worth your time. If you are interested in two or three of them, it's a must-read. This is a classic in the software development space and has been extremely influential for many years. Mr. Brooks' writing style is impeccable; he carefully dissects and examines each topic, with the wit and wisdom merited by such a technical field, yet he does it without using a lot of double-speak or unnecessary "fluff" - not a true text but rather a collection of essays, each chapter comes across as a polished, finished product, well-focused on a single topic. This particular edition is also highly recommended. It contains four additional chapters: No Silver Bullet, yet another influential essay by Brooks that was not in the original edition; an overview of all his points (the entire book) in an easy-to-digest format; his thoughts 20 years on from writing the original, and how the industry has changed in that time; and finally, his responses to various criticism he has received over the years specifically in response to the "No Silver Bullet" essay. This is an excellent purchase and a great read.

I originally read this book 20 years ago for a Comp Sci class. Even today I'm amazed at how relevant it still is. Downloaded the kindle version to refresh my memory of it's teachings and trying to get the C-Level people at my company to read it so they can understand why it's "bad" when they keep doing all the stuff in this book.

A timeless book after >30 years. The stable price reflects this classic wisdom. I keep buying copies because the ones I loan out keep getting passed forward. Not technical - this is about team work, process, and approaches.

I've already met a lot of managers and executives that have never read this and possess the detrimental mentality described here, a must-read if you ever manage an IT project.

This book is a classic, but it's from another era. On the plus side, it was one of the first books to recognize that programmer-hours are not interchangeable, that some programmers perform as much as 10 times faster than others. It gives a lot of attention to the ways a corporation can accommodate this variation, and still deliver complex projects on time. On the other hand, the book views software as monolithic: a great edifice that must be designed up front and then built from those specifications. In today's world, we have come to realize that software is a living thing, it constantly morphs as time progresses. The "Agile" software movement is focused on the idea of providing software that does something useful very early, then building upon it bit by bit. The Marx Brothers made some classic movies in their day, but nobody makes movies like that any more. I'd say this book falls into the same category, even the anniversary edition.

The art of computer programming appears to have aspects that are not seen in any other known discipline. Large programs are more complex than small ones. A program twice as large as another is more than twice as complex. So, the management of program development is different than the management of anything else. This is the definitive book on the subject. Is everything in the book absolutely correct in every situation? No, but it's very widely applicable, and better than any other reference available. Is this book the last word on the subject? Probably not. But it has already stood the test of time, despite plenty of serious attempts to displace it over decades. And in most industry, even this book's most basic lessons have yet to be learned. In this volume lies the information to become and stay competitive.

Un libro que narra problemáticas del pasado que sus soluciones son muy aplicables a nuestros tiempos. Tiene un enfoque muy preciso a las personas...mucho que reflexionar.

A lot of the examples are pretty out-dated, but the fundamental principles are sound. Adding more developers to an already late project will only make it later. Managers should read this to avoid common pitfalls and keep your projects on track and running smoothly.

I recommend this book to anyone involved in engineering, not just software people. When it comes to designing complex systems, some big problems cannot be tackled by simply throwing more resources at them. That's a profound and scary observation, especially to those responsible for managing these resources. This book has had a huge impact on the discourse you read about software engineering, particularly on the web (blogs, articles). The views expressed by Mr. Brooks have reached common acceptance in those circles. I must wonder to what extent they have percolated into the workplace however. I suggest contrasting this book with "The Cathedral and the Bazaar" by Eric S. Raymond for a different perspective on large software development and scaling issues, in the open source community.

As a developer, get this book for your boss. Maybe he will understand why he can't assign Richie and Carolina tomorrow to your team so you can deliver that COM API you promised for the day after tomorrow and you could not finish it because you were stuck in the tar pit of your old legacy app, even after you explained to him there is no silver-bullet and you are plannning to throw one away. Best regards,

The information in these essays in almost as valuable now as it was when it was written.

one of my favorite reads great for an upcoming developer best to compare with cathedral and bazaar to see how you will work in a real working environment.

This is the third copy of the book I've purchased. This time as a gift for a coworker. In my mind, Brooks' words are mandatory reading for anybody who presumes they're able to produce software.

Looks like book was copied from another. Preface and Contents fonts and are perfect with high DPI, but all other has lover dpi and borders around text are huge

Many of the principles in this book are truly timeless, and sadly are still not understood in many of todays organizations. The only reason for the 4 starts instead of five is that some of the theses have limited or difficult to find relationships to todays works. I would recommend this book to anyone involved in software development including management and executive level roles.

Ever heard about agile methodologies? That is the fad, this is the essence. It would help extreme programming and the such if they built upon such great work instead of reinventing the wheel each few years, as corporate programmers are wont to do.

I don't read as much as I should but this book is good. Engaging, has a lot of relevant points even though it is old. If you are in the software business and haven't read it, you really should.

Definitely one of the must-read books for any serious software practitioner, and in particular for managers. I find it amazing how timeless the main findings are. I read the 20 year anniversary edition (1995) which examined the main points of the original (1975). Most were just as relevant. Nearly 20 years later, they still are.

Reads Like a Novel. Not the Best format for Technical books. This book contains many helpful tidbits. The first 30 pages were actually quite interesting. However as I began approaching page 100, the content began to become "exhausting". If you are a manager or Leader in the System Design Arena and you are looking for ways to manage better -- this book is for you. However if you are a Programmer interested only in getting better at programming -- Your time can probably be better spent reading a more technical book. Personally, It is my philosophy to try to finish every book that I start -- but I made an exception for this book. It just doesn't seem very applicable to me. But maybe I'll give it a shot in the future if I ever manage System Projects.

Must read for every software engineer. While the book is old the concepts and lessons stand today as they did back then.

Almost everything in this book is common knowledge by now. I personally didn't learn any new concepts and ideas. But I still enjoyed it a lot. I made me understand how ideas of agile evolved for example. How all these practices fit in historical context and why did they succeeded over the others.

A classic. Some ideas are slightly out of date, but most principles are valid as ever

nice

I thought this book was really good. I believe the author does a good job exploding some myths of software development world. If you have ever work on software projects or with software teams, you have probably experience the same issues the author points out in the essays.

In giving testimony before Congress a few years ago on IT issues, I said the following: "Humanity has been developing information technology for half a century. That experience has taught us this unpleasant truth: virtually every information technology project above a certain size or complexity is significantly late and over budget or fails altogether; those that don't fail are often riddled with defects and difficult to enhance. Fred Brooks explored many of the root causes over twenty years ago in The Mythical Man-Month, a classic book that could be regarded as the Bible of information technology because it is universally known, often quoted, occasionally read, and rarely heeded." I have been involved in software engineering for over 25 years, have written many articles and even a few books on the subject. Yet every time I think I've discovered some new insight, chances are I can find it tucked away somewhere in The Mythical Man-Month. And the tarpits and other dangers he lays out plague the IT industry today. I wonder when we will grasp and apply the fundamental insights that Brooks, Jerry Weinberg, and others laid out nearly three decades ago. ..bruce..

This book has provided a great perspective for decades. Now, it's been updated. Anyone who manages software development should read it and think about it. I would suggest first time readers read the last three chapters first, then read them again after starting from the beginning.

Excellent read even for the the network engineer or architect and project manager a lot of wisdom from the development side of techology that can be applied to other disciplines.

If you intend to develop software professionally I highly recommend reading this book. It frames the fundamental difficulties and excitement of developing software and resolves the many emotions involved with development into logical truths.

While this book is not the hottest off the presses so to speak it still has a lot of wisdom to offer. If you plan on managing software projects and want to know the how and why of the way things turn out, you need to read this book. It can save a lot of heartaches and frustrations.

A must read for any serious software developer and those that lead them. There is no magic, just solid engineering discipline, hard work, and a desire to create something of value.

it feels a bit outdated, I mean if you're into software engineering classics then maybe this is for you. I must note that it does have some timeless insights, but most of it feels irrelevant.

Very good book that shows how elements of Project Management in a software development project aren't terribly different from how we manage software projects today. The best part of this book is it's self-review and today's thoughts and views at the end of the book.

This is "Bhagbad Gita" of Software Engineering Concepts. Almost all concepts will be true for ages to come. A must read for aspiring software architects / managers.

It's a really good book, but... just look the photos. It doesn't look like a new book.

Perhaps everyone in computer science has heard The Mythical Man-Month suggested as a book that should be read. As someone in the sector, I finally decided to buy it and see what the fuss was about. And I hate to go against the grain and rate this book so poorly, but I cannot bring myself to see further than 2 stars. To me, the book suffers from two major problems. For one, it is very outdated, and this 'anniversary edition' updates absolutely nothing from the original printing. For a book that is now 40 years old in a sector as fast-moving as software, this is understandable, but I found it puzzling Brooks decided to simply leave the whole script intact in this 1995 re-issue. Worse, the book is consistently described as 'timeless', a word that I feel could not be further from the truth. I will not go into specifics because other reviewers have already effectively described the anachronisms (such as each programmer having a secretary), but I retain the opinion that most of the content in the book is now outdated. Whether this is because the lessons of Brooks have been effectively woven into current best-practices or if the information is simply irrelevant now I cannot say. Additionally, the parts that Brooks does decide to update are questionable. The book itself is 19 chapters; 1-17 are things that have been re-prints of essays from then- 10-20 years ago, and 18 is simply a summary of the book that asks "is this part of the book actually true or not?". This chapter in particular was one that I could not understand. How is it that after 20 years, we are no closer to finding out if any of the information that is put forth is actually true? And why even include such a chapter, a full 20 years after-the-fact? Only in the final chapter are we updated on Brooks's thoughts. I did not find this chapter to be any more illuminating than the rest of the book. Another issue I perceived is that Brooks seems to be exceptionally long-winded in getting his point across. True, this is a problem for many books and does not disqualify a text from being valuable. Still, one would expect a more exacting tone from a book that is so frequently lauded as the 'most important' about software process. The one part that I did find to be interesting and thought-provoking was the essay, No Silver Bullet. The separation of accidental and essential complexity is an intriguing one, even though I disagree with the author's conclusions on that specific point. In my own work, I still think that the vast majority of my time is implementing and verifying that my solution (in code) is correct. If I could think of a solution and immediately have code that corresponds to it, I do think that my effectiveness would increase tremendously. Regardless, the topic is an interesting one that surely does provoke the 'spirited discussion' that Brooks speaks of in the preface. All in all, my suggestion to prospective readers would be to skip the book entirely (possibly reading a summary, if they must know what the main points are) and instead read No Silver Bullet, freely available online. You will gain just as much value but save at least 5 hours.

I thought this was spot on - a good (better) way to think about staffing software projects.

I love this book. It contains so many examples of challenges appearing in software development. Some of them are still relevant for today's world. I fully recommend this book to all people involved in developing software or managing software engineers. It is pure gold.

Perhaps the best book I have read on software development management. An absolute read and a work I have referenced many times in my career. I specifically gifted Kindle versions for a couple of my prior employees after we discussed the topic. I recommend that any software development manager, who wishes to convey the impacts of resource management, share this title with their employees. Superb!!!!

bought it for my pops last xmas... said he had already read it but its a great book

The condition of book was prestine, it was new. The delivery was top notch as well. Zero complains.

Whether you are a junior or senior programmer or not a programmer at all, this book is worth a read. I plan on giving it two reads at least.

As they say "an oldie but a goodie". Short perfect essays about software development. Each as true as the day they were written. Read and heed.

Fantastic book that will be on your top 5 if you work in any capacity related to software development. Gritty and exciting, provides awesome perspective from an insider through time.

This is by far the most definitive book on software engineering.

It's a book for class

I have to confess that I had higher expectations for this book. It's starts well, reviews the basics and the samples are good. Although the age the arguments are very actual. It's a good book indeed but as I said, I had higher expectations for this one.

Timeless. Fundamental book covering software development

It's a great read for the historic accounts of things past and makes some decent confirmations about the current software engineering world we live in.

This book is required reading for anyone working on large Intellectual Property projects (100's to 1000's of contributors) whether it be Software, Silicon, or Aerospace, or other complex systems. This book may not have all the answers, but it does a great job of explaining the problems associated with such an endeavor.

The Mythical Man Month is one of the great classics of computing. Some of the original work feels dated because so much has changed since 1975. But the underlying truths are still valuable today.

Needed for school

The book is a little bit old for a software engineering guide. However it speaks about problems that we still face today.

Absolutely one of the best books on project management, despite its age. I bought several copies for my team. You should too.

This book is from the perspective of a software engineer, but a lot of what's in here is universally true of projects regardless of the field. Essay covers the major pitfalls of poor planning and lots of examples on how one avoids them. The best part is that the book isn't written in a finger pointing manner, but rather a trial and error style report. This means you could probably persuade those management folk, whom you think might not have such great management skills, to give this a read and hopefully re-evaluate things. Also, in response to everyone complaining that this is "dated," I don't see your argument. Yes, Brooks is talking about old projects from the 60's but what is the difference between a current day project and a project of the 60's? It's all the same, however relative, scenario. You have a group of people working to attain a common goal, people are the key factors here, not the project. The terminology and technology Brooks is talking about isn't that's important, it's the concepts and processes.

The Mythical Man-Month is an indisputable classic. It deserves 5 stars even if a little outdated. I do not give 5 stars easily. I'm actually very hard to give high ratings. The reason why I give it 5 stars, when this book is nearly 20 years since the last edition, is because the topics covered in the essays are still very current. I have seen recently projects fall and managers make bad decisions due to lack of wisdom and experience as your going to find in this book. If you still do not know what is the mythical man-month all about. Do yourself a favor and read this book. Please also read the reviews about this myth. McConnell (author of Code Complete) criticize it. However, I have seen this happen. The myth is real and current. I'm 100% sure you heard and read many times the phrase "It is not a silver bullet". If you want to really understand its meaning, do yourself a favor and read this book. I just name two of the essays. There are more essays in the book. All amazing. The wisdom of this book is almost all current. The topics that are not fully current teaches great experiences and have historical value. Many things have changed in software engineering but people with little experience continued making the same mistakes due to ignorance. So, please do yourself a favor and read this book.

An essential book for anyone in the software industry.

I have read this book twice now. Once in college and once again now 5 years later. While I did not get much out of it 5 years ago, now that I have been in the industry a few years, it is a VERY good re-read.

I bought new book but it looks like used beacause it has scratches on covers, bad printed and damaged papers

Book clearly describes the nuts and bolts of software development. Some project examples from the past are still valid today in 2016 and in that way, the book is still relevant to any software engineer or producer.

Wish I’d read this before I took my first coding job

A classic, if a bit dated. Make sure to read, the "No Sliver Bullet", and " The Mythical Man Month" articles. Worth the read, but most of the advice is outdated. Technology such as source control, and ticketing, the internet even, solve many of the problems addressed.

Great book. Shockingly relevant still to this day.

Brooks presents an accessible read on the common pitfalls of software development and how to navigate project management in a mindful way. The revisiting of the original text proves that these tenets are still useful to managers and team members of software projects.

important for understanding how we have come to this point in time in the age of information technology and the managment of it.

This book is a mix of some awesome insights that comes only through real world project management and some dangerous preaching that comes only through not writing code for years. Any arguments with or against this book is in vain because what this book discusses is not mathematical proof but rather empirical observations and extrapolations on few types of software development projects carried out with few types of methodologies. One of the most dangerous things that this book does is recommending and preaching elitist groups, aka Architects. The author actually goes out and claims that architects should never write a line of code!! Madness. I've seen and worked with those kind of "Architects" and to say the list, a person who is blueprinting your million dollar project without knowing the strength and weakness of his tools intimately is bringing disaster to your project. Your policy should be to hire architects who must also prove themselves to be the best coder in the team. I can't overemphasis this point. I see people often stating that they spend less than 10% time on actual programming because they are architect. They start out giving analogy of the person who designs the building but doesn't put his hand son brick and mortar. The analogy is obviously misleading. The bricks that make up building are all same and doesn't require any skills in setting them one over another while a program is made of several different complex constructs, components and libraries and using one thing over another can make a huge difference. Another bad thing that this book does is to draw a picture that big teams are bad and should be avoided at all costs if possible. I think, one has to keep open mind about this. I've always believed that using right methodologies, tight control on recruiting and management structure with isolated smaller groups it is possible to create teams with thousands of developers and deliver the product on schedule. The essential part of methodologies included componentizing the entire product, forming hierarchy of small sub-groups each of who owns these components and talks to each other through well defined APIs, using test driven development and continuous integration. The point is, large teams aren't evil anymore because current state of programming tools and methodologies have evolved to support it very well which wasn't the case 3 decades ago. This book has probably done more damage than good. Still, this book I would rank as one of the must read for any software developer/manager provided you read it AFTER you have significant experience of developing the software with the intention of enhancing your understanding rather than acquiring. You would be most benefited if you look at the book with an eye of a critic instead that of a student.

A classic book updated with more recent thoughts by the author. I bought the ebook and was greatly disappointed by the formatting, especially of Chapter 18, the recapitulation of the author's original theses. On my Kindle 2, for example, only parts of the propositions from Chapter 2 show. Advancing the page doesn't help. Reducing the font size shows that the "missing" material is there but the tiny font makes reading impossible. Buy the paperback, by all means, but Addison-Wesley needs to take this abomination of an ebook.off the market. Professor Brooks deserves far better.

The only thing that stopped me from giving this book a top rating was the author's solemn observation that no executive was likely to work with a terminal in his own office. After all, the executive had far too much paperwork to manage. Right. Well, it was the 1970's. Apart from that and the mysterious absence of female programmers, the book has timeless advice for the management of software projects and team members.

It make you think that the always changing world of IT doesn't really changed that much especially from the management point of view in the last 30 years. Different perspective and a great history lesson. I've really enjoyed it!

Enjoyed the reading... I would recommend this book to anyone who would seek to find out more tips, tricks, techniques, ideas, or how to avoid pitfalls related to computer programming.

Amazing to see how relevant and constant much of the field has remained the same even as they technology has dramatically changed.

Beautiful writing.

Every engineer must read, absorb and apply the lessons condensed in this seminal book. And it's motivating !

This book, although initially written 35 years ago, still has views and opinions that are still valid today. It is amazing how far technology has come, yet how little we have moved in the management of products. Plus, having the official definition of Brook's Law is a definite bonus.

MM-M is a timeless classic on managing large undertakings mainly in software design and production. The matters discussed in the book is still relevant after 40 years.

Although some chapters are dated, the fundamental proposals this book makes about challenges to software development are as valid today as when the book was published.

Absolutely a must read book for all who works on projects, not just for IT.

The author really knows what he is talking about. As a computer programmer, I can tell that the author is speaking from experience. And he makes his points clearly and thoroughly.

This book should be required reading for everyone in the software industry today. It's informative and easy to read and still holds true 30 years after it's original publishing!

The biggest challenge for me was to open first page. This book seems pretty old, but "has million 5stars scores". This is true if you would like to read about CS or software development. But the main theme of this book is software development team. Before last chapter I would like to throw it away in the bin, but at the end of the book I read about wonderful story of the person, who lives and feels the progress of software and hardware industries. This book should be considered only like that - A history of software development and the troubles that coexists in it.

excelent book! nothing else to say!

Love this book. Its great in understanding aspects of software development.

I couldn't put it down because it was like reading a Michael Crichton or John Grisham book. Must for any new computer person.

Even though it is old, many of the ideas presented hold true today.

A lot of pieces of this book are really great, and maybe every software developer chief need to read this at least one time. I found little difficult read it (as a non-natual english user) and also examples given are 20 years old... a lot of reference to long-dead systems and techniques are passed.

Welle written and suprisingly up-to-date for a tech book - specially first chapters

Timeless ...

This updated version is great. The original was great too, but, with these updates it's worth getting, even if you have the original. I got the Audible version and listened to it on a long trip. Then I bought the hard copy.

A must-read for software developers and their managers. I loved it 20 years ago in college and it has not lost any bite with age.

Really good book in my optinion even if it is very old (+20 years). Excellent base principles for software developemnt. I don't think someone who just got out of school can really understand it. -1 star for not vectorizing the diagrams(they are scanned) and not putting the start of chapter drawings. I whould have also decreased half a star for the last part added to the second edition. In my opinion it is too long for the added value...or maybe I just don't get it (yet :)).

I would recommend every software engineer this book. This has everything - from methodologies, project management; and rational and cognitive thinking. This should be a desktop reference for all software engineers.

30+ years after its original publication MMM remains one of the classic works in software engineering. Most of what Brooks writes about his experience developing the OS360 in the 1960s - the stone age of software development - remains true to this day. And much of his experience and advice, sadly, is unknown to or ignored by the current generation of developers. Their loss. As for logistics, the (used) book arrived very quickly and in the advertised condition. I highly recommend both the book and the seller.

Fred Brooks discusses his experiences as a project leader in the 1960s. In the process he promulgates many lessons which he has learned. Some of these are merely opinions, but others are world-class propositions which IT professionals should pay attention to.

This is a great book for software engineering. However, it is not a reference book for you to learn the SE in general, rather it is a book pushing you hard to think the SE in general. The book has a age of more than 20 years, but most conclusions are correct. Being a software architect, how sad I am !

Companies would be wise to follow this recipe.

This book was written by an IBMer during the System 360 implementation. The concepts are still valid after the last few decades. The book helps to present the problems and challenges faced back then by IT project management and it's really still the same challenges we face today. Good historical background to start and understand IT implementations better

Classic book which is proven by time. Don't think it needs more people reviews.

This books is a gold mine in terms of what a Software Development Project are all about. Well worth reading, however most of the Systems refered to are collecters items. That said, the fundamental Message of the book is still valid.

A good read for anyone in the software business

Some of the content in here was dated, but I was surprised at how much seemed to apply to software development today.

This is abook that was written back in the old times of computing, but applies to any large scale project. This is a re-visit by the author that looks at what had changed over 25 years. It turns out not much.

required

The underlying ideas are generally sound, but I can't shake the impression that the author wants to sound like someone from the late 19th century. Language is on the florid side, and generally assumes male gender, etc. It's a strange little time capsule, but it reads quickly and the information that Brooks is focused on comes across fairly easily.