Anniversary Edition (2nd Edition) - Essays on Software Engineering

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.

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..

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.

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.

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.

An old book, but still probably THE BEST ONE EVER on software engineering - THE CLASSIC! Very fairly priced, every techie must have, read and re-read. Everyone else will gain a lot of insight into what it takes to build software and why monumental errors are still common.

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.

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.

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.

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.

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 !

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

A classic software management book for good reason. The technology discussed is extremely dated, but the ideas are as relevant today as they were when the book was written. The essays on scaling up a team go into great detail about some of the classic traps managers might be tempted to fall into. From a development standpoint, it goes into a curious amount of detail about documentation. I found the last couple chapters to be the most relevant to myself as a developer where it talks about designing (and redesigning) to avoid bugs, testing at a modular level, and ways to avoid conflict by enabling the team then getting out of their way.

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.

I was deceived by the word "timeless" appearing in the reviews, don't fall for that. The advice is mostly outdated, even the final chapters added in the 2nd edition. The book will serve you well, if you want to study a history of programming (assuming up to date with current state of the art, otherwise even the predictions are faulty). Most of the problems described do have real solutions in the mainstream programmting today. Save your money and buy Joel on Software: ... you won't miss anything from MM-M.

Myself and a group of project managers bought this book for a book club to try and improve our project management skills but we ended up abandoning it. It's more of an historical text that something that has a huge amount of practical current-day advice.

The title of the book is "Mythical Man Month" but there's not much more than a passing reference to that topic. We all know that old saying that 9 women can't make a baby in a month but the author doesn't provide a whole lot more discussion around that area of resourcing. There must be better books on that subject.

It was an effort to find little bits of information that we could apply to our own project management responsibilities and finding those bits required wading through pages of pages of useless info. eg: use microfiche instead of paper for documentation!

So by all means read this if discussions of operating system development in the 1960s interests you but look elsewhere for more practical project management advice.

There was a time when this book rocked. That time has passed. Although there is still useful info here you have to slog through so much old useless references, stories and crap that it seems hardly worth the effort. Particularly when there are other more useful books that I can invest my efforts in.

The Mythical Man Month

When I visited POK in May 1965 the area was abuzz with the story about the high ranking manager who was fired and disgraced. (It was unusual to hear any talk about top management.) Fifteen months later I heard about the success of a new management technique used there. Six years later, after years of practical experience) the results were published. I wonder how much good it did since? In 1975 F.P.Brooks Jr. published this “Essays on Software Engineering”. The first edition explicitly noted his failure, and there was no mention of his successor. The second edition censored the details of his failure, and mentioned his successor in a footnote. He does not explain why one manager succeeded when another failed.

The book does not mention a topic of discussion in the early 1960s: should a manager of programming also be a programmer? GE and RCA said “no”, IBM said “yes”. By 1970 that question was no longer discussed. When the programmers assigned to OS/360 refused to sign off on the specifications and schedules, IBM asked a Director of Engineering to head the project. Within a year the project was further behind schedule than when it started, and grossly over budget! Has any other project before or since used an engineer to manage a programming project?

The most quoted essay is the chapter that repeats the title. It starts out by noting that most software projects go over schedule as if this never happens in other areas! The correct answer is that most schedules are not based on reality, but on the wishes (fantasies?) of upper management. But no one dares to mention this fact! F.P. Brooks Jr. claimed the term “man month” is fallacious. Forty two centuries of human experience says it it NOT if the project is competently managed. Doesn’t he know that “reaping wheat or picking cotton” also has sequential constraints? Most buildings start with detailed plans from experienced builders, and proceed from excavation for the foundation to the roof, sequential constraints.

He talks about “pairwise intercommunication”, an exercise that is a demonstration of deliberate poor judgment, or an attempt to explain away failure. No mention of customer expectations.

In the “Sharp Tools” chapter F.P. Brooks says “I am convinced that interactive systems will never displace batch systems for many applications”. The response is: word processors, spreadsheets, and the internet. Does he lack “the vision thing”? Since 1965 he has never held another management job in programming or in engineering, his area of expertise. Any reason why? Around 1942 Henry Kaiser revolutionized ship building with his modular approach. Could this technique ever be used for software? It requires planning and experience.

