4 ms·

I joined Android in April 2012. Looking back, at that time Android was incredibly lean for what it was accomplishing. The entire Frameworks team reported to one

I joined Android in April 2012. Looking back, at that time Android was incredibly lean for what it was accomplishing. The entire Frameworks team reported to one manager, and we would fit in a medium size conference room. That included all of UI toolkit and the bulk of the Java APIs an app would call into, including Binder. (Networking, phone, graphics, Bluetooth, etc were other teams, but we worked closely together. And I think graphics was like 5 people). At the time I was slightly worried that I had joined a mature project and that it had already seen most of its success. Little did I know. (Disclosure: Chet was my manager for a couple years, until I left in late 2016 to join Fuchsia, largely because I was impatient to develop in Rust). Chet is a great comedian, I think he'll do well in his new interest. I'll bend the norms here and tell a joke. It'll be funny to Android insiders, apologies otherwise. At one point, he hosted a get-together in his house, which was one of many things that led to incredible team cohesion. It was somewhat chilly, and we were sitting around in our jackets shivering a bit. One person said, "we should have an Android app for turning on the heat to warm us up." My response: "we already do, it's called GMSCore."

eclipxe 3y ago
As someone currently working on GMSCore…I couldn’t stop laughing.
chaboud 3y ago
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 3y ago
  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?).
- ghaff 3y ago
  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.
  - chaboud 3y ago
    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.
  - wrs 3y ago
    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 3y ago
      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.
  - 3y ago
- monero-xmr 3y ago
  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 3y ago
    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.
  - agentgumshoe 3y ago
    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.
  - p_l 3y ago
    Various individual components involved in sending people to the moon were also composed of small focused engineering teams.
FpUser 3y ago
>"until I left in late 2016 to join Fuchsia, largely because I was impatient to develop in Rust" Shows how different people are. I only care what I am developing. I have my preferences but if generally language is the last thing I care about bar some pathological cases.
- chihuahua 3y ago
  I used to think that way until I ran into one of the pathological cases (Ruby) and now I'll think very carefully about which job offers to accept based on the language(s) involved.
  - shermantanktop 3y ago
    Me, before Ruby: “languages are languages, I can usually pick up what I need to in order to contribute.” Me, after Ruby: “fools rush in where wise men fear to tread.”
    - chihuahua 3y ago
      exactly - last year I had to learn Go and Scala for a job, and it was a nice experience learning something new. 2 languages with advantages and disadvantages, and good support from VSCode and IntelliJ. This year, I had to learn Ruby, and found it to be a mess, with poor support from VSCode and RubyMine. Apparently you can't know what methods exist on a class until runtime, so the IDEs don't can't tell you much about your code. Just like you shouldn't be so open-minded that your brain falls out, a language shouldn't be so dynamic that you can't tell anything about a line of code until you're in the middle of executing it. Maybe it's great for cranking out a CRUD web app in a weekend, but not so great for a product that's had 300 developers writing code for 10 years.
      - boredtofears 3y ago
        > Apparently you can't know what methods exist on a class until runtime, so the IDEs don't can't tell you much about your code. If you didn't know that going in you did zero research about the job you took.
chairhairair 3y ago
Is there any animosity towards the later efforts to “professionalize” some of the early simpler Android APIs? I’m thinking specifically of some of the drama surrounding the banning of SharedPreferences.
- jreck 3y ago
  Most of that is being driven by the same people who worked on the original APIs. Being on a successful platform means all your rushed, good-enough APIs from years ago tend to now be load bearing regret.

eclipxe 3y ago

As someone currently working on GMSCore…I couldn’t stop laughing.

chaboud 3y ago

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 3y ago
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?).
ghaff 3y ago
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.
- chaboud 3y ago
  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.
- wrs 3y ago
  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 3y ago
    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.
- 3y ago
monero-xmr 3y ago
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 3y ago
  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.
- agentgumshoe 3y ago
  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.
- p_l 3y ago
  Various individual components involved in sending people to the moon were also composed of small focused engineering teams.

FpUser 3y ago

>"until I left in late 2016 to join Fuchsia, largely because I was impatient to develop in Rust" Shows how different people are. I only care what I am developing. I have my preferences but if generally language is the last thing I care about bar some pathological cases.

chihuahua 3y ago
I used to think that way until I ran into one of the pathological cases (Ruby) and now I'll think very carefully about which job offers to accept based on the language(s) involved.
- shermantanktop 3y ago
  Me, before Ruby: “languages are languages, I can usually pick up what I need to in order to contribute.” Me, after Ruby: “fools rush in where wise men fear to tread.”
  - chihuahua 3y ago
    exactly - last year I had to learn Go and Scala for a job, and it was a nice experience learning something new. 2 languages with advantages and disadvantages, and good support from VSCode and IntelliJ. This year, I had to learn Ruby, and found it to be a mess, with poor support from VSCode and RubyMine. Apparently you can't know what methods exist on a class until runtime, so the IDEs don't can't tell you much about your code. Just like you shouldn't be so open-minded that your brain falls out, a language shouldn't be so dynamic that you can't tell anything about a line of code until you're in the middle of executing it. Maybe it's great for cranking out a CRUD web app in a weekend, but not so great for a product that's had 300 developers writing code for 10 years.
    - boredtofears 3y ago
      > Apparently you can't know what methods exist on a class until runtime, so the IDEs don't can't tell you much about your code. If you didn't know that going in you did zero research about the job you took.

chairhairair 3y ago

Is there any animosity towards the later efforts to “professionalize” some of the early simpler Android APIs? I’m thinking specifically of some of the drama surrounding the banning of SharedPreferences.

jreck 3y ago
Most of that is being driven by the same people who worked on the original APIs. Being on a successful platform means all your rushed, good-enough APIs from years ago tend to now be load bearing regret.