CoRecursive: Coding Stories - Story: Android's Unlikely Success

Episode Date: October 3, 2022

What could you accomplish if your teammates were all excited and determined to hit some project timelines? What is it like for a group of people to give it all they have? That's what today is about.��    Chet Haase from the Android team is here to share the story of the early days of Android, the mobile operating system that powers the majority of phones worldwide. We'll cover the years from 2005 to around 2011.    It's a wild story. Episode Page Support The Show Subscribe To The Podcast Join The Newsletter Android's Book

Hello, this is Co-Recursive, and I'm Adam Gordon-Bell. Each episode is the story of a piece of software being built. Once, around 2012, I was working on this web application that I had inherited, and I didn't like the way the front end of it was written. It looked old, and it used some tech that I didn't like. Don McKay, my frequent podcast guest, joined the team at this time and we decided to just rewrite that front end. We moved all the UI to Bootstrap and we made some other changes. It turned out it was a lot more work than we thought, but it was exciting and we threw

ourselves into that project and we got it done. We got it done because it was our project. We took it on and we told people we would get it done. I share this because I feel like I get what it's like for a group of people to get excited about something and give it all they got. And that's what today is about. What could you accomplish if your teammates were all excited and determined to hit some project timelines? Today, I've got somebody from the Android team. Yeah, why don't you tell me your name and what you do? I am Chet Haas.

I am a software engineer and have been for many years now. I currently work on the Android team at Google, where I've been since about 2010, working on graphic software, animation, performance, whatever. Chet is here to share the story of Android, the mobile operating system that powers the majority of phones worldwide. Let's start on Chet's first day when he was given a four foot wide desk in a large room full of other desks to start his work at. And that's your space.

Like there is no bookshelf next to it. There's no wall for you to hang stuff on. And there are, you know, cute walls, but it's not like high. Like you can see everybody else in the room. You are all part of that shared space there, which can be a bit much. They break up the space a little bit so that at least, you know, you're not hearing, you know, someone on the speakerphone like several rows away. And it does help create an atmosphere where you do feel like you are working with the other people around you as opposed to everybody's in their own office doing their own thing. When Chet joined, they were working on Honeycomb, which would be followed by ICS, Ice Cream Sandwich, and then Jelly Bean. Android releases,

by the way, have dessert-based internal code names. And from that, you might guess that the Android team had a passion for desserts. But when Chet joined the team, it was a different passion that jumped out. There were so many ways to get awesome coffee in the building, which I found a little bit weird until I understood how hard people were working. And then it kind of made a little bit more sense. But like there was, you know, really good drip coffee sitting there that you could just pick up, or there was an espresso machine. There was a clover machine there. There was other kinds of, you know, like a cake pod thing or whatever. And I remember walking in one time, I walked up to the espresso machine,

or maybe I was just getting drip guy. I don't know. And there was a guy using the espresso machine who, I don't know if you've used these, you know, like real espresso machines. You basically have a grinder to grind the things into the little dispenser and then you tamp it down. Like there's a specialized tool for like pressing this thing and you're pressing it just exactly right so that you get the, you know, the perfect extraction, all that stuff. So the guy walked out the espresso machine and he pulls his own metal tamper out of a holster in his belt. He had like a specialized coffee tamper. And that kind of defined the culture to me. Like these people are really serious about their coffee, that they're going to bring their

own specialized equipment to use the already over-specialized equipment that is sitting right in front of them. That's awesome. Was that like in a little kitchenette, like off to the side or? Yeah, it was just a little, we call them MK's micro kitchen where all the snacks and drinks are like in my mind if you're making a coffee that fancy like you don't just go back to your desk and code away you like sit and appreciate it or no like the break was actually making the coffee having the coffee that's just something you do while you're coding chet learned pretty quickly that this group was different than other software groups he had worked with in the past.

The thing that I remember the most of the time was hitting the ground running really fast and really hard. Everybody was fairly serious and focused on what they were doing. They weren't just hanging out. They weren't getting a coffee and sitting in the room and chatting away. It was like, no, everybody was working. But also the hours. I tend to be a morning person just because I evolved that way given some of the commutes that I've had over the years. And I was one of the few people that

would be there early, but everybody else was there late, right? On those days when I would stay late as well, there was a lot of other people putting in those late hours or, you know, working when they're getting home. You can sort of see them checking in code whenever. On the weekends as well. Towards the end of the Honeycomb release, Chet was introduced to Bacon Sundays. For the few weeks coming up to a release when we really needed to hit the deadline and we had too many bugs and the release needed to be nailed down so that we could ship it, then everybody was encouraged, not made to, but encouraged to show up on Sundays so that we could sort of pull together and there would be other people around to collaborate with,

to nail the bugs, to do the work that needed to be done. And then they would provide, you know, a catered breakfast. So in the cafe, people would show up around 10, they grab some nice food in the cafe, and then they make their way up to their desk and get to work. They were working hard because they were fighting for their right to exist. Android is huge now, but in 2010, that wasn't the case. Like people were buying Android phones, but not hugely, right? We were one of the smartphones, but we were a solid fourth or fifth place in terms of like the platforms that were out there selling and doing well. And so it wasn't really obvious that we were going to stick around. So the more and the faster that we could do our work, the more chance we had to actually stick around and do more of that.

It was more work, harder work, more hours than I had put in to any job prior to that. Like my main memory was like, I'm on the team and all of a sudden I'm, you know, I'm writing code, I'm checking in stuff as fast as I can because the team felt at that time, like the more we could do faster, the more chance we had to actually survive. So that's sort of my lasting memory was like that first couple of years was a serious amount of work.