I first read The Mythical Man Month about 2 years ago after purchasing it impulsively from the Computer History Museum. At the time, I was actually only about 3 years in the industry as a Software Engineer.

I read it again this week and have taken a lot more out of it than I did the first time around. I wonder whether it might be because I have now seen more 5 years being in the industry, or maybe because I’m becoming more pragmatic in terms of viewing things in a different perspective which differs from my own.

Regardless, this book is almost always one of the “must reads” in the Software Engineering world. Although it is very, very old, Fred Brooks makes some interesting points in which I think hold very well… even for today.

The Tar Pit — Creating production-grade software is hard. A small program or tool is quick to produce with little trouble, but a full-blown industrial grade system to be used by a large customer base… now, that’s a totally different beast. We programmers are optimists, and enjoying our craft is what essentially allows us to get by in the product development lifecycle. Seriously enjoying programming as a passion is what will let you grind out the last feature, or fix that stubborn bug through a brutal debug session to get the job done.

The Mythical Man Month — Adding more people does not mean a faster turnaround time for a project. It depends what components are outstanding in the project, the time constraints, the willingness of the team to train, etc…

The Second System Effect — Conceptually designing a system the second time around is much easier. We generally can anticipate any roadblocks we may encounter due to experience from the first time around. As a dangerous consequence, we tend to add too much into the second system which could lead to a few complications down the line. A successful architect is one that has survived her “second system”.

Plan to Throw Away — Prototypes are prototypes. You don’t have to feel pressured to release the first thing you make that works. Chances are, the customer will not like something about it. Or, maybe even everything… because of that, don’t feel hurt when told to throw your system away and start from scratch. Things change. It is a part of life, and learn the lessons from your attempts.

The Flow-Chart Curse — Flow charts suck. Self documenting code? Better.

No Silver Bullet — I actually didn’t enjoy this essay as much since it has aged quite a bit since it was written… But I did get a bit of entertainment out of Brooks’ mentioning of software reuse. During the early days of computing, more people were willing to spend the time and money to actually build custom software for their business. The reasoning? Well, if you’re going to buy a multi-million dollar machine… then it sounds perfectly reasonable to spend $250,000 on a custom piece of software! The attractiveness of the custom building becomes unattractive once your fleet of computers become much cheaper. Say, $50,000 for a computer that does the job of a $2,000,000 machine ten years ago. All of the sudden, that $250,000 cost to build software isn’t as cool anymore. That’s where buying pre-built software comes in handy. The customer will essentially mold their business practices into what the software is capable of, rather than expecting software to do what they want.

The Mythical Man Month is basically a collection of Software Engineering lessons learned from Fred Brooks during his time at IBM on the System/360 project. Reading this book gave me a ton of insightful thoughts on things which I found readily acceptable. For any points mentioned in which I did not immediately agree with, Brooks’ writing made me think about why it was the case… I internally conclude that any disagreements on some points simply are results of the passage of time and the maturity of the Software Engineering discipline.

I recommend this book and expect about a week or so of reading time along with some self reflection on your own practices too. ;)

The Mythical Man-Month

The original version would have been better if it documented F. P. Brooks failure when he was in charge of the OS/360 Project for one year. Brooks' background is in engineering, not programming. His observations are personal opinion, not Absolute Truth. Those who are impressed with this book appear to have little practical experience. Woe to any programmer who disputes his manager because 'Brooks says so'! [In 1998 there was a publicized firing of someone who quoted Brooks in opposition to management policy.] This 20th anniversary edition reminds me of an old computer program that has been modified to meet new needs. Chapter 16 through 19 have been added, as if there was no need for any other changes in the earlier chapters. But many of the examples in the earlier chapters became obsolete with virtual programming, faster machines, and bigger memories. The programmers of that Golden Age are now on the beach or have gone underground. The new era of Windows and Intel, with offshore jobs, have turned mainframe programmers into a new version of 19th century whalers and buffalo hunters. As I understand it, the problems of OS/360 were due to: a new machine architecture, a new assembler language, and new people with less experience. In time these problems were overcome. Some might compare the effort to the Union Army in 1861-62,

