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.

The Mythical Man-Month: Essays on Software Engineering is a book on software project management by Fred Brooks, whose central theme is that "Adding manpower to a late software project makes it later." This idea is known as Brooks's law, and is presented along with the second-system effect and advocacy of prototyping. The work was first published in 1975, and republished as an anniversary edition in 1995 (ISBN 0-201-83595-9) with the essay "No Silver Bullet" and commentary by the author.

Brooks's observations are based on his experiences at IBM while managing the development of OS/360. He had mistakenly added more workers to a project falling behind schedule. He also made the mistake of asserting that one project -- writing an Algol compiler -- would require six months--regardless of the number of workers involved (it required longer). The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering" because "everybody reads it but nobody does anything about it!"

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.

30 Years later this book is still highly relevent. If your project is in trouble, don't add bodies!

Fred Brooks, the author, is the individual primarily responsible for the IBM System/360, arguably the most successful computer software system built to this point. He is also primarily responsible for the IBM OS/360, which was not as successful. You may find that his frank and honest assessment of why one was successful and one was not provides a map of a right way to develop software and an alert system for what can go wrong. Because of this and the distilled thought and experience present in the book, it would be difficult to find a resource that could better prepare you to develop good software.

I have been a software project manager for many years. One of the biggest problem that I encountered was what the author called as "Second System Effect". Some times, architects were unable to discipline himself to avoid over-designing systems in the second project. Their goals were to build perfect systems that would streamline all processes without considering the costs and patience of business groups. To convince others that they were right, they could come up with various reasons that sounded very reasonable. Unfortunately, they were not aware of the cost, time window for product delivery, and etc.

This books provided insightful view about this effect. If our architects could have read this book, they could avoid such problems and became more successful.

An excellent book and a must-have for all those involved in the software industry. The concepts and problems described in this book are still valid to this day in our modern software development process.
I recommend this book to everyone active in the field of software development.

Essential Reading for Project/Program Managers at all levels. This book exposes the shortcomings of the purely quantitative software engineering approach in building software applications and systems. While data driven risk management, decision system is here to stay where PMs use a variety of metrics to measure, control and report on the progress of a particular project, process or operation - the book explains why that approach alone is no substitute for the human factor...

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,

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.

The philosophy of this book is very similar to lean thinking in that:
a. The more hands touching the software, the more time built into the process - partitioning a task builds in extra time (training and communication).
b. Advocates employee ownership relative to the specific work that they do.
c. Speaks to flow (appropriate people touching the product at the correct time) and teamwork (rewards, interaction and stimulation along with team fusion)
d. Speaks to a system of incremental building (improvements)
e. Value is focused on the customer ("happy user" test)
f. Willingness to accept better ideas/processes
g. Team approach to creating value rather than seeking credit; delegating power down and allowing teams to own the process - "...the quality of the people on a project, and their organization and management, are much more important factors in success than are the tools they use or the technical approaches they take."
h. Interchangeable talent
i. Honesty and encouragement in disclosing status
j. Milestone reports (value-added steps)

The philosophy of this book is very similar to lean thinking in that:
a. The more hands touching the software, the more time built into the process - partitioning a task builds in extra time (training and communication).
b. Advocates employee ownership relative to the specific work that they do.
c. Speaks to flow (appropriate people touching the product at the correct time) and teamwork (rewards, interaction and stimulation along with team fusion)
d. Speaks to a system of incremental building (improvements)
e. Value is focused on the customer ("happy user" test)
f. Willingness to accept better ideas/processes
g. Team approach to creating value rather than seeking credit; delegating power down and allowing teams to own the process - "...the quality of the people on a project, and their organization and management, are much more important factors in success than are the tools they use or the technical approaches they take."
h. Interchangeable talent
i. Honesty and encouragement in disclosing status
j. Milestone reports (value-added steps)

Both Dr. Brooks' original and anniversary book is outdated. The original 1975 was written based on experiences in the 60's and 70's while the 1995 anniversary edition is just a reprint along with chapters/articles written in the late 80's and early 90's. As good and fun-reading as classics are, Software Engineering is not like Archeology and Anthropology where past tools and technology are intently studied and cherished. Dr. Brooks time is long gone and he even admits it; so are the experiences he has in the book. Focus should be placed on more current books that take into account things like object-oriented programming, UML, extreme programming, class-generation software (e.g Microsoft Visio) and other modern tool... which are before the time of the Mythical man-month books. Despite some good information in the book I would not spend much time on it.