In those early years, the odds were against Android. It was just a small team building a mobile operating system as fast as they could. And at the very beginning, they weren't even part of Google. They were a startup. I know this story because Chet spent four years writing a book, Androids, the team that built the Android operating system. It's a super good book, and we're going to be drawing on it here, but you should probably read it. Anyways, let's start at the beginning. The goal of the startup Android was to provide an open source operating system. They wanted to do was basically level the playing field that they provide an open operating system. Then it allows other manufacturers, not just, you know, the company that acquired them, but everybody to take part in this ecosystem and use this common platform across all of those different devices.

At the time, in 2005, there was two models for phone operating systems. One was the RIM BlackBerry model, where you sell a phone and then also create the operating system. Windows had the other model where they did an operating system that they would then license, right? HTC or one of these manufacturers would build devices using an operating system, a platform provided by Microsoft, and then Microsoft would get a cut of each handset. But HTC or these manufacturers could not see the code. They didn't really necessarily know where it was going in the future. So to some extent, it was kind of a black box, but it was a black box that they had to port to their devices, which was a little bit tough. And it was a black box that they had to pay for,

and the margins can be quite small on these devices. So what Android wanted to do was provide an open source thing. It's going to be free to everybody, and everybody can see the code. So it's going to be easier to port. It's going to be common across all these devices. So you can have applications working on different phones and there is no licensing fee. So it's easy for people to get into. That was the goal of the original Android startup, but Google's goal was different and based on some predictions about the future. It was clear given the numbers at that time. You could look at the graphs of phones being sold in the world and PCs being sold. And Google at that time was totally focused on PCs.

Everybody accesses the web through a browser on their desktop. Laptop, desktop, workstation, whatever. That was how they got to Google services. But it was clear that in the future, there would be a mobile ecosystem, and they wanted to make sure that they were there as well. Google services, but it was clear that in the future there would be a mobile ecosystem and they wanted to make sure that they were there as well. We want to make sure people can get

to Google search. Everybody's switching to phones. Imagine a world where, let's take Apple as an example. Let's say that Apple came out with their phone and for whatever market reasons, they end up being the only smartphone available in the world. So now imagine, well, they've got the phone. They have a dedicated audience that is accessing the internet through their phone. You don't have to imagine too hard to understand, well, what if they had their own search engine and their own ads infrastructure and their own services built on top of that? Then all of a sudden, Apple is the place. That's the portal through which you get all of these services. And I think that was, that was a future that scared people. What do you think

they thought the odds were though? Like maybe they just thought this is a long shot, but we throw, we throw a couple of long shots in every year or something. I see it more like that because let's be clear, like Google funded this, but they didn't fund it. Like this is the next direction for Google. They funded it. Like, it seems like we should try this thing. They took flyers on things. I, I think it's really good that they did. And maybe it's really good that they did this in a small way, because I think the, everybody was just totally focused on trying to make this thing work as opposed to like, you throw too much money at a thing and you build the team up too big. And you're going to end up spending all of your times in meetings, trying to make this thing work, as opposed to like you throw too much money at a thing and you build the team up too big and you're going to end up spending all of your times in meetings trying

to figure out what to do. It seems better to start small and become a thing first before you bulk up and try to do it in a more polished way. And so Google acquired this startup. They funded them enough that they could hire some people, but that was about it. And actually that was probably ideal. Most acquisitions, like they acquire the company, they try to integrate them into the company. There's a social culture mismatch. The founders leave because they got a big fat paycheck. The engineers fritter out to other projects. You know, they spend all day in meetings trying to align with other, you know, product directions and priorities and then nothing happens, right? I've seen so many acquisitions just die on the vine.

Somebody made a lot of money somewhere, but I'm not sure that the results were what the company wanted. This one absolutely did, right? So they got eight people in the door. And then three and a half years later, they shipped 1.0 with 100 people and all the opportunities that we've had since then. And one of the aspects that helped that work was the company basically walled off itself from the rest of Google. It ran

as a separate startup within Google. So Google cut the paychecks. Everybody got paid for the work that they were doing. But everybody outside the leadership essentially ignored Google because they just didn't have time. Google was working on different kinds of software. They had different processes. They had different infrastructure. They had different priorities. And they were not interested in having those conversations at that time. Besides money to hire people and office space, the other thing that Google brought to the table was legitimacy.

In the startup, you might call that chip manufacturer and say, hey, I'd really like to try your stuff out. And if they answer the phone, they may say, yep, that's going to cost you, you know, X hundred thousand dollars for a development board. Whereas if you're at Google, that company may be approaching you and saying, hey, would you like to try my new development board? Because they want to make sure that if Google is serious about this thing, that they are, you know are in the front door in conversations with this company so they can be a part of this. They took Android a lot more seriously as a part of Google than they did when it was on its own, barely funded.

And I think that was an important dynamic. The first phone the Android team was to deploy their OS to, once it was built, was the Sooner phone, a BlackBerry-type device made by HTC. But first they needed to build an operating system, and for that they needed a team. They didn't acquire a huge company with an existing product. They acquired a company that brought over eight employees, only three of whom were writing code. And the only code that they had was 3,000 lines of JavaScript. Hiring was trickier than it sounded though, because at this point,

Google hadn't announced it was building a mobile OS. It was still somewhat of a secret. They couldn't advertise and say, we're building a new phone platform. And so they couldn't necessarily get all of the candidates looking at those job postings that they would have wanted because they couldn't say what they were doing. Also, embedded operating system people are not easy to find. And there's no time to train an undifferentiated developer on the embedded space. There's just too much to learn. But here, personal networks and especially geography helped. There were three companies in the Valley that Android could recruit from.