Chapter 16 speaks of the folklore nightmares of werewolves! Is he kidding? Brooks needs to see "Abbot & Costello Meet Frankenstein" to update his knowledge. Software costs have dropped rapidly, as the price for Windows 2000 shows. Brooks confuses mass-production with custom work. You can compare stick-built houses to modular houses, more common outside the USA they say. Software entities are complex because they use general purpose programming languages. A specific purpose language should be less complex. Another advantage of a high-level language is fewer typed characters, and hence fewer typing mistakes that can't be found by a compiler. The advantage to time-sharing is to cut delays, it also makes programming more intensive. The rest of the chapter, pages 188-203 can be skipped. There is a "silver bullet": offshore programming where programmers are rented for $30 a day compared to $50 an hour state-side. Cottage weavers were eliminated by factory production, and whaling ships by kerosene production.

Chapter 17 has Brooks' comments on replies to his "no silver bullet" concept. A silver bullet is an alleged particular solution to a specific problem. Did anyone do a field test for this solution? Perhaps a better symbol is needed? Chapter 18 regurgitates the original book in outline form with Brooks' added comments. Did you find this educational? Chapter 19 asks about the appeal of MM-M. Perhaps it is due to its counter-intuitive claim that adding more labor to a process makes it take longer? Would removing labor from a process make it finish earlier? More new people who don't have experience reduces the average level of knowledge needed for the job. Usually more people means the job is done earlier, as in barn-raising. Talk of a "second system" implies more experience. Brooks failure to understand this suggests some personal problem. The prevention of "featuritis" is accomplished by following the needs of users according to priority. Brooks admits his advice "to throw one away" is wrong (p.265). Page 266 tells of the problem is listening to unproven fantasies. Brooks' comments on "fluidity" (p.280) seems oriented to entertainment not production ("slide presentations") The coalescence of operating systems seems similar to automotive manufacturing (who remembers marque-specific engines?) Is "software engineering" an a priori fantasy? Other engineering creates rules for mass-production (p.286). Programming practice should be concerned with the rules for efficient creation of programs. There is a picture of Brooks on page 228, another on page i. Do you see what I see? What is the usefulness of this book?

While I admit that I don't have much professional experience at this point in my life, I don't see how the bulk of the content in this book could possibly apply to a modern software development operation. Technology and practices have changed a great deal since the 70's, and I feel most of his insights into management will either be completely obvious to the reader or something that was explained to them in college. Many of the management problems faced by the author in his career were also due to limited technology and the studies cited all appear out of date.

Not at all worth the purchase price.

The Mythical Man-Month

The original version would have been better if it documented F. P. Brooks failure when he was in charge of the OS/360 Project for one year. Brooks' background is in engineering, not programming. His observations are personal opinion, not Absolute Truth. Those who are impressed with this book appear to have little practical experience. Woe to any programmer who disputes his manager because 'Brooks says so'! [In 1998 there was a publicized firing of someone who quoted Brooks in opposition to management policy.] This 20th anniversary edition reminds me of an old computer program that has been modified to meet new needs. Chapter 16 through 19 have been added, as if there was no need for any other changes in the earlier chapters. But many of the examples in the earlier chapters became obsolete with virtual programming, faster machines, and bigger memories. The programmers of that Golden Age are now on the beach or have gone underground. The new era of Windows and Intel, with offshore jobs, have turned mainframe programmers into a new version of 19th century whalers and buffalo hunters. As I understand it, the problems of OS/360 were due to: a new machine architecture, a new assembler language, and new people with less experience. In time these problems were overcome. Some might compare the effort to the Union Army in 1861-62,

