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

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

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

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

Although it was written in 1975, much of the book's information remains surprisingly relevant today. For instance, Fred discusses Artificial Intelligence in Chapter 16, along with expert systems and inference engine technology. It’s understandable to wonder if this information might be outdated, but it still holds value. For small projects, diving into these details might be more than necessary. However, for larger projects, whether you’re a programmer, engineer, project manager, or part of senior leadership, understanding these concepts can be incredibly beneficial. Big projects involve more than just building something — they require the right team, organization, coordination, effective debugging tools, and strategies for deployment. Many of us have experienced OS or system issues and might be curious if developers conduct thorough testing before releasing updates. It’s important to remember that when changes are made, they often need to be validated from scratch, which takes time, resources, and additional costs. A lot comes down to discipline and judgment — skills we can all learn from this book. When you build something, it’s essential to have ways to debug it, and to ensure that users have access to clear and comprehensive documentation, not just a few quick instructions. While mainframes might seem outdated to some of us, it’s interesting to note that many of the core components, like memory and disks, are still in use today. To get the most out of this book, focus on the underlying concepts and proven methods. And most importantly, appreciate Fred's foresight.

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

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

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

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.