One entity (person/group) with a strong product vision + a giant decentralized workforce is pretty much how everything gets built. The actual people putting hands to keyboard have the mythical man month thing going for them.
The part of mythical man month I was thinking of, which I consider the most famous/useful take-away, is how adding people to a project will not necessarily make it go faster, because the more people, the more coordination work -- and Brooks paid a lot of attention to the fact that the "coordination work" isn't just, like, issuing orders and monitoring people, but involves building and sharing and maintaining "mental models", a vision for how it all goes together in a consistent and coherent way.
i don't think that vision can be developed and maintained succesfully only by people who never get their hands dirty, it needs to be iteratively developed with constant feedback from the work itself and it's reception, if it is to be successful.
> it needs to be iteratively developed with constant feedback from the work itself and it's reception, if it is to be successful.
There's a danger here too in that you can iterate on a design in a "monolithic" way where you iterate over a brittle design that's still hard to work with years later because you need to reload the entire system into your brain to make sense of it again.
Looking at Unix as an open source design success story, it was designed in relatively well-defined "layers". So for example it can get away with making literally everything a "file" with a common file interface, even if you're actually working with a physical peripheral or a "black hole" like /dev/null. And on these layers you can build all kinds of different implementations.
I try to push for a similar approach even on proprietary projects because if we can compartmentalize what we need to know to work with the pieces of our systems, they'll be easier to understand with less effort than if we need to understand everything about them before iterating on them.
And this can be passively "encouraged" by how the work is divided across teams/workgroups to leverage Conway's Law (which can also just as easily lead to software components that don't make any engineering sense if people aren't conscious of the effect their organization has on their software's organization).