Chapter 16 speaks of the folklore nightmares of werewolves! Is he kidding? Brooks needs to see "Abbot & Costello Meet Frankenstein" to update his knowledge. Software costs have dropped rapidly, as the price for Windows 2000 shows. Brooks confuses mass-production with custom work. You can compare stick-built houses to modular houses, more common outside the USA they say. Software entities are complex because they use general purpose programming languages. A specific purpose language should be less complex. Another advantage of a high-level language is fewer typed characters, and hence fewer typing mistakes that can't be found by a compiler. The advantage to time-sharing is to cut delays, it also makes programming more intensive. The rest of the chapter, pages 188-203 can be skipped. There is a "silver bullet": offshore programming where programmers are rented for $30 a day compared to $50 an hour state-side. Cottage weavers were eliminated by factory production, and whaling ships by kerosene production.

Chapter 17 has Brooks' comments on replies to his "no silver bullet" concept. A silver bullet is an alleged particular solution to a specific problem. Did anyone do a field test for this solution? Perhaps a better symbol is needed? Chapter 18 regurgitates the original book in outline form with Brooks' added comments. Did you find this educational? Chapter 19 asks about the appeal of MM-M. Perhaps it is due to its counter-intuitive claim that adding more labor to a process makes it take longer? Would removing labor from a process make it finish earlier? More new people who don't have experience reduces the average level of knowledge needed for the job. Usually more people means the job is done earlier, as in barn-raising. Talk of a "second system" implies more experience. Brooks failure to understand this suggests some personal problem. The prevention of "featuritis" is accomplished by following the needs of users according to priority. Brooks admits his advice "to throw one away" is wrong (p.265). Page 266 tells of the problem is listening to unproven fantasies. Brooks' comments on "fluidity" (p.280) seems oriented to entertainment not production ("slide presentations") The coalescence of operating systems seems similar to automotive manufacturing (who remembers marque-specific engines?) Is "software engineering" an a priori fantasy? Other engineering creates rules for mass-production (p.286). Programming practice should be concerned with the rules for efficient creation of programs. There is a picture of Brooks on page 228, another on page i. Do you see what I see? What is the usefulness of this book?

The Mythical Man Month, 1974

When I visited POK in May 1965 the area was abuzz with the story about the high ranking manager who was fired and disgraced. (It was unusual to hear any talk about top management.) Fifteen months later I heard about the success of a new management technique used there. Six years later, after years of practical experience) the results were published. I wonder how much good it did since? In 1975 F.P.Brooks Jr. published this “Essays on Software Engineering”. The first edition explicitly noted his failure, and there was no mention of his successor. The second edition censored the details of his failure, and mentioned his successor in a footnote. He does not explain why one manager succeeded when another failed.

The book does not mention a topic of discussion in the early 1960s: should a manager of programming also be a programmer? GE and RCA said “no”, IBM said “yes”. By 1970 that question was no longer discussed. When the programmers assigned to OS/360 refused to sign off on the specifications and schedules, IBM asked a Director of Engineering to head the project. Within a year the project was further behind schedule than when it started, and grossly over budget! Has any other project before or since used an engineer to manage a programming project?

The most quoted essay is the chapter that repeats the title. It starts out by noting that most software projects go over schedule as if this never happens in other areas! The correct answer is that most schedules are not based on reality, but on the wishes (fantasies?) of upper management. But no one dares to mention this fact! F.P. Brooks Jr. claimed the term “man month” is fallacious. Forty two centuries of human experience says it it NOT if the project is competently managed. Doesn’t he know that “reaping wheat or picking cotton” also has sequential constraints? Most buildings start with detailed plans from experienced builders, and proceed from excavation for the foundation to the roof, sequential constraints.

He talks about “pairwise intercommunication”, an exercise that is a demonstration of deliberate poor judgment, or an attempt to explain away failure. No mention of customer expectations.

In the “Sharp Tools” chapter F.P. Brooks says “I am convinced that interactive systems will never displace batch systems for many applications”. The response is: word processors, spreadsheets, and the internet. Does he lack “the vision thing”? Since 1965 he has never held another management job in programming or in engineering, his area of expertise. Any reason why? Around 1942 Henry Kaiser revolutionized ship building with his modular approach. Could this technique ever be used for software? It requires planning and experience.