One of them was a company called Danger Inc., which was started by Andy Rubin, co-founder of Android. So he basically had done a smartphone thing before, you know, five years earlier when it was even harder and the devices were even more constrained. And several of the people that eventually ended up on Android had worked at Andy's company at that time. So they had already built essentially a smartphone platform using the Java programming language. They had an app store. They had, you know, backend services, like a lot of the elements in Android had been done before in a different and more constrained way on danger. So there was a group of people that had been there sort of building the skills and knowledge to do something like that. There was other people that were at a company called B, which was an operating system operating through most of the 90s, trying to get out there and sell to people and didn't quite make it. They made their own

hardware called the B box. They figured out how to port it to different like x86 and Mac architectures. So you could just buy the BOS. They pivoted how to port it to different like x86 and Mac architectures. So you could just buy the BOS. They pivoted and tried to do an internet appliance that didn't quite work. And like they kept trying these things, none of which really made any market penetration or any real money for them. But it did attract like sort of cult classic people. Like a lot of people used BOS and a lot of the Android people ended up working at BOS because it was an exciting new operating system. It wasn't Windows. It wasn't Mac. It was a multi-threaded, multimedia centric, super interesting platform. It just didn't happen to sell to anybody. But in the meantime, the engineers working there, again, built up the

skills, knowing how to build something like this kernel Kernel operating system, UI toolkit, all the stuff that you need, the application layer, the public APIs, like again, all of the elements that they ended up using later on Android. So B was acquired by Palm who spun it out into Palm Source to theoretically build their next OS. That didn't end up happening.

They did build an OS, kept building the skills for another few years. And then that company got acquired by a company called Access, who came in and said, we don't want to do this anymore. Why don't we do this other thing? And all of the people that had come from B and carried on into Palm said, we're done. We don't need to do this anymore.

And so these people were available. And then another operating system team was looking for jobs, the WebTV team. They had built an operating system as well and a full UI, but then they were acquired by Microsoft. So the people to hire were out there, but first Google had to hire them. And then they hit another problem. They weren't the type of engineers that Google liked to hire. Google was very focused, especially at that time, on more of a pedigree education. Not that there's anything against it, but like they really were going and interviewing at, you know, top engineering schools. They love the idea of,

you know, Stanford CS grad or, you know, MIT or whatever it is. Some of these, these better known engineering schools where people were coming out with really good CS degrees because they could bank on that. And because they could, like they, they were Google, people had heard of this company, they had, you know, name recognition. And so they could attract this kind of hiring talent. And that was the people that the recruiters would go out and look for. And then people would come in to interview and they would answer these, you know, math and coding and algorithm questions. And they would do well because that's exactly what they had trained for in their CS education. But the Android team needed different skill sets.

They need embedded engineers. They need people that understand how to write operating systems. There's an OS course in a CS degree, maybe. Not a lot of people take it and not a lot of people explore that outside of course. And so it's really uncommon to find those kind of people. And those people aren't necessarily the same kind of people that are going to nail one of those coding interviews because they have been working on different kinds of coding all these years. Like so many people, especially on that early team, came in after hacking, you know, assembly code on embedded systems for years. Well, that's a different skill set, right? Or writing performance graphics code or writing UI code. Like this was not necessarily skills that Google was hiring for at the time.

And so there was this mismatch in who Google traditionally would look for and would approve through the interviews and in the types of engineers that Android really needed to hire. One of the greatest examples is how many of the people on that early team, like not only did they not come from a top engineering school with a top CS degree, some of them didn't even have college degrees at all. And in fact, at least one of them didn't graduate high school. This was a problem. Google had a unified hiring process. So these embedded people would go through a generic phone screen and they would fail it, or they'd go in for an onsite whiteboard interview and fail that. And yet Android knew that these were the right people with the right skills to bring in. And so they ended up having to essentially create their own hiring process to make sure that they were bringing in and then approving the people that had the right skills for Android, even if

that wasn't exactly the right skills for Android, even if that wasn't exactly the right skills for what Google considered as more of a plug and play software engineer. That wasn't the goal. The goal was to hire people that could write an operating system for a mobile phone. Like it was critical that you bring in, let's say Brian Swetland, right? He didn't finish college because he got too busy on his hobby projects, working on Linux kernel stuff. He was much more jazzed about his side projects. And so school kind of took a back seat. Well, that may not look good to a traditional recruiter, but Brian Swetland was absolutely the best person to bring in to start the Linux kernel effort for Android.

And I think the people that started on that early team knew, well, we need something different here because otherwise we're just not going to start with the right people on this small and growing team. Thankfully, they overcame the hiring process barriers and they built the team from experienced people from B, Palm, from Danger, from WebTV. This was an operating system dream team. They knew what they were doing. They knew the pieces that they needed to build, and they knew how to work with each other

to sort of reach the end goal, which is a huge advantage over, I think, most new software organizations where you're hiring random people, they need to ramp up. They need to get used to, you know, how things happen on the team. And so that the combination of those, like people that had worked at one of these places, some of them worked at a couple of them, Hiroshi, who now runs Android and Chrome OS and all kinds

of platform stuff had actually worked at all three, right? But the fact that they had a built those skills and knowledge, knowing what they needed to do to build a platform or even in some cases like an embedded or mobile platform. And B, they'd actually worked together before, meant that they could sort of hit the ground running. And a lot of these engineers, too, like the people that work on operating systems on this kind of platform, like this is what they love to do. They love to bring things up from nothing, right? And so giving them an opportunity to come in and be on the ground floor, to see it appear from like zero into software running on devices, I think was really motivating for them. And honestly, there's not that many of these things around, like people aren't, you know, creating new operating system platforms every day.

And so this was exactly the kind of project that they wanted to work on. This excitement and this experience was a big key to getting as much done as they did in those early years. There's less design and discussion work to do when everybody's already done this before. Like the App Store, for instance. The person that they ended up getting to lead that team was Michael Morrissey. Well, he had a team at Danger that had built an app store. And I mean, it was quite different, right? They weren't using the same code. They weren't solving exactly the same problems, but he knew, okay, well, we're going to need a persistent data connection between all of these phones and the backend server. And we're going to have a single connection. And then it can forward those requests to, you know, Gmail or Calendar or Contacts or whatever.

