And something that wasn't a book but made a huge impact was Eric Ries's blog, Startup Lessons Learned, circa 2009. He correctly spotted that things like Extreme Programming are generic software development processes, but that in specific domains you could take advantage of their flexibilty to enable new business practices, as in Blank's "Customer Development" process.
When I met Fred Brooks, I had no idea who he was. He was just another grandparent of a student in a club I was volunteering with. Spent some time with him on a road trip even. Such a humble and kind man.
It wasn’t until our 3rd or 4th interaction that I put two and two together. The result was a very nicely signed and personalized copy of the MMM.
Ah, but bad management likes to -claim- to have read it. Sometimes just having the reference can be leverage, i.e., "Well, as per the Mythical Man Month, not all tasks can be parallelized. We can't take three women and complete a pregnancy in 3 months, 3x as fast, after all. This is one of those cases - we won't speed things up by adding people, but we might make things worse"
Sometimes I can't believe that as an industry we've failed to internalize things we've known about for almost half a century.
It'd be one thing if there were managers out there actively disputing the ideas in the book, but I don't really ever see that. Like you say, more often I find managers that claim to have read it and agree. But still, shit like "let's flag if this project is late so we can try to add more people to it" gets said all the fucking time.
I think with a lot of managers, trusting downwards just isn't a thing they're able to do, and so the only move they think they have is to view engineers as miners chipping away at "man-months" of software work. Sometimes I almost think it doesn't matter to them if it actually works or not, it's just the only move they see so it's the only thing they'll do.
Well, speaking as a manager, I can tell you a LOT of that is coming from above middle management too, and the optics of adding people and failing is better than not adding people and failing.
Heck, I stepped away from my last job in part because the environment was that (really, 'leadership' was just generally so bad, and this was but one of its manifestations of suck). I kept having status meetings as we neared a due date (that had been set by product, not engineering, and which our velocity said we would not make) asking us if we'd make the date. To which I replied "Data says no; gut says maybe. If I say we're not going to make the date, what are we going to do differently?", and to which they had no answer -except- "pull people from other projects and put them on this one". Nevermind that the whole difficulty was learning the integrative aspects, i.e., communication, NOT implementation (and that was why gut said maybe; we had learned a lot already, which is what took a lot of time; we were still facing both known and unknown unknowns).
Meanwhile, the teams that were getting kudos were the ones where managers were just like "yep, we're floundering; give us more people". If they succeed, they were brilliant and knew to ask for help. If they failed, well, it was doomed, but at least they knew to ask for help. Nevermind if more people were actually helpful, and derailing other projects just to get them was worthwhile. Clearly, I was a bad cultural fit; I cared more about getting things done efficiently.
The Mythical Man Month reference there was helpful for not derailing things by having more people thrown in the mix; it wasn't helpful for avoiding blame.
> a LOT of that is coming from above middle management
For sure. One of the curses of the modern business environment is the belief in management as a universal skill. That if one has an MBA one can manage anything. That all one needs to do is find the appropriate graph and make it go up and to the right. In practice it ends up being an erasure of domain-specific knowledge in favor of the naive beliefs of the powerful.
The Empire State Building was built on time and under budget, but they did not have a complete plan when they started. This sounds impossible to the modern ear, but that's because executives see plans as a substitute for competence.
The pregnancy analogy has been incredibly helpful to explain the nature of a critical path throughout my career. People instantly get it. I’m often credited with thinking up this analogy because outside of programmers nobody reads MMM.
It has a tendency to rankle managers trying to boost their headcount.
It's difficult to get a man to understand something when their raise depends upon them not understanding it.
I can still remember when the CTO I argued with came into the room one day and said that he'd been given the green light to hire as many additional people as he liked. He was grinning from ear to ear. I suspect he knew it wouldn't actually fix any of our issues but he didn't really care.
I've found if a book or idea doesn't come to them through their own network, then it's easily just dismissed. Especially if the book is nearing a half century old. About the saying that adding people to a late project makes it later, the simple retort was: "But we have agile scrum." End of discussion.
* The Mythical Man-Month, Brooks
* Rapid Development, McConnell
* Extreme Programming Explained, Beck, et al
* Test-Driven Development by Example, Beck
* Domain-Driven Design, Evans
And something that wasn't a book but made a huge impact was Eric Ries's blog, Startup Lessons Learned, circa 2009. He correctly spotted that things like Extreme Programming are generic software development processes, but that in specific domains you could take advantage of their flexibilty to enable new business practices, as in Blank's "Customer Development" process.