This book does not offer any "silver bullet" solutions, but it is a helpful guide to understanding failure. If your ditch-digging project falls behind schedule, adding manpower will probably help, because there is a not a lot of sophistication to digging a ditch. Software, on the other hand, is a project of the mind, and adding more minds to a problem does not necessarily mean the problem will be solved any faster. (One glance at cancer research can tell you that.)

As I write this review (2013-10-21), it has been announced that the Obama administration is seeking the "best and the brightest minds" to bring about a "tech surge" for the healthcare.gov website. Based on this report, the Obamacare team has already violated the first recommendation of this book, and bought into the idea that "more people == faster software development." How many other precepts of this book is the Obamacare team ignoring?

The Second-System Effect:
Some people have been comparing the healthcare.gov fiasco to the troubled roll-out of the Medicare Part D web-based enrollment system. If we operate under the assumption that the same tech bureacrats responsible for that system are responsible for healthcare.gov, then we can hypothesize that the Second-System Effect is also operating: healthcare.gov is likely a bloated mess of code driven by incomprehensible rules.

Conceptual Integrity:
An examination of how the system was supposed to work reveals that the Conceptual Integrity was broken from the very beginning: the original plan was for 50 different States with 50 different systems to all integrate into a single website. Woah. Fortunately, a lot of States opted to have the federal government create their health exchanges, which (in my humble opinion) should have allowed for a simpler design. The results, currently, are still disastrous.

Pilot Plant:
It appears certain that healthcare.gov is not a second system. It is the first attempt-- the one that should have been thrown away; but has instead been served up to the public.

Communication:
It's pretty clear the right hand does not know what the left hand is doing. Some examples: reports that insurance companies are receiving multiple enrollments for a single person with each enrollment different from the previous, with no indication of which one is correct; the fact that early in the process, all of the successful enrolees were given a forced password reset without notification; the story about how system testing for certain aspects of the system do not occur until it went live, and then the tests failed; the anecdote I read about how network infrastructure orders were being placed in the second half of September, when the system was supposed to go live in October-- (network provisioning orders can not always be done overnight... sometimes they need weeks or months to be put into effect.)

Specialized Tools:
This is perhaps my personal favorite: the revelation that healthcare.gov was using an open-source tool for data presentation, but that the open source licensing and authorship information had been stripped out from the code. If some software developer on the Obamacare project is stealing code and passing it off as her own, that is just shameful. On the other hand, if the project management instructed a team member to remove the licensing, then it is shameful and a criminal conspiracy.

Only time will tell if healthcare.gov version 1.0 can be saved, or will have to be completely scrapped. But reading this book can certainly help you understand what happened and why.

For a book on software engineering that has been printed and sold more than quarter million copies, there is little to be said. At the same time it is an eye opener to see how well its messages have been embedded into the software engineering teaching and preaching. Almost in every essay, I found something that was mentioned to me through some medium: explaining the code review comments, explaining the project plan, review comments on software sizing, and so on. The greatness of this book lies in assembling some of the time tested essays that refuse to lose its shine even after four decades.

