Earlier quoted context omitted.
That must have been an amazing ride. Note: in my opinion, a small, lean, focused team is the right way to build an OS. I haven't seen the "throw an army at it" approach succeed for building the core of an OS or platform, as it becomes almost impossible to keep coherence in the system. And, yeah, that GMSCore joke is too real.
Maybe? How many people worked on the core of Windows NT? On a number of the big Unixes? Various minicomputer OSs? What you probably do need is a chief architect--like Cutler in the NT case--to keep everyone lined up.
The Mythical Man Month is, like the Bible, one of those tomes that everyone cites with reverence, yet no one seems to read or follow the principles of. The ideal team from corporate's perspective is what I call the RAMP -- Redundant Array of Mid Programmers. The idea being that if you get a bunch of mid programmers together and have them constantly communicating, you can get the output of one good programmer without the risk of one good programmer, since you can always replace any of the mid programmers that fail or falter. But this approach has a number of drawbacks: you don't actually get the output of one good programmer this way, and you don't get the speed of one good programmer either. Furthermore, you run into the same problems you do with actual RAID: similar components tend to fail on similar timelines, so you end up having to replace all the components at around the same time anyway. Programmers tend to burn out, or quit and look for greener pa$ture$, after a few years, so you may end up losing a significant chunk, if not all, of your team at around the same time.
But if you're an organization with billions in the bank, you can remain idiotic for much longer periods of time than any of your people are willing to stick around for and attempt to positively change things.