Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition 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.

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.

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.