on 27 October 1997
Programming languages and development tools may have changed since the first edition of this book, but the problems that arise during a software project development are still the same: lack of communication, division of labor, schedules, etc. Fred Brooks presents case studies where there were such problems and how to face it.
This book is a little bit dated on technical matters, but no book on software management has been so timeless as The Mythical Man-Month.
on 31 May 1996
One of the best technical overview books I've read. Brooks
was project lead for IBMs system 360 software and
articulates truths I have known and experienced personally
during the last fifteen years of software development.
I really enjoyed his understanding of the limits and
capabilities of the human mind, especially bandwidth
inside one mind compared to bandwidth between minds.
I found Brooks's combination of knowledge and humilty
appealing, and the whole book was a delight to read.
on 17 August 2009
This a classic work, and as valuable today as it was in 1975. It is mainly a collection of essays, each focusing a different issue in software engineering and management. The book is full of gems like "All programmers are optimists: All will go well", the famous Brook's law "Adding manpower to a late software project makes it later", "Bearing of a child takes nine months, no matter how many women are assigned" and "An omelette, promised in two minutes, when not ready in two minutes, the customer has two choices - wait or eat it half-cooked. Software customers also have the same choices."
This is a great book for project managers but this certainly doesn't mean it is any less valuable for programmers. The theories Fred. Brooks pioneered 34 years back are now fundamentals of software engineering and project management. Some essays I found valuable in particular are "The Mythical Man-Month" where author discusses managing project schedules, "Plan to Throw One Away" where author discusses the change in user requirements and how to tackle these changes. The best of the lot is "No Silver Bullet", where author compares software construction to werewolves, who appears to be normal but can suddenly turn into monsters. Here author stresses that managing complexity is the essence of software engineering. It includes gems like "Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike. If they are, we make the two similar parts into one, a subroutine. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound" and "The hardest single part of building a software system is deciding precisely what to built. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later". And it goes on to say that software construction is a creative process, the difference between good software design and great one does not necessarily depend on methods used to create the design, instead, great designs come from great designers.
There are a few essays which I didn't find very useful and it is there where this book looks somehow overrated. Anyways my only problem with this book is the language. For non-English speaker at places it becomes a tough read (though it is understandable given that it was written 35 years ago).
Summary: Highly recommended to software project managers as well as programmers.
on 17 December 2004
One of the best books ever written about software development and computing in general.
Yes, it has dated in places but even so it is still very interesting and often incredibly insightful. The title essay (about how throwing additional people at an already late project simply makes it even later) and the essay about Second System Syndrome at particularly good.
It ought to be (but rather sadly is not) a must read for everybody working in IT.
on 11 May 1997
This book is an amazing experience. Whether you come to it with the intention of learning more about how to manage software projects, or simply an interest in the black art of OS programmingit's guaranteed to be an exhiliarating ride. It's not only succinct, refusing to delve into details we wouldn't comprehend, it also contains enough general commentary to make it useful for anyone involved in large projects with creative people (which basically includes just about any form of productivity whatsoever). What makes the book approachable is Brooks' style, which can only be called simple. What keeps you interested in the book are the metaphoric range it has (calling OS programming a tar pit is a considerable reach of the imagination, and yet so obvious) and the rather pragmatic advise Brooks provides at every turn of the page. If you read the book carefully enough, you realize that it makes a series of suggestions about how computing is changing us and the way we create. Brooks may or may not have anticipated this, but his use of the distinction between "essential" and "accidental" difficulties forces one to think long and hard about how these are changing the world of the artist, and the world of art. Just how much writing today is a result of the writer's "liberation" from the static manuscript, either hand/typewritten? What does one lose when this discipline goes away, and what does one gain. Without the accidental difficulties, does tackling the essential ones lead us to inelegant solutions? Or does it simply extend our range, making it possible for more among us to create, and the creative genius to make more than he/she would have otherwise. Throughout the book, what kept coming back to me was the image of a Renaissance painter and his bevy of apprentices. One never knows to what extent the painting's essence was created by the master who drew the outlines and the students who painted the details.
on 19 July 2010
This book is a classic for a reason. Every essay by Frederick P. Brooks Jr. addresses software engineering and proves invaluable for those interested in the history and processes of that field. getAbstract also recommends Brooks' book to anyone who plans or organizes major projects. The collection remains timely due to the clarity of his thought and the educated loveliness of his prose. When Brooks is writing about programming, he's never just writing about programming. He's writing about the complexities of life, and about how best to plan, organize and communicate the concepts you need to overcome those complexities. This 20th-anniversary edition contains new essays in which Brooks reflects on his earlier writing - especially his principles and predications - and responds to his critics. The result showcases a singular, markedly honest mind at work.
on 20 March 2011
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...
on 11 December 1997
Yes, you should buy the 20th-anniversary edition to get "No Silver Bullets", but I am shocked by how little the book has dated overall. Memory may be cheap nowadays, but the book's core message is timeless: "Adding people to an overdue project makes the project later." One of my mentors says "Every working programmer should reread *The Mythical Man-Month* once a year." He's right.
on 6 January 2011
20 years into my career, and this is still the most important book about software engineering I've read, trumping the XP books, Programming Pearls, Programming Perl, Modern C++ Programming and Effective C++, my other favourites. Why? Because it's insightful about the strange and counter-productive mentality that still prevails today, around large software development projects. Everyone involved in software projects should understand the traps laid bare by this book before they embark on a large software development project.
on 28 June 1997
Most of what you'll read in this book will not come as a surprise, you've
heard it before; well, this is the source. These are observation like:
Programmers who really think they found the last bug mess up your planning
(since they didn't), the last 10% of a software project may take more resources
to complete than all used so far and adding resources to a project will only
make it finish even later.
This very book has left a tremendous impression on the industry ever since
it was first printed (1971?) although most mistakes are still made.
Virtually all examples are outdated like "--the date should be changed manually for a leap year, this saves some 50 bytes in main memory--" but
anyone can substitute relevant examples.
The author's main argument is that no "silver bullet" will be invented that
can decrease the time to perform a complex software project significantly.
In this 1995 edition the author admits (in a new chapter) that some of his
conclusions are incorrect but he stays with that argument: the silver bullet
was not invented and will not soon (if ever) be invented.