I'm a little confused by the question. I don't see it applied <i>within</i> the software industry.<p>Software teams still measure in man-months. We just call them something else, like "story points". I've never seen any estimate or schedule which included team communications costs.<p>Second-system effect is still just as common as it ever was. We still fix bugs, and in doing so, create other bugs. Many or most systems lack conceptual integrity. We still hire implementors before the architecture is finalized.<p>I've seen pilot systems only very rarely. I've never seen an architect produce a manual of specifications. I've never seen a surgical team, or anything even vaguely resembling it. I've never seen tool-maker as a dedicated position, even when my manager agreed it would be useful to the team (on the basis that "nobody would want to take that job" even though I volunteered).<p>The only piece of TMMM that I've ever seen or heard any team try to apply is "No Silver Bullet", and that only as a catch-phrase used to mean "we're fucked either way so don't try". Nobody quoting Brooks has bothered to read that chapter (or that paper) and find out Brooks's criteria for what would constitute a "silver bullet", or try to make one. I can think of a couple examples of partial attempts, but always by UI/PL researchers, never by software engineers quoting Brooks.<p>Are you looking for "the book everybody knows they should read but nobody actually does"?
This is the best book on software engineering and project management.<p>1. Need standards for process, coding style, change control, documentation. Must be easy to move people between projects without massive retraining. Implies use only one programming language.<p>2. Change control is essential.<p>3. Some projects cannot be completed faster: Nine women will not produce a baby in one month.<p>4. Forced schedules will impact quality.<p>5. There is No Silver Bullet. There is implicit difficulty that cannot be changed by tools, process, training.<p>Just read the book!
The Mythical Man-Month is one of my favorite books about managing engineering projects, and I've found it to be useful beyond just software development. The surgical team principle is one that I pushed for heavily when leading a competitive robotics team in college and found to work quite well. I think that organizing an actual software development team to work in this manner would be difficult, but the limited ability to have many people working on the physical robot at once made the surgical team approach worthwhile.<p>The book typically referenced the scarce resource of compile time, which is not a concern today. I can't really think of a good parallel to that scarcity in software development today, but in a situation like the robotics team where there was a truly scarce resource to be shared amongst the group (the robot) the surgical team approach worked excellently.
It isn't.<p>Classical engineering is still following the classical planning principles, with all its pitfalls.<p>An equivalent lesson would be the widely cited Kanban principle, Toyota. But still rarely implemented, only in crazy experiments. Managers still want to be in control, and still throw money and people on a problem.<p>But wait, I found a good TMMM case in the film business. There often film projects tend to get over budget. It is explicitly advised not to prolongue the upcoming desaster by throwing more money at it, or wait a few months. You rather fire the director, and finish fast and cheap.
<a href="https://www.forbes.com/sites/schuylermoore/2019/08/16/business-issues-under-film-licenses/" rel="nofollow">https://www.forbes.com/sites/schuylermoore/2019/08/16/busine...</a>