[bitwize]

The Mythical Man Month was literally written because Fred Brooks threw an army at the problem of writing an OS -- IBM's OS/360 -- then found it didn't work and decided to write down why it didn't work. His idea of an ideal software team he called the "surgical team" and your chief architect is the "surgeon" -- the one responsible for the major design decisions who calls all the shots. The surgeon and his team shouldn't exceed about ten people.

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.

[agentgumshoe]

The other key factor is probably the person hiring/hiring being able to identify a 'good' programmer. Whether that's through their own competence or having some knowledge of the candidate outside their resume.

Speed to market is also a factor. If you pushing to release a new product, good engineers are very important. For big corporates with established marketshare and profits, it seems to be the thousand monkeys with typewriters approach

[bitwize]

Indeed. I've noticed that the more off the critical path is the corpo's software team, the more waste they are willing to tolerate when it comes to software development. That's how you come to things like super-scalable, cloud-based, kooberneteez-orchestrated microservice architectures for internal applications which serve a subset of a division of a company. And you need a team 200 strong to service that.