Most of the the essays in here are now common sense for any project manager. A lot of the information is obviously dated, its now over 20 years old. However, it is interesting for a historical perspective as well as to see how terminology has changed and developed.

If you're new to project management, or if you are involved in project management at any level, read this book. Its short, and a number of chapters don't apply anymore. They all hold good (and in some cases interesting even though obscelete) information.

Say "The Mythical Man-Month" to any software engineer or project manager and you will get immediate recognition. The concept of this title essay is that, because of communication and other overhead, adding additional engineers to a late software project makes the project finish later, not earlier.

It's a valuable insight, and one which is regularly taken into consideration when making staffing and planning decisions today. But this 300 page book contains much more just this assertion, and since it was written in 1975 (and re-issued in 1995) large chunks of it are so out of date as to be of only academic interest.

There are a few other points that Brooks makes in various essays that are still worth emphasizing today. The one that I found to be most compelling was his claim that for a system to be produced efficiently it has to have a conceptual integrity that can only be achieved if the architecture come from the mind of one or two people. As a product manager, this also started me thinking about whether a new product could succeed if features and requirements were prioritized by more than one or two people. In both cases, Brooks seems to agree that if the work can be broken down into high level chunks with rigorously defined interfaces, as in classic object oriented design, the resulting sub-projects can be delegated out, so long as each piece is once again designed by one or two minds.

Another area that feels plausible, although I can't confirm it from experience, is the "second system effect"; the tendency of product architects on their second project to try to do all of the things they feel they didn't get to on their first one, regardless of whether that fits the new project. Given that we now take for granted that feature creep is bad on a project and that features not wanted by users are bad for a product, some architects may have been trained out of this mental trap, but it seems such a natural human response that it is probably still worth looking for.

But much of the rest of the book has been supplanted by modern practices and processes. The section on programming "surgical teams" for example postulates one secretarial support person per chief programmer - an obvious anachronism today. It also postulates a world where organizations have the option of hiring as many top level minds as they need, something that in today's marketplace is the domain only of companies like Google. (And even in 1975 could probably only have been guaranteed to an IBM manager.)

Much discussion is devoted to the intricacies of bug checking and machine-time sharing on systems now more than 30 years old. Scheduling, documentation, and maintainability issues are touched upon, but except to highlight the fact that theses have been important issues in software development for a long time the discussion does nothing to enlighten the modern practitioner, and may on occasion mislead.

Overall I agree with the consensus that this book was important, perhaps even seminal, in our understanding of many software development issues. But the best way to read it today is to be willing to skim quickly over out of date material to find the nuggets of wisdom that remain relevant.

There are very few great essays on software. If we were to assemble them then this book would undoubtedly sit on the top.

The Mythical Man-Month started of as great piece of software project management book heavily based on the OS/360 project. Despite its age the book has managed to retain value for its readers to this day. A sign of true classics.

One of the well known quote from the book "Adding manpower to a late software project makes it later." has gone on to become a law on to itself "Brook's Law"

I think this book should be made a mandatory reading for all the aspiring project managers.

Pros: Great set of essays on software engineering
Cons: None

Note: Buy the the 20th anniversary edition as this has a new chapter chapter titled "Propositions of The Mythical Man-Month: True or False?" which contains updated stuff for the previous 17 chapters.

Brooks captures in an excellent way the essence of software development and SW development planning. Although the book uses some examples which can be considered old the ideeas are still usefull after 20 years.

