Toby Muresianu
(tmuresia)

Chapters 2-6 of the Mythical Man Month make interesting recommendations about how engineering teams should be structured and how they should operate.  It is particularly interesting that despite the book's good reputation and it being about 30 years old, these recommendations are counterintuitive and contrary to standard operating procedure in most places.
The overall message was one of pragmatism and realism over idealism and optimism.  From the propensity to schedule too little time to accomplish tasks to the idea that everyone on the team should contribute to the architecture of the project, people perceive groups as operating on a much more ideal level than they actually do.  It was interesting, therefore, to see another method of group organization (the 'surgeon' model) proposed which enabled large groups to operate much more effectively.  Unfortunately, there was only one example of that model working effectively, and it was not in the context of a large software project, so it is hard to tell whether the author truly recommends this--if he did, why did he not implement it in one of his own projects and describe that?  Also, I have to be skeptical that having seven to 10 people support the work of one programmer is efficient with large projects--since the scope of what needs to be programmed is so large it will always need a large number of programmers, and having seven to 10 people supporting them implies a gargantuan team, which is still susceptible to communication delays associated with its size even if not at the same scale as a traditionally structured one.  Also, even if the time savings and quality benefit incurred by having a tester and 'copilot' on hand enable each programmer to build much more of the project than he would otherwise, because he is moving quickly and all components of the project are not being worked on simultaneously integration issues might be much more severe. 
Another interesting topic was how the second versions of products tended to be the worst, and that feature bloat was an extremely common problem.  It's also been my own experience that after building a simplified version of something, I become overconfident and want to expand it to do much more than was originally planned.  When developing a scripting language to automatically test a particular piece of software, I initially limited the instruction set to navigate and take pictures.  When I was able to do this in a relatively short amount of time and found that it was a useful tool, I immediately thought of how I could integrate other testing capabilities into the software such as sending data to the program and changing various aspects of the OS that it was integrated with.  While some of these were possible, I attempted to use the existing design as the core of the more full-featured new program and found that my program included numerous awkward features that didn't work or integrate well into the original program, and that due to accomodations for the new features it was now more cumbersome to use.  I eventually redesigned the program to incorporate the features whose value justified their extra cost (as Brooks recommends); had I done this at the beginning I would have saved time and not wasted effort.