Like he had solved similar problems in a different environment. And so just being able to say, okay, these are the pieces that we will need to solve here, I think was a huge advantage to getting started faster. So Swetland and the team start working on getting Linux to work on these early devices. And team start working on getting Linux to work on these early devices. And others are working on other systems programming work like device drivers and power management. It turns out Linux has a lot of support for doing standard server type things,

maybe even desktop hardware things. But running on a lower powered device with lots of multimedia like audio and cameras and Bluetooth, well, there was a lot of gaps to fill. And then the team needed to decide how applications were going to be written for this platform. When they got acquired, the only code that they had was JavaScript, right? Because they just needed this demo running and whoever was writing it was writing JavaScript. JavaScript was common. So when they came in, they said, OK, well, obviously, JavaScript is going to be one of the languages. But why don't we do multiple languages? Why don't we also offer C and C++? Because many of the people on the team were embedded programmers and C and C++ allow you to get much more low level details.

Like you can really more manually control all of the allocation of memory and and what's going on. It's much lower to the hardware. And then there's also this Java programming language thing. This seems like a good idea because many developers know this language in the real world. And so why don't we do all three? All three make sense. And then they got to the end of that year and they realized, we've got like 15 people on the team. We're trying to accomplish an infinite amount of things. How about we just do one language? Why don't we just try not to solve every problem in the universe because we really should

ship 1.0 someday. And then word came down from on high somewhere that that single language was going to be Java. I believe the main reason for that was a common theme at that time was lowering the barrier to entry. By the time the SDK launched in late 2007, and they said, hey, programmers, try out our new platform. And programmers are like, you don't have any users. Like, why would I spend a lot of my life trying to figure out how to program for this thing that by definition has zero customers for the software that I'm writing. And that was the case until 1.0 came out a year later. And, you know, there continued to not be a lot of devices for some amount of time after that. But if you can at least make it as easy as possible for those developers, at least they don't have to like reinvent their programming lives in order to

figure out how to get something to run on your platform. So if you give them a language that they already know, because they probably used it a in school and be in their enterprise jobs elsewhere, then you've made it easy for them to understand the language of writing Android apps as well. I mean, the downside being, as you said, it's a memory constrained environment and like Java is not known to be super memory efficient, I guess. Right. So at the time they had to write a runtime for it. So Java, the language needs a runtime like it's a it's a translated language. It's something like the the original slogan coming out of Sun was write once run everywhere. And that's because the binary files that it produces are not actually binaries that run on the device.

Instead, you have an intermediate layer, which is the runtime on, you know, desktops and servers. That's the Java VM. But it basically translates between this bit codes, the Java class file format and the binary code that's actually going to run on the runtime device. Be it, you know, in this case, a phone or, you know, desktop or, you know, x86 Mac, whatever it is. So you need this runtime running that is A, translating and B, also doing memory management. This is like major difference between Java programming and C or C++ programming because C, C++ programmer needs to know that they allocated that thing so that they can free it up later.

And Java from the beginning has always sort of managed that for you through garbage collectors. The downside, as you say, is like, well, that means there is another thing running and maybe we don't have as direct control over the memory. So one of the things they did, instead of just using the Java class file format directly, they translated it into something they created just for Android called DexCode, which ran in a VM they created called Dalvik. Which allowed them to tune some things and be more optimal in a more constrained environment than the class file format of traditional Java language would have allowed.

And so they created a new class file format that they would compile into, and then they needed their own runtime to be able to run that Dalvik class file format and translate that. The scope of it, like, it seems wild. Like they're like, Oh yeah, we're building our operating system, but yeah, we're also going to build like our own, like runtime for Java and our own like bytecode format. You know, like it, it seems like, Oh, why not just throw that on? Right. While we're building an operating system, like let's build a runtime and a new format, like a new binary format for Java code. First of all, I should point out that this is similar

to something that they had done on Danger. It was a different file format, but they also were using the Java programming language and they were also compiling into their own file format and running their own runtime. So the people that came in, including Brian Swetland, but also Dan Bornstein, who was on that early team, had done something very much like this before. So again, it was a case of like, we know what we need to do.

We do know the steps that we need, and we know that it's physically possible. So then they just got down to work. I'm with you. Like if I posed myself that problem, I kind of wouldn't know where to start because I've never worked on a runtime. Like I know what they are in theory, but I don't actually know how to execute one. So it would take me a very long time. That's, that's a very daunting project, but you get someone who has been working on runtimes for many years and they know this is what a garbage collector is, is what the runtime job is.

And this is what, you know, a file format needs. And, you know, they they have in their mind, you know, different file formats and different options. Like, I think they can break the problem down a little more successfully so that they can have, you know, that one to two people essentially was who wrote the early Dalvik, like over the course of a year or two, they had Dalvik up and running with a very tiny team because it was the right people with, you know, the right skills to understand what the problem was and execute it. Yeah. Yeah. It's a wild, it was a lot of work that happened at that time. So the team was heads down working towards Android 1.0 and shipping their first phone, the Sooner phone, the phone they thought would blow the BlackBerry and Nokia phones out of the water. But then Apple, to much fanfare,

released the iPhone, and the whole market changed. So the iPhone came out, and all of a sudden, that kind of defined, you know, due to marketing, due to uptake, due to, you know, a good job. It's a solid device and company shipping consumer products. It defines a smartphone as having a touchscreen, right? They didn't invent the touchscreen. They weren't even the first phone with a touchscreen.