There were only two computer programming courses at the University of Alaska - Fairbanks in the fall of 1963, and I took them both. One involved writing machine language code on a key-punch machine to run a stack of punch cards on a surplus IBM 1620 computer. The computer and peripherals were donated to the University by the feds. The 1620 was interesting in that it had 4 kilobytes (that's kilo, not mega, and not giga) of magnetic-core based memory. Along with it's peripherals, the 1620 took up most of a room measuring, as I recall, about 15 feet by 20 feet.

I wrote a little inventory tracking program that fit on five punch cards, and ran without errors. I was enormously proud, and very full of myself at the end of it.

The other course involved the study of symbolic logic. The instructor spent the entire class writing lines and lines of symbolic code on the blackboard. He never spoke a word during this process, so we students dutifully wrote down each symbol without having a clue what any of them meant. This could not and did not last. One day the instructor did not show up for class, and never came again. We never knew what happened to him. I can't help but see these two courses in the same semester as something of a paradigm for the evolution of the computer and information processing industry itself; or at least for my place in it.

I ended up with a degree in English, but I have never been able to break permanently free of my fascination with the gizmos, devices, and plumbing underneath the high concept that we now call information technology (IT). More to the point, for the past 25 years I have been making my living in the business of building interfaces between people who want information, and the ugly black boxes that hold all those magical bits and bytes which we can define, after much effort, as data.

Today I supervise a 2 to 5 person tech team charged with web-enabling a 40 data form/250 data output format system running against a live production database containing 20 + million data records. Because we are such a small team, and we have a very large project - and in the interest of full disclosure - I have become an enthusiast for the kind of software development described as Agile. Agile is defined in the Agile Manifesto ( http://agilemanifesto.org/ ).

Agile is probably not the Silver Bullet that Brooks talks about in Chapter 16 of his excellent series of essays, but it does point the way to it. My own forecast is that some form of a biological or quantum mechanism in the memory architecture of the hardware, mirroring the Agile processes, will eventually make Brook's Silver Bullet a reality... maybe in 10 more years. At that point jobs like mine - essentially software middle-men and women helping non-techs try to convert boxes and machines full of data "bits" into real-time information - will disappear.

Brooks covers the great management issues of software design and development during this period. He shows us in these few well-written essays how we are moving from an almost pure, "top-down," engineering process to an almost pure, "bottom-up," humanistic and cultural one. Because they are essays they are all - like Agile methods - succinct, readable, and to the point. Brooks refers to Jim McCarthy, then of Microsoft, and the development manager of Microsoft's very successful Visual C++ product. In McCarthy's own book, "Dynamics of Software Development," published in 1995, McCarthy talks about the six elements of aesthetic form in the arts: unity, theme, variation, evolution, balance and hierarchy, and how these are critical to developing and delivering great software on time and on budget.

In his preface to the 1974 edition, Brooks refers to Tom Watson of IBM asking why software programming is so hard to manage. This is a great premise for the series because there is no real answer, yet, to Watson's question. It is still - more than 30 years later - very hard to manage software development, and, according to Brooks' 1985 essay, and his 1995 update, there still is "No Silver Bullet."

For tech geeks like myself, or for those who are simply trying to understand what the modern world is all about Brook's essays are must reading. Five stars - No question.

I first saw this book in a college bookstore in 1976. I did not buy it then, and have seen it referenced several times through the years as a significant computer science text. Well, I finally decided to hunt it down and buy it!

After reading it, I am sure glad I did. Even though few might remember the IBM 360, the lessons learned are still valid today -- like "adding resources to a late project makes it later." With proof.

This particular edition includes a follow up by Dr. Brooks written 20 years after the first edition was published. He is very frank about how he has changed his mind over the years (not much, but some), and the whole chapter shows a glimpse of the mind of one of the great men in the field.

Now I wish I had it in hardback...

Few books written about software engineering have value a few years after introduction. But Brooks is time less! This is a must read by anyone who craft is computer science. I would also suggest it to anyone who is in technology managment. It is very readable and very usable.

According to the readers comments for this book, I expected to read more interesting book...
It was fun to read, somethings it was to hard to understand what author had in mind.
There's was to much os/360 in that book :)

If you think it would be outdated it must be because you have not worked long in the business of software engineering. It is not about languages or tools, its about managing people. As much as we like to think we can automate the eccentricities and flaws of people away, we never will. Software engineering is a process done by people - not machines and milestones on paper. In order to succeed the key is not avoiding mistakes; mistakes are inevitable. No, the secret to success is not the process but the people who use the process. Having the tools and understanding to not just handle setbacks of human error but to flourish in them, that is the secret to success. That is what this book tries to convey. Too few seem to get the message.

Fred Brooks wrote the original edition of this book about software development truths in 1975. What's so striking is how his assertions still hold true through all the apparent changes in how software is built, sold, and used. The title refers to Brooks' proven assertion that, for most projects, adding more people to a late software project will make it later. He has many others, including the famous "No Silver Bullet" article. In his 1995 update, he finds that most of his original claims are still true.

Don't be put off by all the examples about punched cards, assembly language, and IBM mainframes. Rather, look for ideas like requirements management, iterative development, and even hints of extreme programming ("surgical teams"). Brooks and others saw these things in 1975, while predicting that software development productivity had no chance of vast gains per decade parallel to hardware gains.

But Brooks hopes you read with optimism. The message is not that software development can't improve. Rather, that the essential part (not the mechanics of coding which has improved somewhat) is people creating machines (software) from pure thought. We can look for improvement methods in our ways of thinking, communicating, and working together.

Even 30 years later most of Mr. Brooks' ideas are still very applicable. In a nutshell, I strongly feel that anyone involved with the software developement life cycle should read this book. It's a pretty easy read, shouldn't take you too long and the knowledge gained from it will be extremely helpful for you and those you work with.

[...]

Not that I am or ever have been a manager of SDEs... but this book seems to hit the nail on the head in regards to my personal observations. Mr. Brooks claims that to be a software developer, one must be an eternal optimist: This will be the last bug! Just one more test cycle, and we'll reach perfection!

Mr. Brooks' way of capturing the essence of what it means to build software resonates with me, and I think it will with you as well.

Even 30 years later most of Mr. Brooks' ideas are still very applicable. In a nutshell, I strongly feel that anyone involved with the software developement life cycle should read this book. It's a pretty easy read, shouldn't take you too long and the knowledge gained from it will be extremely helpful for you and those you work with.

I give further thoughts on the book here.

This is truly a must read. Many have said that this book is quite out date, and I don't outright deny that charge. However, it is still very relevant and helpful. I found at least half of the chapters to be very sharply applicable to today's software engineer. If you have any involvement on any organized software project, please do yourself a favour and get this book!

"For picking the milestones there is only one relevant rule.
Milestones must be concrete, specific, measurable events,
defined with knife-edge sharpness."
[The Mythical Man-Month]
Do not expect theory, nor processes, nor checklists...expect wisdom. Mr. Brooks is, in the form of accessible esseys, portraying his experiences with large software project(s). Majority of the problem areas and lessons learned mentioned in the book are valid till these days. Excellent. Kind regards, Mario.

This book spells out what you already know about writing/managing
sofware/software projects -- and a lot more you never though of.
It's especially interesting to see that the problems haven't
changed much; even with "extreme" and "agile" and all the other
methods and buzzwords.

With no gender bias intended, this book needs to be read by that
manager with a 4 month pregnant programmer who can't understand
why he just can't hire another female programmer and get the job
done in another 2 1/2 months. I've worked for more than one
manager that really did think that way.

One of the most essential software books ever written. Up there
with Kernighan, Ritchie, Van Der Linden, Koenig, et. al.

A classic, and for good reason. Although seemingly dated, Brooks addresses timeless ideas that affect any complex undertaking. A few selected quotes will illustrate why Brooks is never dull:

"our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable."

"when schedule slippage is recognized, the natural (and traditional) response is to add more manpower. Like dousing a fire with gasoline, this makes matters worse..."

"Because the medium [i.e. software] is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified."

For the last 20+ years I've recommended this book to every misguided project planner I've encountered. Everyone who reads it, enjoys it and learns from it. If I had to predict which books on computing would still be worth reading in 100 years, this is the one I'd bet on...

This was one of the first software engineering books I ever purchased (Not the 20th Anniversity Edition). It is still one of my favorite books and I re-read it every year or so. The wisdom in this book has become so ingrained in our industry that people quote it without even realizing it. How many times have you heard someone say, "You can't make a baby in less than nine months no matter how many women are assigned to the task." Or, "Ten Pounds in a five pound sack." Chapter 5, "The Second System Effect," alone is worth the price of the book. 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 it's value.

This is a good book for people who are interested in project management; although there might be some information that programmers might find useful. If you are a software programmer I suggest that you take a look at other book. I find "the pragmatic programmer" promesing

The Mythical Man-Month (M M-M) [Frederick P. Brooks] is often referred to as the most influential Software Engineering books ever. Despite being originally published in 1975 the content remains timeless, equally valuable today.

The central theses of these essays revolve around conceptual integrity - maintaining the product focus in large systems (IBM's OS/360). Brooks touches on many other topics such as the need for a software process, how to manage a team, and the importance of distinguishing between the architecture, design, and development processes. Brooks approaches most subjects from an abstract (managerial) perspective requiring personal interpretation (reading between the lines).

"If a system is to have conceptual integrity, someone must control the concepts." (Chapter 4)

Throughout the book Brooks continually emphasizes the need for remaining analytical (objective), and his famed "No Silver Bullet" essay can be found in Chapter 16.

"Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any-no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware." (Chapter 16)

The Mythical Man-Month is enjoyable, a wealth of information, and easy to read. Some readers may be discouraged, as this book requires personal interpretation, but in doing so the M M-M facilitates inspiration, introspection and debate. Anyone associated with the software industry (introduction level programmer through to management) can appreciate what Brooks has to say.

If you're looking for a comprehensive checklist or an immediately implemental solution then read what other authors like Steve McConnell and Robert L. Glass have to say.

"The tar pit of software engineering will continue to be sticky for a long time to come." (Chapter 18)

The Mythical Man-Month (M M-M) [Frederick P. Brooks] is often referred to as the most influential Software Engineering books ever. Despite being originally published in 1975 the content remains timeless, equally valuable today.

The central theses of these essays revolve around conceptual integrity - maintaining the product focus in large systems (IBM's OS/360). Brooks touches on many other topics such as the need for a software process, how to manage a team, and the importance of distinguishing between the architecture, design, and development process. Brooks approaches most subjects from an abstract (managerial) perspective requiring a great deal of personal interpretation (reading between the lines).

"If a system is to have conceptual integrity, someone must control the concepts." (Chapter 4)

Throughout the book Brooks continually emphasizes the need for remaining analytical (objective), and his famed "No Silver Bullet" essay can be found in Chapter 16.

"Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any-no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware." (Chapter 16)

The Mythical Man-Month is enjoyable, a wealth of information, and moderately easy to read. Some readers may be discouraged, as this book requires personal interpretation, but in doing so the M M-M facilitates inspiration, introspection and debate. Anyone associated with the software industry (introduction level programmer through to management) can appreciate what Brooks has to say.

If you're looking for a comprehensive checklist or an immediately implemental solution then read what other authors like Steve McConnell and Robert L. Glass have to say.

"The tar pit of software engineering will continue to be sticky for a long time to come." (Chapter 18)

The Mythical Man-Month (M M-M) [Frederick P. Brooks] is a timeless classic, equally valuable today as when first published in 1975.

Brooks discusses the technical and managerial issues encountered while developing the IBM OS/360; however the OS/360 is entirely unimportant the timeless truths and insights, between the comments on the OS/360 are what really matter.

Brooks is famous for his "No Silver Bullet" essay, where he underlines the importance of remaining objective, and emphasizes that there is no single universal answer (no silver bullet, no elixir, no philosopher's stone, etc...) in software development. This book (like most good books) facilitates introspection, inspiration, personal interpretation and debate, the numerous citations to this book and the controversial reviews attest.

Selected Quotes from The Mythical Man-Month:

"If a system is to have conceptual integrity, someone must control the concepts." (Chapter 4)

"The wise manager also saves himself a kitty, to be allocated as work proceeds." (Chapter 9)

"Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any-no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware." (Chapter 16)

"Where is next November?" (Chapter 17)

"The tar pit of software engineering will continue to be sticky for a long time to come." (Chapter 18)

The Mythical Man-Month is easy to read, enjoyable, and a wealth of information. Anyone associated with the software industry (introduction level through to management) can appreciate what Brooks has to say. Other authors like Steve McConnell (Code Complete 2nd Edition) and Robert L. Glass have insightful comments on The M M-M.

This book is a classic and should be read.

The Mythical Man-Month (M M-M) [Frederick P. Brooks] is a timeless classic, equally valuable today as when first published in 1975.

Brooks discusses the technical and managerial issues encountered while developing the IBM OS/360; however the OS/360 is entirely unimportant the timeless truths and insights, between the comments on the OS/360 are what really matter.

Brooks is famous for his "No Silver Bullet" essay, where he underlines the importance of remaining objective, and emphasizes that there is no single universal answer (no silver bullet, no elixir, no philosopher's stone, etc...) in software development. This book (like most good books) facilitates introspection, inspiration, personal interpretation and debate, the numerous citations to this book and the controversial reviews attest.

Many readers / reviewers have charged Brooks with being vain, preachy, aristocratic, and have dismissed this text as obsolete or useless. Brooks put it best, there is "No Silver Bullet", and this text is not an exception. The content embodied within this text should be taken conceptually rather than literally, the book should be read in the context of the 70's. I reiterate; this book is equally valid today as the 70's.

Selected Quotes from The Mythical Man-Month:

"If a system is to have conceptual integrity, someone must control the concepts." (Chapter 4)

"The wise manager also saves himself a kitty, to be allocated as work proceeds." (Chapter 9)

"Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any-no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware." (Chapter 16)

"Where is next November?" (Chapter 17)

"The tar pit of software engineering will continue to be sticky for a long time to come." (Chapter 18)

The Mythical Man-Month is easy to read, enjoyable, and a wealth of information. Anyone associated with the software industry (introduction level through to management) can appreciate what Brooks has to say. Other authors like Steve McConnell (Code Complete 2nd Edition) and Robert L. Glass have insightful comments on The M M-M.

This book is a classic and should be read.

The Mythical Man-Month (M M-M) [Frederick P. Brooks] is a timeless classic, equally valuable today as when first published in 1975.

Brooks discusses the technical and managerial issues encountered while developing the OS/360 (IBM); however the OS/360 is entirely unimportant, the timeless truths and insights, between the comments on the OS/360 are what really matter.

Brooks is famous for his "No Silver Bullet" essay, where he underlines the importance of remaining objective, and emphasizes that there is no single universal answer (no silver bullet, no elixir, no philosopher's stone, etc...) in software development. This book (like most good books) facilitates introspection, inspiration, personal interpretation and debate, the numerous citations to this book and the controversial reviews attest.

Many readers / reviewers have charged Brooks with being vain, preachy, aristocratic, and have dismissed this text as obsolete or useless. I think Brooks put it best, there is "No Silver Bullet"; this book is not the silver bullet, and must be read in the context of it's time (1970's). Keep in mind that, the content should be taken conceptually rather than literally.

Selected Quotes from The Mythical Man-Month:

"If a system is to have conceptual integrity, someone must control the concepts." (Chapter 4)

"The wise manager also saves himself a kitty, to be allocated as work proceeds." (Chapter 9)

"Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any-no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware." (Chapter 16)

"Where is next November?" (Chapter 17)

"The tar pit of software engineering will continue to be sticky for a long time to come." (Chapter 18)

The M M-M is easy to read, enjoyable, and a wealth of information. Anyone associated with the software industry (practitioners through to management) can appreciate what Brooks has to say. Other authors like Steve McConnell (Code Complete 2nd Edition) and Robert L. Glass have insightful comments on The Mythical Man-Month.
This book is a classic and should be read.

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

After reading Eric Raymond's book "The Art of UNIX Programming", I realized there were important concepts to learn about the software development PROCESS itself. I had heard of this book, but didn't know much else about it beyond its title. I was stunned when I first saw its original publication date, and almost didn't bother reading it. Luckily for me, I started it, and the first chapter captured my mind so entirely that I didn't put it down until I'd finished the entire book (that same Saturday). This book gave me an insight into how the people of the last 50 years developed the industry of software development, and the insights of Fred Brooks back in 1975 still had an impact on me and the processes I saw in practice at my job and in the various "new" development methodologies I'd heard about in the industry today. I highly recommend this to anyone who's been in the software development environment for at least three years... I think that having less experience would make it difficult for you to step back and look at your own processes from a higher plane... this book would sound more to you like a project manager's work diary rather than the true gem that it is.

I highly recommend reading this book if your a fresh graduate, Software Developer, Project Manager, play an architectural role or are in any way connected software Project irrespective of its size and complexity.

This book was especially important for me, I read it just before I began as program manager with a startup.

The book offers insight into the key roles behind every Project, timelines, product integrity, size, programmer efficiency, productivity, communication and other variables that have a significant impact on Software projects. The author does not preach, instead he offers clear-cut arguments based on his experiences as the architect of OS/360 with IBM. Objectively evaluate them for yourself. This book definitely offers a tremendous learning experience.

A classic book about the development and management of large scale software projects. One of the industries veterans shares his experience and his views gathered mainly during the development process of the IBM OS/360 operating system. Yes, this book is more than 20 years old - which makes it even more interesting (or shall I even say: sad?) to see that many of the observed shortcomings and pitfalls are still the industries greatest problems today. Maybe all management and developers alike should be required to read this book prior to getting a job in the field. Although the book does feature some code examples these are few and far in between, it's main focus lies on the coordination and management aspects of software projects. The somewhat poetical title hints at one of the most stressed points, namely that men are not interchangeable and that twice as many engineers don't cut development times in half. Brooks also offers his opinions on the psychological aspects of systems design, backed up by his experience and occasional statistical evidence. This anniversary edition features a review by the author, where he sums up what points he thinks remain valid in hindsight more than twenty years later.
I particularly enjoyed a beautiful chapter titled: 'The joys of the craft' where Brooks tries to explain what fascinates and captures him about programming. If you happen to be stuck on a frustrating stretch of your project - read this chapter and you'll feel better - I did.

This book has been known for its reputation in software engineering and management classic. The reason is Brooks gave a very good concept about how he see things in a generic, not only in specific way.

In short, the contents in the book describe on nature of the software development, software complexity gave what limitation managers who giving a sight only on top level should be aware, team working and software development roles, and, my favorite, why there is No Silver Bullet in "Essence" and "Accident" for software beast. However, some chapter such as "The other face" seems to be a little dated because the technology changed.

Also, you need to read the last Chapter of "The Mythical Man-Month over 20 years" since this chapter give you the idea what is obsolete and what is not author want to address after the book has been published 20 years back.

Over all, Brooks give such a good reading with his very own experience. Developer will find it knowledgeable and more understanding about conflicting in the development team. Manager will find this book useful for how to really develop the software not the plastic toy. Student will find this book a good concept on software engineering with bring its nature of developing the real software on.

This book has been known for its reputation in software engineering and management classic. The reason is Brooks gave a very good concept about how he see things in a generic way not only in specific way.

In short, the contents in the book describe on nature of the software development, software complexity gave what limitation managers who giving a sight only on top level should be aware, team working and software development roles, and, my favorite, why there is No Silver Bullet in "Essence" and "Accident" for software beast. However, some chapter such as "The other face" seems to be a little dated because the technology changed.

Also, DO NOT forget to read the last Chapter of "The Mythical Man-Month over 20 years" at all cost since this chapter give you the idea what is obsolete and what is not author want to address after the book has been published 20 years back.

Over all, Brooks give such a good reading with his very own experience. Developer will find it very entertaining and aware of what managers are trying to do now which conflicting the practical way. Manager will find this book very useful for the team and to get back to his desk and think what he can improve his attitude about how to really develop the software not the plastic toy. Student will find this book a very good concept on software engineering with giving a sight of its very nature to develop the real software.

This book has been known for its reputation in software engineering and management classic book. The reason is Brooks gave a very good concept about how he see things in a generic way not only in specific way.

In short, the contents in the book describe on nature of the software development, software complexity gave what limitation managers who giving a sight only on top level should be aware, team working and software development roles in the team, and, my favorite, why there is No Silver Bullet in "Essence" and "Accident" for software beast. However, some chapter such as "The other face" seems to be a little obsolete.

Also, DO NOT forget to read the last Chapter of "The Mythical Man-Month over 20 years" at all cost since this chapter give you the idea what is obsolete and what is not author want to address after the book has been published 20 years back.

Over all, Brooks give such a good reading with his very own experience. Developer will find it very entertaining and laugh at your managers behind thier back to see what they are trying to do now which conflicting the practical way. Manager will find this book very useful for the team and to get back to her desk and think what she can improve her attitude about how to really develop the software not the plastic toy. Student will find this book a very good concept on software engineering with giving a sight of its very nature to develop real software.

This book is the real software engineering practice comes to live. Composed by the real experienced software engineer, the book really reflects the real problems we, as a software engineer, will face in all our development cycles.

A good and easy to read book. A must read for everyone involved in big SW projects

A very good read; the software profession is still very young in terms of expecting the system architect to also be the code builder. Imagine handing a building architect a hammer and nail after drafting the construction blueprints...two dependent but distinct professions. This book clearly supports this view.

I read the book and also the reviews and i'm glad to see that many programmers have read it. Unfortunatelly many of them were not able to understand it.

The book is not important for technical data (hardware etc) but for ideas, ideas that come from a huge experience of the author. In project planning you will meet with many problems that are presented here and if you will not be able to remember you will repeat the mistakes that you've made before again and again.

I would recommend read this book for everybody who takes software development seriously. It is not obsolete till now. Yes, some of ideas are the history; some of them are not topical, but the main idea - developing a robust, reliable, and maintainable software is alive.