Note: all page numbers below are for the Kindle version of the book.
This book was absolutely painful at the start. The 20th anniversary edition (...
For further actions, you may consider blocking this person and/or reporting abuse
I read the paperback version of this book (20th anniversary edition 1995) a few years back, when I was getting deeper into being the core Solaris gatekeeper and figuring out how to improve our back-end tools.
At that time Solaris org was ~2500 people and we had many many decades of experience at different methods of software project planning, implementation and delivery.
The core message of TMM which has stuck with me over the years is that the project team size at which you need to get a project/program manager and somebody whose primary focus is tooling is actually quite small. That is exactly what we did with Solaris - though we did rotate people through those roles so that both the benefits and the pain were shared throughout. As a worldwide organisation this was perhaps even more important than in a geographically disparate but still same-country team.
Another core value we had was that everybody was empowered to not only suggest improvements in (or log bugs against) the common build tools, but to also go and fix those tools themselves. Apart from providing a good way for new staff to learn about our dev methods and approaches, it was just a core part of the corporate culture.
That's the one bit of advice that I wasn't so sure about from TMM -- that even groups as small as four people should have an "architect" and a "tools designer". But I don't have much experience in the industry, so I'll have to take your word for it!
My experience is that when you've got fewer than 10 people in the team, many of those roles can be combined - or even just shared around. Though I'd make sure that there's just one architect. If you've got a small team you have to work with and around each other, and I suggest that in that sort of environment everybody should be tasked with process as well as code.
That could get a little interesting if you have people of wildly differing skill levels, but the more senior members should be taking the lead on pulling the juniors up to their level. If you're in a team that small and the seniors aren't doing that, then they're not pulling their weight and you need to find a way to get them to do so.
Glad you eventually got some value out of it... as someone interested in the history of the field, I found the references to older tech to be a nice bonus back when I read it.
Much of the rest is timeless, though IIRC it applies more readily to very large teams writing very large projects from scratch while maintaining large typewritten manuals, and all of it without the benefit of VCS.
So much of what Brooks advocates for (and I don't mean to imply that he was the lone voice) has become conventional -- tracking milestones, avoiding complexity, prototyping, versioning, standardizing tools, separating spec from implementation -- that I doubt many folks reading MMM today would be surprised by any of the takeaways. But I found it interesting both as a primary source and as a window into a time when those practices couldn't be gotten for free or taken for granted.
Peopleware is another classic in this vein, but unlike MMM, its lessons (despite empirical proof) are often ignored.
And though I haven't yet, I'm looking forward to reading Patterns of Software at some point.
I don't follow. Self-documenting code is code that reduces the need for explanation, including comments. As you mentioned, things like "show, don't tell" and "use the parts of the program that have to be there anyway" are what you want -- more specifically, they're preferable to comments, and part of an alternative.
I think you're right. Most of what is discussed in TMM is taken for granted nowadays -- lots of disk space so comments can be interleaved with source code, distributed version control systems, better communication across teams, and more.
Brooks actually recommends Peopleware near the end of TMM, so I'll definitely have to check it out.
Finally, with regards to your last comment, I think it's a matter of usage. From what I can gather from Brooks' writing in TMM, he defines "self-documenting programs" as programs which have the documentation included with the source code, as opposed to typed up and printed in a separate manual somewhere. I think I agree with your more modern definition of "self-documenting code", in that variable names, function names, etc. should be self-explanatory, and therefore not need much documentation or commenting at all. I think it's just a shift in the connotation since 1975.
Oops, I misread you & thought you were advocating for a shift in the recommendation. But that makes perfect sense.
Well certain concepts like
"There's no silver bullet"
"Adding people to a late project makes the project later"
"The second system effect"
Are well known lessons today that Brooks introduced. They are well known these days.
This book started a discussion that continues till this day.
I second Peopleware as an important book who's lessons we'd probably learn from if we went back to them. For example, the concept that come developers were 10x more productive than others was more due to environment than skill or experience. A lesson that is often forgotten today.
I’ve heard some of the high level points of this book, and wanted to get around to reading it but was looking for a post just like this to actually get started with.
Very much appreciated!
Happy to help!