But the way that they did this or the way that people absorbed that kind of made it a checkbox item so that if anybody wanted to compete in the smartphone market after the iPhone came out, it clearly needed a touchscreen on it. So it was clear after the iPhone came out that they couldn't launch that sooner device because there's no sense competing with a BlackBerry after iPhone exists. So that one was killed and they pivoted and said, OK, 1.0 device is going to be the G1. It's going to be a touchscreen device instead. The G1 was the T-Mobile G1 in the US and the HTC Dream elsewhere.

It had a touchscreen and a keyboard and buttons on the bottom of the screen, one for back, one for menu, but also a couple more buttons and a full keyboard that slid out from behind the screen and a trackball. This is a lot of stuff. This is a lot of peripherals to get working.

So the team had a lot of work to do before they could ship a phone. But Android now had something unexpected going for them. The iPhone had changed the market. So in hindsight, like it kind of seems like, wow, when the iPhone launched, that must've been really stiff competition. Absolutely, right?

Really stiff competition from day one. Continuing today will continue in the future. But they also created an opportunity for everybody that wasn't named Apple and wasn't one of the carriers that they picked in each market. So when when the iPhone launched, they basically had one phone manufacturer that benefited from the iPhone, and that was named Apple. And they had one carrier in each market in the U S it was AT&T. So if you're not named Apple and you're not AT&T in the U S what are you going to do? It's not like you say, Oh, well, I guess they won. Like,

no, no, they wanted a phone, but they did not have a platform that was going to have the capabilities that they needed to compete against that phone. And they weren't going to get them soon because none of these companies were platform building companies. Like they would build these like one-off OSs, which were clearly not going to be sufficient to compete in this, you know, growing smartphone market with all these capabilities that smartphones needed, including the touchscreen. And that basically created the opportunity for Android to come in and say, well, you know, it's not ready yet, but we are working on this thing.

And then the conversations with those manufacturers could start. So now all these carriers are interested, but Android still hasn't shipped a phone. Meanwhile, the team also has some ideas about how people will use phones in a different way than how we use desktop computers. Well, one of the recognitions early on that that's impressed me was that the team realized people are going to be running apps and in mobile phones in a different way than we do on desktops and desktops. You have these monolithic apps where you spend, you know, most of your time, be it Chrome or, you know, Microsoft Word or whatever, like I'm going to be in this this app and I'm going to do a bunch of things. Whereas they realized, well, mobile phones are different. We're going to have little micro apps

and these micro apps are going to interact with other micro apps. I'm going to go into this social application. Then I want to take a picture, which is going to launch a camera application. And then I'm going to want to filter that picture, which is going to launch a filtering application. And they go between all these applications.

This quick switch really only works if multiple programs can reside in memory at the same time. So if each of these applications is coming to the foreground and everything else behind it is dying at the same time, it makes it much more difficult and painful for the user to go between these micro experiences because they're always taking a long time to launch. And now the team is back to struggling with memory issues. Every team wants to use all the memory it can, but that's just not going to work. It's a multitasking operating system where you can run as many things as you want,

but if something launches into the foreground and doesn't have enough memory, then the operating system will automatically start killing stuff in the background until it has enough memory for the thing that just launched. Right. So you're always in a state where your application may just get killed. And then the next time the user goes back to it, it may take a little bit longer to launch because it has to be restarted. So if everybody takes maximum memory, then you're really not going to be able to have these multiple things running in memory. The user is always going to be getting a slow start to all the applications.

And it's much better if everybody can be much tighter so that you can have multiple things in memory all at the same time. I'm going to get the numbers wrong here, but let's say I think there was 168 megs available for applications to use for applications and platform. Like that's all they had, which meant that if your application was coming in too big, you better work on it to cut it down. The web browser group was working weekends to try to get the memory usage down. Then Brian Swetland came out of nowhere with a simple fix.

He made a little one-line change in the kernel that freed up 32 megs. And so he basically hid the memory. He made a little change to the kernel that basically only exposed 168 megs to the operating system. So that's all they had to work with, even though there physically was more memory available. He just wasn't giving it to them until the end of the release. And by then it was too late. Like they couldn't expand to fill the space. Instead, they could just be a part of a much larger sandbox that was opened up to them right before they shipped. And now all of a sudden you had, you know, a couple of hundred megs on that device that only had 168. And that's like a huge change. Like he gave back, you know, 30% or whatever it is. And people were not happy with Brian.

Was that a key to that release's success that they had that extra room? Or was it just like a dick move by somebody? I don't know. I mean, there were so many aspects of that early release that were critical. I don't know if this was one of them, but it was, and I wasn't there at the time, you know, some teams were very unhappy about this because they'd put in, you know, a lot of effort trying to cram things down into a fictionally small space. But I have to believe, especially on the limited devices like the G1 that launched with 1.0, that the ability for things to run in a much smaller, more trimmed down state, I think was better in general. Like you don't want launcher to be killed all the time because every time you launch every application,

launcher has just taken up too much memory. And so with that trick, the team managed to ship Android 1.0 and the G1 started to be sold. It wasn't actually a great success though. The uptake of the G1 wasn't huge a great after 1.0 came out, then in the U.S., the Droid launched. And that was like the first commercially successful phone or at least what the team thought of it. And you could actually see like significant numbers of people buying this thing. And there were ads out there that were really successful. And all of a sudden, Android became a thing, partly due to this device or, you know, the timing of when this came out with the capability of the platform or whatever. So that was kind of I think the team realized, oh, well, maybe, maybe we'll actually be here for a little bit. But six months after that, when I got there in, in May of 2010, the platform was still like a solid

fourth or fifth place. Like above us was iPhone, Microsoft, Nokia was shipping phones with like Symbian OS, which some other phones, I think Sony was shipping some Symbian stuff. Then I mentioned RIM, like BlackBerry, like all these really big deep pocket players with very successful platforms were doing very well. Thank you very much. And then Android was kind of coasting down at the bottom of the heap. And so I don't think that looked like success.