The book is a collection of nineteen essays including the three added after twenty years of initial publish. The novelty starts from the first page of each essay through the illustration of the central theme of that essay. Those illustrations are drawn from the non-software facets of our lives: mythology, literature, menu card of a restaurant, etc. As a result, we learn the relationship between time and quality through the menu card of a New Orleans' restaurant that says "Good cooking takes time. If you are made to wait, it is to serve you better, and to please you." Also, we see how Noah's ark and the tower of Babel easily fit to explain the complexity of managing large software development teams. The essays also bring up the details of project workbook (present days' software project plan), specification, planning for changes or change requests (Plan to Throw One Away), and above all, the importance of communication with clarity. All of these are relevant today to its fullest extent.

Some of the essays may have little practical use in today's software development projects, simply because the technology, processes, and people skills have leapfrogged many folds in the last four decades. As a result, we see the essay #3 "The Surgical Team" documents nine roles in a team of ten (one role called secretaries require two individuals), largely drawn from Harlan Mill's proposal. About five of those nine roles are no longer required to be filled by full time individuals; some of those like language lawyers are not at all required today due to advancement of standards and open architecture. Even surgery today, does not require so much support staff, largely due to advancement of surgical procedures. Nevertheless, this is a good academic experience to gain insights the challenges faced by the software engineers four decades back.

In its initial edition, the last essay "No Silver Bullet" attempted to establish a hypothesis that there is (or will be) no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity. For the subsequent twenty years, this hypothesis attracted a lot of criticism, adverse and constructive included. In the anniversary edition, the author tried to respond to the adverse critiques by adding one more essay "No Silver Bullet Re-fired". While the proponents and opponents of the hypothesis had their own argumentative strengths, the evolution of software engineering itself has taken some phenomenal turns in last four decades. As a result, software today, is not just for a mainframe, it's for everyday lives of billions around the world. Hence, the book as a whole stands up stronger than any single essay.

For all software engineers, aspirants included, this book is a recommended reading.

It has been almost 15 years since the 20th Anniversary Edition of The Mythical Man-Month came out. Does such a work still hold meaning for today's software industry? Absolutely. Those who do not know history are doomed to repeat it. Frederick Brooks gives an excellent history circa 1975 of software development on the IBM OS/360 project. At the core of his argument is that men and months are not interchangeable on software development projects and further that adding people to a late project makes it later. The upshot of his argument comes down to two aspects: communication complexities and conceptual integrity. One could argue that the latter is constrained by the former.

I have been in the software industry for only 12 years, and I have to admit that I can only partially relate to the specifics of the OS/360 project. I never worked with punch cards, nor have I had limited access to my software execution environment. However, these are only the context of the message and not the message itself. Software development is a highly complex undertaking due to its abstract nature. Many have compared it to trying to nail jell-o to the wall.

One of Brooks keep coping strategies for this complexity is to separate the essential and accidental aspects. Many of the constraints on the OS/360 project were of the accidental nature - limited access to limited resources, programming at a very low level (i.e. assembler), etc. The essential complexity is trying to specify that which exists in the ether, and human communication is the source of much of the difficulty. As the size of the team grows, so does the number of communication nodes. Brooks gives suggestions on how to manage this problem that apply as much today as they did on the OS/360 project.

The last four chapters in the 20th Anniversary Edition are a reflection on what has changed since the original, and the thing that I commend Brooks for the most is an honest evaluation of what is still valid as well as what he was wrong about. This is the main focus of chapter 19, and without it this is not a five star book. Even if they do not have time to read the entire book, *all* leaders in software development organizations should read chapters 16-19. Yes, there have been many new developments since 1995, but the wisdom in these pages is as relevant now as it was 15 years ago. Read it. Digest it. Make it your own. Live it.

Overall: A+

There are few must reads in this industry. This is one. First published in 1975, this work is as applicable to software engineering today as it was then. Why? Because building things, including software, has always been as much about people as it has been about materials or technology--and people don't change much in only 25 years.

In the preface to the First Edition, Brooks states "This book is a belated answer to Tom Watson's probing question as to why programming is hard to manage." This short book (at just over 300 pages) does a masterful job answering that question.

It is here we first hear of Brooks's Law: "Adding manpower to a late software project makes it later." Brooks doesn't just drop that on the reader without explanation. Instead, he walks through the reasoning, discusses how communication in a group changes as the group changes or grows, and how additions to the group need time to climb the learning curve.

Those new to the industry or who are reading the book for the first time might be put off by the examples and technology discussed. Indeed, even in the newly released edition, the original text from 1975 is still present, essentially untouched. So, talk of OS/360 and 7090s, which permeates the text, is perhaps laughable to those not looking deeper. When talking about trade-offs, for example, Brooks offers "... OS/360 devotes 26 bytes of the permanently resident date-turnover routine to the proper handling of December 31 on leap years (when it is day 366). That might have been left to the operator." This is 26 bytes he's talking about!

Brooks provides a light, almost conversational tone to the prose. This isn't to say the observations and analysis were not very well researched. Comparing productivity number with those of Software Productivity Research (SPR), you'll find Brooks came up with the same measurements for productivity as Jones--only 20 years earlier!

Other wisdom is also buried in this work. Brooks declares "The question, therefore, is not whether to build a pilot system and throw it away. You will do that. The question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers." The state of products I buy today tells me not enough people have taken Brooks's observations to heart!

The latest version of the text includes his work "No Silver Bullet." Brooks, who had brought us so much before, had one last "parting shot."

As I started this review I will also end it: this book is a classic. Read it.

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.

Note: Original first edition dates from 1975 (!!!). I've readed the 20th anniversary edition.

The book talks about managing software development, in form of essays. Some of this essays talk about differences of developing a program and a commercial product, why people like/enjoy programming (and what the problems of it are), the problems of estimating projects (the incorrect asumption that gives name to the book of "one man equals one month" and thus to shorten schedules more manpower has to be added), optimism vs reality, slipping schedules because of not enough testing, the problem of "small sharp teams" on large scale projects (no matter how good they are, they are too slow for really big projects) and the surgical team solution (one person does the heavy tasks, some others support), Conceptual integrity, ...

It also talks about separating architecture from implementation (separate the what from the how), the "second system effect" (over-design: as a first version of something goes well, second version gets so much "ideas" that becomes impossible to acomplish), what and how should be documented, communication and meetings handling, programmers productivity, documentation (what, when, how much, where and who), prototyping and refactoring (throwing away "the first system built"), bug fixing and testing, ...

Other topics include tools for development, debugging, testing... One chapter mentions a way of "branching" source code and using sharedrepositories back when Subversion was not even a idea... Good people take as much as possible advantage given the possibilities, even if the tools are quite limited.

Teaches how to think about real facts and not illusions; An example sentence: "Find real solutions to real problems on actual schedules with available resources" (Development is sequential, and so restricted and constrained).

Other topics that the book fantastically covers and defines are debugging (multiple categories, types and situations), testing (he recommends using "dummy objects" and faking input data, our actual "mock object" definition), incremental iterative development (based on small individual changes, maintaining changelogs), estimation problems and misconceptions (doing "problems-actions" negative meetings instead of "status-reviews" ones) or the importance of documentation in any software project (self-documenting code and both good and bad practices).

Also, there are plenty of examples, studies and even calculations/formulae, but one problem here is that samples are a bit outdated sometimes (or too oriented to system design).

Finally, this author is also famous for the essay "There is no silver bullet", which appears in here too. The essay talks about the fake idea of thinking that there will be a "something" that will be valid for everything and ease a lot our development process. Explaining then that each project, each system, each situation is unique and thus, there is no single solution to all of them.

It is amazing how more than 25 years later the same text is valid and still true. It should be mandatory for project managers of IT companies.

Why so few companies follow this book advices then? I wish I knew...

"Throwing more programmers at a project won't get it finished quicker." We've all heard it a thousand times. This is the book of the quote.
This has been a massively influential book and yet we still see ourselves and others making the same mistakes in software development, year in year out. It is certainly one of the 'must read' books that every project manager should read early on in their career. Written by an experienced manager, pretty much everything it says is common sense, yet it is only common sense after you've read it. Reading the book though is only the first (and easiest) step.
The hard part is putting it all into practice in the real world. To do that properly it is not enough to say that you once read it 20 years ago. It needs to be on the shelf by your desk and dipped into now and again. There's nothing so helpful as being told what to do, or not to do, (even when you already know) for contributing to the courage to go and do it. Stick by the principles of this book as far as you can and you won't go far wrong. Serious software development will never be without its headaches but that's no excuse for not doing things better.
"Be the change you're trying to create." - Gandhi

This book is a classic, but recently revised and corrected. The amazing thing is how relevant the book still is to software product development. If you are involved in software, this book is a must-read.
The most valuable part of the book, I believe, is the "plan to throw out" prototype chapter. While the goal is always to make a bigger, better, fast whatever, it is almost an axiom that you WILL build something that has to be discarded and reworked. This absolutely happens every time, I can tell you from first-hand experience. Therefore it is vital to plan to throw out so you can migrate your users to whatever will follow. If you dream that the first product is THE ONE, you risk abandoning them on a product that will inevitably evolve. Planning the throw-away also helps meet the schedule goals by setting reasonable milestones that can be met.
In my role as a product manager for a top-selling software product in its class, I found that the Mythical Man-Month was absolutely vital. However, some additional reading is recommended; Walker Royce's Software Project Management was published in 1998 and adds the dimension of software project evolution. This goes into more detail why you can't write all the specifications upfront, and even if you do, they are certain to change by the time the product is released.

The Mythical Man-Month

The original version would have been better if it documented F. P. Brooks failure when he was in charge of the OS/360 Project for one year. Brooks' background is in engineering, not programming. His observations are personal opinion, not Absolute Truth. Those who are impressed with this book appear to have little practical experience. Woe to any programmer who disputes his manager because 'Brooks says so'! [In 1998 there was a publicized firing of someone who quoted Brooks in opposition to management policy.] This 20th anniversary edition reminds me of an old computer program that has been modified to meet new needs. Chapter 16 through 19 have been added, as if there was no need for any other changes in the earlier chapters. But many of the examples in the earlier chapters became obsolete with virtual programming, faster machines, and bigger memories. The programmers of that Golden Age are now on the beach or have gone underground. The new era of Windows and Intel, with offshore jobs, have turned mainframe programmers into a new version of 19th century whalers and buffalo hunters. As I understand it, the problems of OS/360 were due to: a new machine architecture, a new assembler language, and new people with less experience. In time these problems were overcome. Some might compare the effort to the Union Army in 1861-62,

Chapter 16 speaks of the folklore nightmares of werewolves! Is he kidding? Brooks needs to see "Abbot & Costello Meet Frankenstein" to update his knowledge. Software costs have dropped rapidly, as the price for Windows 2000 shows. Brooks confuses mass-production with custom work. You can compare stick-built houses to modular houses, more common outside the USA they say. Software entities are complex because they use general purpose programming languages. A specific purpose language should be less complex. Another advantage of a high-level language is fewer typed characters, and hence fewer typing mistakes that can't be found by a compiler. The advantage to time-sharing is to cut delays, it also makes programming more intensive. The rest of the chapter, pages 188-203 can be skipped. There is a "silver bullet": offshore programming where programmers are rented for $30 a day compared to $50 an hour state-side. Cottage weavers were eliminated by factory production, and whaling ships by kerosene production.

Chapter 17 has Brooks' comments on replies to his "no silver bullet" concept. A silver bullet is an alleged particular solution to a specific problem. Did anyone do a field test for this solution? Perhaps a better symbol is needed? Chapter 18 regurgitates the original book in outline form with Brooks' added comments. Did you find this educational? Chapter 19 asks about the appeal of MM-M. Perhaps it is due to its counter-intuitive claim that adding more labor to a process makes it take longer? Would removing labor from a process make it finish earlier? More new people who don't have experience reduces the average level of knowledge needed for the job. Usually more people means the job is done earlier, as in barn-raising. Talk of a "second system" implies more experience. Brooks failure to understand this suggests some personal problem. The prevention of "featuritis" is accomplished by following the needs of users according to priority. Brooks admits his advice "to throw one away" is wrong (p.265). Page 266 tells of the problem is listening to unproven fantasies. Brooks' comments on "fluidity" (p.280) seems oriented to entertainment not production ("slide presentations") The coalescence of operating systems seems similar to automotive manufacturing (who remembers marque-specific engines?) Is "software engineering" an a priori fantasy? Other engineering creates rules for mass-production (p.286). Programming practice should be concerned with the rules for efficient creation of programs. There is a picture of Brooks on page 228, another on page i. Do you see what I see? What is the usefulness of this book?