Depending on your definition of “core”, I think the cores of those were indeed implemented by a handful of people. Read “Showstopper” for the Windows NT story, for example, with a small gang of ex-DEC engineers putting the basic kernel abstractions in place.
Of course, the full functionality of the system comes after lots more people build functionality on top of that core. Which is exactly why it’s important for that core to be coherent, powerful, and well engineered.
You can have the best chief architect in the world, but if everyone’s building on sand you’re going to get a crappy system. Whereas if the core of the system is solid, it will guide people into doing things better even without an architect.
I've read Showstopper. Also Soul of a New Machine. Don't really disagree. A lot depends on what you consider core and what you consider a system in the words of Fred Brooks.
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.
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
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.
The real core of NT, the kernel team, could have been fed by two pizzas (if they could agree on the toppings). I didn’t work at Microsoft, but I had some occasions to meet with them (I was working on high performance media tools that squeezed a lot out of a little at the time). They kept a tight ship and designed systems that they genuinely had understanding of. Linux has had similar guidance, and my contact with the Fuchsia team in the early days showed signs of the core design tenets (e.g., object capability permissions model) having been well considered before broadening the effort and resourcing.
Different ecosystems have gone through phases of mass and focus, but times of concise clarity of vision from small groups (e.g., hardware rendering in Android 4.x, early days of CoreAudio, NTFS) move mountains that large teams never could.
Of course, the full functionality of the system comes after lots more people build functionality on top of that core. Which is exactly why it’s important for that core to be coherent, powerful, and well engineered.
You can have the best chief architect in the world, but if everyone’s building on sand you’re going to get a crappy system. Whereas if the core of the system is solid, it will guide people into doing things better even without an architect.