That looked like, oh, wouldn't it be nice if we still get to be doing this, you know, in a couple or a few years, but we had no idea where it was going. And it was in that, that single year that I joined where everything changed. The thing that changed was that manufacturers were forced by the iPhone to up their game and Android was now shipping devices. They weren't iPhone killers, but there was potential there. So when the iPhone launched, maybe they weren't ready to really bet on Android yet. But by the time 1.0 came out and could demonstrate that the G1, maybe it wasn't a consumer success, but it was a commercial success in that you could look at it and go, yep, I get it. Right. I understand what Android wants to be. And I understand that they can be a real smartphone

platform. And if I need a platform to ship my device, maybe I should go have a chat with them. If you think back to that time, like everybody had their own phone, like they were seen as much more like one off devices where you might on that thing. And then all of a sudden we've got this new idea where, no, no, it's going to be a single platform. It's going to work the same everywhere, but with different form factors and different price points. And maybe that's the vision of the future. So the manufacturers are on side, but there's still so much to do. And remember, the Android team is years into moving as fast as they can. They really want to build this mobile platform, though. And so the pace of shipping just increases. I mean, it's crazy if you look back at the timeline for releases, like they were kind of shipping major releases every two to three months for the first couple of years.

And this is like the same level of release or even larger than we now ship annually. Right. Because this is when all of the fundamentals were coming into place in this very early platform, like really major things like internationalization support and supporting multiple densities and sensor support, like things that now we just kind of take for granted. Of course, they're part of the platform. Well, in the early days, they weren't, right. So they needed to be done and then they would just be working on multiple ones in parallel. It's around this time that Chet joins the Android team. It was pretty exciting. I mean, especially after a career of working on products that like,

you know, were buried in the enterprise somewhere or maybe didn't succeed or just weren't available for friends and family to see. It was kind of exciting to work on something that like, if this happens to work, real people in the real world will actually use the stuff that I'm working on. That was pretty motivating, I think, for me and for other people, but also just being around other sharp and motivated people working together on a thing. To me, there's a big difference between putting in a lot of effort and hours and time and energy into something to see if you can push it through and get it there. And the flip side of that is a death march.

I don't know if you've ever been on one of those. And this didn't feel like that. It was more like, I'm going to jam on this thing because it's really exciting right now. And I'm excited to see what is possible. To be clear, nobody was forcing them to work these long hours. It was more that everybody could see this window of opportunity that presented itself, just given the timing of the situation when things were coming out. And they were really excited about being able to offer something that could actually be in this market. And they just wanted to see things work.

Right. So it wasn't the people they were working for saying you need to be here. It was definitely a communal effort. I want to work with these people and together we're going to put it entirely too many hours and see whether we can actually get to the end of the tunnel here and launch this thing. Did the stress of it ever get to you? Like, was there times when the releases built up or you felt worn down by it? I mean, yeah, your energy runs out. I didn't reach the burnout point. Most of the real push was toward the end of the release. And again, like if you have to push a little bit harder for a limited time and then you can ease up and say, okay, let's take a break. Let's have a real,

you know, working schedule before, unfortunately it may come up again. Most of my experience has been like cloud type things where it's easy to release something. Like when you have a specific release date, I guess, what is the impact of a bug? Yeah, that's a very good question. I think this is what drove the team to sort of push a little bit harder because the constraints on that type of product were very different than the constraints on, you know, the server web backend stuff that the rest of the company was doing. Because if they have a bug in search, they could fix it that afternoon, right? They can push a release almost immediately. And everybody, by definition, all of their users will get that fixed immediately.

But now you imagine a phone. Well, we ship a release and that user buys that phone and they go off the grid and that's it. Like they will not get a fix because, you know, the manufacturer didn't feel like shipping an update. They didn't feel like taking an update, whatever it is. So you could not count on them getting it, which meant it had to be that much more solid by the time we shipped. Also with hardware manufacturers, like I said, the deadlines that they had hit were very serious because it's not it's not like, hey, we'd like to get this feature out by December. It's like, no, no, no. Our partner is committing an assembly line to building these things that need software on them. And that assembly line starts running in December.

And if we delay the release for, you know, two to 17 months, they may go out of business or find somebody else to work with. Right. We are going to hit December no matter what. So then it's all hands on deck to hit that. And that kind of deadline pressure also doesn't really exist so much in other software environments where, well, you don't hit December, that's fine. Or, you know, you could hit it with something that you could then, you know, update in January. Like that, that dynamic just didn't exist in the device world. So yeah, the pressures on Android are different.

Android did build an over-the-air update system, which itself is pretty cool. But mainly you're trying to hit a release date. You want your code flashed onto these phones that are then sold in stores all around the world. One of those things in the Honeycomb release specifically was hardware acceleration. The Honeycomb release, you probably don't know it because it hit very few devices in the world because it was intentionally aimed at tablets, which were new at that time. So this was the first tablet release for Android. Other companies, other manufacturers had shipped tablets, but they were using something intended for phones. And so the experience really

wasn't what we thought that it could be. And so we wrote a lot of stuff in order to make the tablet experience much better. But one of the things that's kind of obvious about tablets is the screens are bigger. Well, if you have more screens, that means more pixels to fill, which means you're doing more operations to draw that. And the CPU on those devices, particularly at that time, just couldn't keep up with the amount of stuff that we were throwing at it. So it was clear that we needed hardware acceleration in order to get the performance that would actually give people a real smooth experience on these devices. And so at an earlier stage in the release, my friend and colleague that had brought me in also doing graphics and UI stuff.

