This is Dr. Fred Brooks’ seminal work for project management and software engineering. This cannot be highly recommended enough, and it should be the first book that any project manager, software manager, or development lead becomes acquainted with, in my humble opinion.
Why to read it:
Quite frankly, this will be the “a-ha” book for anyone with some experience in software development. And given its age and the number of low-level maxims that it’s able to convey, it really is more of a primer than an advanced study. But I’m sure that something you’ll read in it will bring about some sort of disagreement, and let’s call these “learning experiences.”
And the best part of all is that this book is management friendly! Yes, this is the book that you can recommend to the manager in your group that just “doesn’t get it.” It’s short, large print, and simply written. It has helped countless managers realize the issues with their behavior in the past, and it can help your situation, as well.
Just a small sample of the multitude of useful maxims that this book teaches:
1. The Mythical Man-Month
This is the eponymous maxim that is at the core of the book. The idea is you can’t say “if it takes 1 person 5 months, it will take 5 people 1 month.” Now in more extreme examples, i.e. “1 person 100 weeks versus 100 people for 1 week” it might seem obvious, but you will quickly run into a manager or lead that will suggest that they can throw a person or two into a project for a brief amount of time to help you “catch back up” on the timeline. This is fool’s gold, as it completely ignores the time the team spends ramping this person up, the communication overhead that is increased by adding another member to the team, etc. This would be a legendary book if it only covered this point, but it does a lot more.
2. There is no silver bullet
This cannot be said often enough. There is no one single strategy, tip, or trick that is going to make everything work well. That’s not saying that a new strategy (such as Agile) can’t address multiple problems. What it is saying is that you can’t rely on that strategy to solve everything. There will always be other things that can be done to squeeze better productivity out of the team, and the good manager will look at all of these. You can also find this “No Silver Bullet” concept discussed and explained in a paper published by Dr. Brooks on the internet.
3. Great programmers write code that a college kid can maintain
Uh oh. A few of you probably bristled, but this is one of those “Learning Experiences” mentioned above! We all know people that optimize code to extreme measures, sometimes to the point where the code is practically unreadable. It’s almost as if the complexity is some badge of honor to be shared only among the worthy. This, however, is one of the worst things you can do for your clients or the product. The simple fact is that at some point, likely sooner than you think, someone else will own the code you’ve written, and struggle to maintain it. Instead of showing off your intelligence by making it unintelligible, strive to make it clean and simple. The ability to break problems down to their simplest components, and then design neat & clean interfaces between those components is not highly valued enough in our industry. The real geniuses are the ones that can code up systems that any idiot can own, because eventually some idiot will! And yes, I pilfered that line nearly directly from Warren Buffett, but he was speaking about business and managers.
4. An architect’s second system will be the most bloated design they ever do
If you don’t believe this, go work with some college grad students. It’s great to work with them because they’re enthusiastic, soak up info like a sponge, and are very sharp. However, the systems that they design can leave something to be desired. They get so caught up in the possibilities that they design around everything, and before you know it you’ve got 9 layers of abstraction when 1 or 2 would do, and way more code maintaining that overhead than should have gone into the project to begin with.
And the basics of documentation, core release events, proper communication, and a lot of other good stuff!
Why not to listen to those who tell you not to read it:
The common criticisms I’ve heard are this:
1. “This isn’t an “a-ha” book, it’s stuff you already know.”
Hmmm, maybe. If you’re experienced with several projects under your belt, you might be checking these items off as things you’ve already learned through experience, but it’s more likely that you were working with someone that DID know this book and was teaching you the lessons organically. And even if you know the lessons, you should read it for the different perspectives on the problems presented, and so that you can properly recommend it to the managers you’re working with that have clearly NOT read it. How do you recommend a book you’ve never read?
2. “The tools and advice it mentions are outdated.”
This is the worst criticism, b/c it’s missing the forest for the trees. Brooks’ team was using assembly language and talking about things like investing in your library, whereas today 90% of projects are created using a library from a 3rd party or service from another team. In other words, the details don’t always apply directly to current situations. This isn’t what you should be reading this for, however. Look at the human nature involved. Look at the “obvious” things that turn out to be proven incorrect. They deal with similar examples to the maxims of today (i.e. “Many eyes make bugs shallow”) that have been completely disproven, so the historical perspective is interesting. So explore the concepts, not the details. And again, the managers that you’ve recommended this to will be looking at the concepts, so they’ll likely be getting the necessary lessons.