[chaboud]

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.

[manmal]

Indeed, it was interesting when VW announced they‘d hire 10k engineers to build an automotive OS. Of course it hasn’t worked out and they needed to restart the effort (with 5k devs it seems?).

[monero-xmr]

Small, lean, focused team is the correct way to build any massive undertaking in software. Maybe not in sending people to the moon, but in building consumer software.

[jethro_tell]

Well, small, lean, and focused also implies that the time to deliver is still a bit longer. If you're willing to wait 5 years for something, then a small lean focused team is the way to go. The issue with hiring 10k devs to build the core of an os is that just by definition, you'll have people starting the user land at the same time as the core and now you have UI project managers dictating ABI interfaces at the same time as you're trying to make your core OS.

A large dev team for something that complex it the classic case of the mythical man month. Some things just need to happen in series, and some things just need to happen first.

[p_l]

Various individual components involved in sending people to the moon were also composed of small focused engineering teams.

[agentgumshoe]

Much like societies, there is no 'one way' to do it all.

Best is to really understand what you are trying to do in the first place.

[ghaff]

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.

[wrs]

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.

[ghaff]

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.

[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.

[chaboud]

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.