And he had proposed doing this hardware acceleration thing. And they said, well, no, it seems a little risky. So why don't we not do it in this release? We'll do it, you know, in the next one. And so he backed off and we all had other things to do. And then very near the end of that release, one of the executives came and said, no, it really looks like we're going to need that. So how about you do that thing that you proposed several months ago? But we've only got, you know, it was like two months or something to ship. Like this isn't like two months to finish our part and then it sits in QA. It was like two months to ship the release.

And we're basically, you know, taking the patient, pulling their brain out, building a new brain and putting it back in and then sending them out to the real world. Right. So like we were checking in like major fundamentally platform changing things within days of that software release actually landing on phones that real people would use. And that to me was like, oh, wow, it's different here. And was it a success? Like whenever I've rewritten a major thing and then shipped it, like it turns out a lot of the old stuff was important, you know? I mean, to me, like there are always bugs in software. Like that is, that is the one true thing about software is it's impossible to write software without, without writing bugs at that time. It did generally work.

Like it did the job that it was supposed to. We did have hardware acceleration. We did hit the performance that we needed to. This is an impressive achievement. Shipping graphics acceleration in two months when you're a new team member. But that was just the speed that this team moved at back in those days. One way they did that was just by removing all of the overhead. We had individuals working on large swaths of technology,

and they were the only person responsible for it. And there wasn't necessarily a lot of design happening in committees and code reviews with many people and iterations through the changes and tests being written and tests being real, like that was, that was considered, you know, maybe we don't have time for this stuff. We really need to ship the software. But the fact that one person could get that entire thing in their brain meant that they were more in control of all of the code and maybe didn't need some of that overhead because they could do the right thing. And they would also put in the time, like when it went in and it didn't work quite the

way it was supposed to, they could then just plow the time and effort in to make sure that it was robust enough by the time that we shipped. That's something that is difficult to do as a software project grows and you have much larger teams and multiple people working on the code base. You can't have people just lobbying in random code into the code base because that person next to you needs to understand how that integrates with their changes in the same code. It was less of a factor

when the team was really small and nimble. And therefore the amount of process and overhead was unfortunately quite small. I would say we've gotten better over the years just because we needed to. You need to with a growing team. If you currently or in the past have worked at Google, maybe on search or ads or one of the tens of internal data stores I hear about, then yeah, Chet's work life might sound

a lot different from how you experienced Google. So I think of Google, I think of it as a more mature engineering organization in terms of like, they've got processes they have, you know, this is the way that we write code here. This is our style guide. This is how we do code reviews. This is how we check in. This is the, you know, thousands of tests that are going to run on every line of code that you have. At least this is my theory. Like I should point out, I've been in the Android org since I joined and I actually don't know anything about how anything else works in the rest of Google, but this is my, my personal interpretation of what happens over there in Android. First of all, like for very good reasons, they used an entirely different infrastructure. It wasn't just, you know,

capriciousness, like we don't want to use theirs. Instead, like it was going to be an open source operating system and they wanted developers to be able to access that, you know, partners for the OS, but also developers to access the public APIs and to build the applications. They wanted, again, to lower the barrier of entry as much as possible, which meant they couldn't require people to buy expensive tools to edit or to code review or to merge the code or, you know, all the all the stuff. Right. They weren't going to require source code repository licenses. Instead, they needed to use tools that were going to be free and available to everybody. And so they kind of built their own infrastructure and to some extent ignored what was going on in the rest of Google. And then at the same time, they had these like killer deadlines that I talked about.

Like they could see this window of opportunity. Like if we get this available, maybe people will care. And they were running as fast as possible. And that meant that although code reviews are a really good idea, and I would encourage everybody to always have their code reviewed, maybe not all of the code was being reviewed all the time in early Android. Maybe people were actually self-plus-twoing a lot of their code because it was more important to them to get that thing in now than it was to send it out to the

team and wait for approval because they had 50 other bugs to fix that day. Right. So that was one aspect of Wild West was just code was just coming in as quickly as possible. Really good engineers, really responsible. And they would, you know, chase the problems and fix them as they as they found them. But maybe there was a, it was not a test driven culture at all, because again, that was kind of seen as like overhead we don't need and can't have time for right now. Instead, I know how the code works. I can sort of, you know, mentally test it and it's going in now, right? There really wasn't a focus on what I would say was more traditional software culture of like, this is how we write software. We, we design it, you know, with a group of people, we have a design doc and then we all agree. And then we write the code and then we reviewed it and then we iterate and, and we have tests obviously to test, you know, all of the functionality to make sure like that. No, no, that, that was entirely too much overhead for the team

at that time. So they ran a lot more quickly. Do you think they succeeded despite or because of? I think it's a mixed bag. I do think that them running very fast was a key element in Android being relevant at all. If Android had come out a year later, I'm thinking it wouldn't exist right now because maybe somebody else would have come out in year later, I'm thinking it wouldn't exist right now because maybe somebody else would have come out in the meantime. I know Palm was working on webOS at the time. Some stuff was

really interesting there. Maybe this would have given Microsoft more of an opportunity for some of their stuff. There were so many players in the market. Which one of those would have come out with something that would have attracted manufacturers at the time that they needed it while Android was being more robust? So I do believe that running really fast and maybe cutting a lot of those corners was responsible for some of the timing that actually made it succeed. You know, I've seen code and been like, why did they cut these corners? But then you realize the context and realize that that, you know, I wouldn't be working on this if, if it wasn't done this way. Right.

Like it literally wouldn't exist. The ones where they spent all the time and made sure everything was very polished and whatever, like they never got out the door. Like that's, that's why I'm not working on those ones. I'm working on this one that actually was released. Yeah, exactly. I've always thought that about Android where, yep, some of those early APIs are a little rough and we should fix those and improve them and offer better things over

