Product Description
No book on software project management has been so influential and so timeless as The Mythical Man-Month. Now 20 years after the publication of his book, Frederick P. Brooks, Jr. (best known as the “father of the IBM System 360″) revisits his original ideas and develops new thoughts and advice both for readers familiar with his work and for readers discovering it for the first time.Amazon.com Review
The classic book on the human elements of software engineering. Software tools and development environments may have changed in the 21 years since the first edition of this book, but the peculiarly nonlinear economies of scale in collaborative work and the nature of individuals and groups has not changed an epsilon. If you write code or depend upon those who do, get this book as soon as possible — from Amazon.com Books, your library, or anyone else. You (and/or your colleagues) will be forever grateful. Very Highest Recommendation.
This book is a dated classic. The broad discussion of software management is valid, but without a modern context or critique. I prefer more modern examinations of this topic; Code Complete: A Practical Handbook of Software Construction and Rapid Development by Steve McConnell spring to mind. I would borrow it from the library and buy Code Complete: A Practical Handbook of Software Construction .
Amazon User Rating: 1 / 5
I don’t know about you, but I am not interested in reading a book on managing computer software development as a trip down memory lane. It’s just not a fun way to spend a weekend. I bought this book to improve my skills in the world today, and it was 80% useless. If you are a retired software engineer, and want to relive the good ol’ days of Big Blue, this is the book for you. For the rest of us, it’s a waste of time.
Here are the reasons I think this book is useless.
1. IT IS SEVERELY OUTDATED
Do you know what OS/360 is? How about Exec 8? Scope 6600? Multics? The author uses these as examples throughout, and I have no idea if he is holding them up as good or bad, because I have no idea what they are or what they signify … and the author doesn’t really explain. For the under-40 crowd (under-50? I don’t even know WHEN these were made, or who used them) this is completely mystifying.
It’s not just that the technology has moved on … it’s that the book takes up an awful lot of space dealing with the specifics of the old technology. He makes recommendations about using microfiche, assumes memory is made of gold, suggests that you hire secretaries to key-punch in the hand-written code of the programmers, doesn’t know about version control software like Perforce, etc etc.
Personally, I don’t know who in the software business has the time or energy to read all this old, useless material. It should have been edited out for the re-print. There is certainly no need for it, other than to mark the book as quaint…
2. IT IS RELIGIOUS AND SEXIST
Additionally, I am perpetually put off by the sexism and the religious [stuff] in the book. Religion, you ask? What does this have to do with systems programming? I ask that too. And can’t the editors remove the all-male references in the book? Apparently not.
Here are a few of the totally inappropriate comments he makes about sex and religion that made it hard for me to stomach the book:
“A team of two, with one leader, is often the best use of minds. [Note God's plan for marriage.]” EXCUSE ME??????
“…this delight must be an image of God’s delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.”
“This description, which Miss Sayers uses to illuminate not only human creativity but also the Christian doctrine of the Trinity, will help us in our present task.”
Note: The author refers to all men by their last names alone (Watson, Cosgrove, etc.) but to all women with the title “Miss” (Miss Sayers, Miss Campbell etc.). And he refers to all workers as men, to their output as man-hours or man-months, and to all people in this book as He. There isn’t any balance at all, despite the large numbers of women in the software industry today. Yes, the book was originally written 30 years ago. But this version was published in 1995, and by then the sexism in most publications had appropriately been exised and replaced with a more just system of using He and She interchangeable, and People instead of Men.
The Christian references (to the Tower of Bable, to Noah’s ark, to Reims Cathedral “proclaiming not only the glory of God but also His power to salvage fallen men from their pride”) are also odd, and distracting. A large proportion of the people in the software industry today are not Christian, and this Christian bias is oddly insulting. It is particularly odd because it doesn’t actually add anything of value to the message of the book.
3. IT IS OFTEN WRONG OR POORLY WRITTEN
One chapter is from a paper written in 1986. The next chapter is a comment on all the criticisms written on that paper. Nearly every single one of the author’s comments says, “So-and-so doesn’t agree with my thesis, but he misunderstood what I was trying to say.” He spends over 20 pages explaining what he “meant” to say.
He also has retracted certain sections completely, but he didn’t do this in the main part of the book. He did this in the back, in an outline that is likely to be skipped by most readers. This is a weak way to put out a new version. Hello, take the time to re-write the book with the updated information. Remove the obsolete references and either add new ones or skip concrete examples completely so that the book will be less grounded in one narrow slice of time. Take the responsibility of an author and make the book worth reading.
This book is a must-skip. The editor should have demanded a new version, or not published it at all.
Amazon User Rating: 1 / 5
The original version would have been better if it documented 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’!
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, Dracula, and the Wolfman” 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?
[Novice programmers may find Scott Adams' "Dilbert Principle" better for today's world.]
Amazon User Rating: 2 / 5
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 his essays. 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 turned to 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. claims 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 fantasizes about “pairwise intercommunication”, an exercise that is a demonstration of deliberate poor judgment, or an attempt to explain away failure.
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 programming management job, or even 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 computers and software?
Amazon User Rating: 1 / 5
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.
Amazon User Rating: 2 / 5