time. On the other hand, the fact that they're rough means that it was able to succeed, which means that now we get to be around trying to fix them as opposed to it just not mattering. So that pace leading up to 2011, it really made a difference. And it was in that single year that I joined where everything changed. So by the end of 2010, by the time we got to 2011, not only had we continued to grow as more and more diverse devices came out all across the world from all kinds of manufacturers. But we also passed all of those other manufacturers lines. Like if you look at the sales of devices at those times, Android just kind of it did what we call a hockey stick. Like it just kind of changed slope to be much steeper and it just kept going up.

And by the end of 2010, nobody really talked about numbers in that market anymore because Android was there, right? Like clearly iPhone was doing very well, but if you'll look at the numbers, it's like iPhone, you know, they captured the market that they got very solidly, but Android had everything else, right? Because it wasn't just this device in this market. It was all devices in every market all over the world. And then the other manufacturers, like over the next couple of years, they just went away.

And then there was only two. The whole industry, the industry where they were outsiders changed, just like that. And suddenly Android was at the center of it. For example, Steve Horowitz, who ran engineering for the team, he used to go to the Mobile World Conference every year.

It was a big get-together of handset manufacturers. In those early days, like pre-1.0, he remembered, you know, being in meeting rooms, and some of the people would come in and they would get it, and they wanted to be a part of this thing. And some of the companies would come in and just blow them off, like, oh, well, you know, you obviously don't know what you're doing because you're not one of the traditional players here. And then fast forward, you know, five years and mobile world Congress, like the entire show floor was basically Android, right? So the, the change from like, who is going to take us seriously and listen to us and

be a part of this. And then eventually everybody, everybody that's not Apple ends up making Android devices. Cause that's the way the smartphone market works. Chet is still on the Android team 12 years later. And they've changed some things. They do code reviews. They have bigger teams. In fact, there's more people now working on the Play Store,

on the App Store, than built Android 1.0. But the Android team is still hungry. Even me mentioning that they've been successful seems to make Chet itch. Like maybe I'm tempting fate by calling them a success. I think of success as, I think Android was able to deliver this thing and stick around.

But we still run really fast and hard because I've been in tech for many, many years. Like you may have a good thing now and who knows what's going to happen several months from now. Like I've seen so many companies and technologies and products and entire platforms go away in a relatively quick amount of time because something new comes out. And some, you know, fad or some new capability or some new platform that we didn't envision comes out of nowhere. And then it's a matter of like how fast everybody around can pivot to take advantage of that or to become a player in that new market. And, you know, maybe, maybe you can't, I've been in companies that couldn't, their main products went away and they couldn't figure out what else to do. And then those companies went away. Right. And so, you know, you look at those numbers, you're like, well,

I mean, I guess Android's doing pretty well as a platform, but I want to be very careful. Like, yeah, we're out there now and we keep working really hard because we'd like to, we'd like to stay there. But it's, I think we're also very aware that competition is stiff and it always will be. So you guys are still running hard, I guess. You're still running like your life depends on it or? Probably a little less manically than, certainly than pre 1.0 or even when I joined. But it's a serious amount of effort,

you know, knowing what we need to do to provide the platform that other manufacturers and carriers want and that users are going to want on their personal devices. So like, what's the big lesson here? What do I learn from the Android story? Certainly one of the big takeaways is pursue your passion. It's clear to me, like people didn't join the team

and work that hard for many years because someone told them to do that because someone was paying their paycheck, right? Like these are people that were really passionate about working on that kind of software. And when they had the opportunity to do so in an environment where, oh my gosh, we could provide an entirely new platform in the world, wouldn't that be exciting? Then they just doubled down and worked harder than they ever had before. And the end result was they actually got to see that dream reach reality. Now, a lot of people don't, right? There's an undeniable aspect of timing and luck here. But I think if they had not had that passion, they wouldn't have had that opportunity

at all. And at the same time, even if it hadn't succeeded, they still would have had that opportunity at all. And at the same time, like even if it hadn't succeeded, they still would have had a good time working on this thing. Like it was really interesting for them to do this. They weren't just writing code because someone paid them to write the code. They were writing code that was interesting for them. They were solving problems that were fascinating. I think that's one of the hidden benefits of being in software engineering. I hope nobody ever tells our bosses how much we like doing this or they wouldn't pay us this much. Like, sure, you got to get the basics. It's nice that you can get a paycheck, but I don't think that's why people were there at the time. They didn't join Android because

someone said, here's a bucket of money. They joined Android because this was the problem they wanted to solve. And so to me, it's all about enjoying what you do every day. And maybe if you're really lucky, you get to see success out of that thing. And you can be with your friends and family and say, oh, look at that thing that I wrote. But maybe not. But in both cases, if you enjoy doing it, does it matter that much? I think it's more important that you actually enjoyed the journey because who knows whether it's going to lead there, but you do know whether you're enjoying the process of getting there at the time. It comes from like looking at the end goal saying, do I want to be a part of that thing? And do I want to march there with, all of my compatriots running with me next to me in the, in the four foot desk next to where I sit.

That was the show. Thank you so much to Chet. You should buy and read his book, Androids, the team that built the Android operating system. It's also available as an audiobook on Audible. There's lots that isn't covered here. He interviewed over 40 people on the early Android team. And you really get a peek inside of their lives. And if you like the show, if it entertains you, if it brings value to you, which I guess it must if you've made it this far, consider donating through

Patreon. That's what encourages me to put time into it. And it tells me that you want more of it. Also, this month for Patreon supporters, there will be a bonus episode where Chet shares some of his process of actually trying to get a job at Google. Getting on the Android team was not straightforward. It didn't initially go so well. So please find the Patreon link in the show notes or go to patreon.com slash Adam Gordon Bell. Until next time, thank you so much for listening.