Alpha DevCon 2018

Adventures in Alpha Land

Episode 8: Adam Bosworth, The ultimate product manager.

Dan Bricklin interviews Adam Bosworth, who helped define the modern software world we use today, including databases, spreadsheets and web browsers. In many ways Adam built on the conceptual legacy of Dan's spreadsheet work from the previous decade. The underlying theme behind everything Adam has worked toward since the start of the personal computer era in the early Eighties has been about giving users control and thus empowering them.

Adam Bosworth: "I'm a Lego block guy. I like to build things that make it easy for other people to build applications."

Show Notes

00:00 Dan: Intro to episode 8.

01:20 Adam: Start in computers.

02:00 Adam: Rebuilt Citibank's retail systems.

02:57 Adam: Started looking at the Apple II in 1978 and then VisiCalc, but couldn't convince Citibank to use Apple.

03:24 Adam: Left in 1982 to start Analytica and build Reflex.

04:24 Adam: Sold company to Borland, who sold 60x more product, partly by dropping the price greatly.

05:10 Adam: You have to make it possible to program in a spreadsheet, in this case Quartro for Borland.

06:21 Adam: Borland dropped the language in Quattro, I left, and was soon recruited by Microsoft to build Access.

06:29 Adam: Built Access as the product manager with a built-in use of programming.

09:06 Adam: I noticed in 1995 that many Access users were generating HTML for web sites.

09:55 Adam: Wrote internet Application Manifesto for Microsoft calling for what became Ajax.

10:51 Adam: Argued for a simple cross website information protocol for IE5. At the time it was XML, later it became JSON.

11:29 Adam: Added idea of Active Server Pages.

11:46 Adam: Focused on back-end of IE and built the DOM and Ajax.

13:34 Adam: Started building CSS.

14:35 Adam: We were ahead of our time. Javascript wasn't fast enough then.

17:33 Adam: Our one requirement was that we had to be faster than Netscape.

18:03 Adam: We added XML as a data language, and we then had everything we needed for Ajax in early 1999.

20:16 Adam: I argued that this could be used for a web mail UI, but I lost at the time.

21:10 Adam: Later I moved to Google and ran Google Docs, and we were focused on this vision.

21:22 Adam: When the Office team and the Windows team realized what we were doing, there was a lot of yelling.

21:40 Adam: The IE5 team was disbanded and many of the key engineers followed me to Google.

22:59 Adam: We didn't realize what we had with IE5 at the time, so we dropped a lot of the UI and Ajax functionality

26:42 Adam: This is all about Moore's law. Things become practical because of the increased speed of computers.

27:30 Adam: In 1998 when we built XML I had to fight that passing data as text instead of binary was almost as fast.

28:51 Adam: The big lesson is that simple, easy to use text formats... The moment Moore's Law makes it possible, they'll happen.

30:01 Adam: I went off to do cloud computing, 2001 was not a good year to do this.

31:19 Adam: Mobile started to look like the new frontier.

31:57 Adam: We went to Google, but were enjoined from working on mobile. We had to work on Google Docs instead.

32:10 Adam: How it felt to see Google Maps and Google Mail for the first time.

32:48 Adam: Story about Quartro.

33:26 Adam: I also built calendars and the spreadsheet stuff at Google, and ran GMail, and Blogger. It was validating to see this stuff worked.

34:09 Adam: Tablets and smartphones

35:05 Adam: Model View Controller

35:24 Adam: With mobile, everything lives on the mobile device.

36:21 Adam: We changed as profoundly with mobile as we did with the web.

37:07 Adam: Forms on phones or tablets.

38:24 Adam: It's not about productivity apps anymore, it's about getting information at the right time.

39:03 Adam: With Reflex and since, its speed, speed, speed.

41:33 Adam: Data will just be on your phone.

Transcript

00:00 Dan: Welcome to episode eight of Adventures in Alpha Land. I'm Dan Bricklin, CTO of Alpha Software. Today I'm talking with Adam Bosworth, chief strategic officer of Salesforce.com, about Adam's history as the developer and product manager of some of the most influential products in the history of modern software.

00:21 I'm interested in the evolution of the technology and use of today's HTML5 and related technologies in mobile, as well as desktop business applications. Adam, turns out, has been a decision maker and was involved in many of the steps that got us to where we are today. He's like the Zelig of software, but he was involved as opposed to just watching -- I think, I hope.

00:50 Thank you very much, Adam, for agreeing to be on this podcast.

00:54 Adam: Thanks for inviting me.

00:55 Dan: I figured I'd start with just asking you a little bit about your background. I figure we'll go back all the way a little to the Analytica days. What was your background getting into computers? How did you get to the projects that you worked on? What were the roles that got you to this point? Just go over them slowly.

01:20 Adam: I got into computers because it paid better and was less arduous than doing construction when I was in college. It turned out I really enjoyed it and I was reasonably good at it. It also turned out that what really interested me was the product more than the engineering. I built a bunch of interesting things for a technical company, when I left college, that I had worked for during college.

01:51 At some point I said, "I'm writing system software, and writing system software is not really my first love. I'm much more interested in the customer problem." John Reed was reinventing Citibank at that point. I went over there and basically rebuilt most of the MIS systems for him for the retail part of Citibank, which was about 300 companies.

02:14 Using, amazingly, a relational database way before Oracle -- this was in '77 to '81 -- and building what today we would call OLAP. Building tools for him and all of his managers to instantaneously pull up multi-dimensional reports on all the data that made up the bank, to figure out where they were making money and where they were losing money. And, when they were losing money, why they were losing money.

02:40 Dan: You started from a very big business.

02:44 Adam: I did. We had the biggest VAX datacenter east of the Mississippi for a while. I was only 24 when I was running it and running the software for it.

02:56 Then I started looking hard at what you'd done. I started looking hard at VisiCalc and Apple IIs in '78 and said, "Boy, about half of what I'm doing is data collection. And it's not done very well, and it's very expensive. It takes up over half of the computing power I've got. And I could outsource that to these little Apple IIs and not do this anymore. The user would have a better experience and I would have a lot more throughput."

03:22 Suggested that. The bank did not like that idea too much. I left to go do a startup on the West Coast called Analytica.

03:29 Dan: This is in nineteen-seventy-...

03:30 Adam: This was in 1982.

03:33 Dan: So it's after the IBM PC came out. Right after.

03:36 Adam: Right about that time. I actually prototyped the whole thing in 6502 code with a friend of mine called Eric Michelman. We hired two amazing people to start it. I called Brad Silverberg who later ran Windows for years, and in between ran the R&D for Borland. And a guy called Ken Ong, who most recently ran Google Analytics for six years. Helped me build the stuff you're probably going to talk about, which was IE4 and the Trident engine and is now working for me at Salesforce.

04:07 We hired a great group of people and we set off to build a really good way to understand and analyze data interactively and in real time. We built a company that was good at that. There was a small problem. We were not particularly good sales and marketing people.

04:25 To put that in perspective, after about a year of trying to sell it, Brad and I sold the company to Borland. We were doing about a thousand units a month in a good month. And Borland turned around, ran a three-week marketing campaign, and proceeded to sell 60,000 units a month.

04:42 Dan: They dropped the price from $495 down to $99 when they did that.

04:46 Adam: They did, which Eric and I had been arguing about, and that was obviously a key part of it. It turned out there was a lot of elasticity of demand. Later on at Microsoft we took note of that. The thing that we learned, though, is I had no headroom. Alan Kay is famous for saying simple things should be easy and hard things should be possible.

05:05 Actually, when you say hard things should be possible, there's an interesting implication. You have to have a way to take a declarative tool like a spreadsheet and procedurally extend it, so developers can come in and do things you otherwise couldn't express in a declarative tool. Otherwise, people hit the wall.

05:24 And I went off to do Quattro, because I was interested in that. And I actually not only built a macro language and a debugger for Quattro...

05:30 Dan: Quattro is a spreadsheet, for those that don't remember.

05:33 Adam: It was an old spreadsheet. But I also actually built a way for Turbo Pascal and Turbo C to be used to extend the product. I argued with Philippe Kahn, who ran Borland, that this was our secret sauce. We couldn't compete in a feature war with Microsoft or Lotus, but we could compete on the language front.

05:50 We were the best language company in the world at that point. If our languages became the extensibility mechanism for spreadsheets and databases -- and we were buying Paradox by then -- it would be very hard to unseat us.

06:02 As it turned out, after I launched Quattro, another guy came in and convinced Philippe that we shouldn't do this work. We'd actually already built the APIs. We'd already worked. In fact, we had major features in Quattro that used this technology. I thought this was strategic suicide, and I left.

06:21 About nine months later, Steve Ballmer and Bill recruited me up to Microsoft to build Access. I went up, built Access for Microsoft. Learned a lot, but built, basically, the extensibility model that I thought made sense, so that declarative programmers can build database applications in Access, but programmers can extend them when necessary.

06:44 Dan: It has a forms language as well as a programming language.

06:49 Adam: Right, but the big thing I learned, from you actually, was expressions. The big thing Access had was that most things could be described by expressions. The color of a field could be described by an expression. The font could be described by an expression. The validation rule could be described by an expression.

07:04 But you could also write code and say, "This is what's going to control these values," instead. A location could be a piece of code that controlled the location of a bunch of fields, for example. That gave us a lot of headroom.

07:19 That worked out surprisingly well. We thought the total market for databases was about $200 million in those days. Access went to $200 million all by itself in the next two years and grew significantly after that. My key guy was a product guy on Access, running the product marketing...

07:38 Dan: You were what? You were the head of the project?

07:40 Adam: I was the group product manager and, really, it was my product.

07:43 Dan: It was your product. You were the visionary of what should be in it? Did you code anything?

07:48 Adam: I did not code it. I ran the product management and doc and QE, and basically teamed up with a great guy, called Bill Marklin, to run the engineering. Neither he or I would write the code. I missed that. It was the first time I hadn't written code in a long time.

08:03 Dan: You had been coding until then?

08:05 Adam: Yes. Until then, I had been coding.

08:07 Dan: There's this product manager, you said?

08:10 Adam: Yes, I hired a guy called Tod Nielsen. Tod Nielsen was the product guy for me on Access, and was great. Tod and I teamed up thereafter, and Tod and I worked at Salesforce, and was the CEO of my last startup but one. We've worked together again for much of the last 25 years.

08:34 We built Access, and I started to build the next generation UI technology for Microsoft. You may never heard of Forms Q, but it showed up in terms of the forms and programming model and DBA within Office for Office and Microsoft.

08:51 Then I took a long sabbatical in 1995, a three-month sabbatical. I came back in the summer of '95 just when they were doing Start it Up with the Rolling Stones on Windows 95. It was total mayhem. I noticed that a lot of the customers of Access were using HTML.

09:11 That got me really interested. Why were they using HTML? What were they trying to do? I very quickly discovered that this was a much, much easier on-ramp to do things. Then, of course, anyone in the world could do it, not just an Access user in a lab.

09:26 I said, "Wow, this is the future!"

09:29 Dan: They were using Access to output HTML?

09:31 Adam: Yeah. They were basically running gateways between Access and HTML servers. I said, "Why?" I looked at it, and it was immediately obvious that this was compelling. Suddenly you had this extraordinary thing where you could build an application that anyone, anywhere in the world, could access.

09:48 It was also immediately obvious that there were things you would like that you didn't have if you were going to do that. So I wrote this memo at Microsoft called "The Internet Applications Manifesto" in the fall of '95. I basically argued for three things.

10:01 I argued that we needed to extend HTML to have, in essence, the ability to dynamically manipulate and shape the page in response to user interactions. We have right now a static layout once it was rendered. If the user was clicking or doing things, you didn't want a round trip back to the cloud, because that was expensive, but you really did want to be able to react to what the user was doing. For example, if they say, "credit card" or "PayPal," you want a different UI to show up.

10:29 Dan: In those days, if you clicked on a button, usually it would do a submit that would send a post back to the server. The server would then send totally new HTML back.

10:38 Adam: That's right. You had to round-trip and render everything from the server. My view was that was not the right program model. It was not the right latency. I also argued that we had to have a way for websites to talk to each other. Believe it or not, in those days, the prevailing wisdom from Sun, Netscape, and Microsoft was distributed objects.

10:57 I argued that was insane. Even within an enterprise, it was really, really hard to get distributed objects to work, because people didn't agree about how to implement them and change the contracts. Across the web, there was no way in hell this could work.

11:11 HTML had proven that there was an alternative strategy, which was to ship datagrams from point A to point B that even a PHP programmer could write. In fact, you could theoretically write with a text editor if you wanted. Today, we call this JSON. At the time, I picked XML. I argued we needed a way to ship data between locations.

11:29 Lastly, I started something called active server pages, so that mere mortals could dynamically build web pages. I ran those three things. At a certain point, I had to choose between IE and active server pages. They said, "You can be the front end or the back end, but not both," so I focused on the browser.

11:46 We built what today is called AJAX. We built the DOM, we built the asynchronous loading of data, we built the XML...

11:54 Dan: What you built is the ability for JavaScript to have access to the DOM to be...

12:01 Adam: We had to build the DOM.

12:02 Dan: You had to build the DOM so there'd be something to access.

12:04 Adam: We built a programming model for a JavaScript programmer to be able to dynamically manipulate and alter the page in response to user events.

12:11 Dan: Had that been in Netscape or anything before that?

12:14 Adam: No. Netscape, at that point, had a way for JavaScript to do a couple of things, mostly dynamically render the page.

12:24 Dan: It could write into the page...

12:26 Adam: As you are rendering the page.

12:28 Dan: It could write text into the page, which was then evaluated as bracket, bold bracket, or something like that.

12:35 Adam: We went and worked with the Worldwide Web Consortium. I had a great guy working for me called Scott Isaacs. Scott Isaacs basically became the evangelist for what in those days was called dynamic HTML, and went and fought for this model of the DOM, fought for the model of being able to dynamically modify the page.

12:55 There were big debates about how this shit actually worked, because there are some things that you could do more easily and more cleanly if you knew about HTML5. HTML5 is a tree. A tree is a much easier model than what the DOM actually exposes. But in those days, you could have overlapping nodes. You could have a bold and a close and an italic, followed by a close bold followed by close italic, so they're overlapping.

13:20 That's not a tree. We debated whether or not we should just ignore what Netscape did, decided we should not, we have to be compatible, and exposed a programming model that was more complicated, accordingly.

13:32 Still, we built this thing. At the same time, we were building CSS.

13:36 Dan: CSS was specified already? The early CSS, at that point?

13:41 Adam: It was early CSS. A really bright guy at Microsoft was part of this, called Thomas Reardon. Thomas and I used to argue about it a lot, because I thought CSS was too complicated. I didn't like the inheritance model. Nonetheless, we were building this.

13:54 We were slowly thinking about, "How do you separate the CSS rendering from the actual language?" We were doing this anyway in the DOM, because we discovered that really what we did is we attached logic to divs a lot. Rather than worrying about the HTML tags, a lot of the time we were writing JavaScript basically attached to divs, which today we all know as JQuery and things of that sort.

14:18 The first thing we realized, when we're building this, is we need an easy way to collect a collection of DOM nodes that met some criteria, and then iterate over them, in logic, which became the basis later of JQuery.

14:32 JavaScript wasn't fast enough then. We were frankly ahead of our time. We launched this stuff. We had these cool demos and things like Tetris running in the browser. The real issue was that it turns out a real app, which really has dynamic UI using HTML, actually has a lot of JavaScript in it. We had somehow thought it would be a couple of thousand lines and we could move it over the Web fast enough.

14:53 It turned out, no, there's actually a lot of JavaScript involved. There really were two issues. We didn't have broadband in those days and the processors were just not fast enough on the PCs to run that amount of JavaScript, that fast. In essence, this technology sort of went into hiatus.

15:08 Dan: You developed this for...

15:11 ...a particular user? Or just because you believe in building tools for people to build stuff?

15:15 Adam: I'm a Lego block guy. I like to build things that make it easy for other people to build applications. I like to make hard stuff easy.

15:21 Dan: How big was this team that was working on it?

15:24 Adam: It was big.

15:24 Dan: This is DHTML?

15:25 Adam: This was called the Trident Team. It replaced the browser engine in IE. Basically IE4 was a completely different engine than IE3.

15:33 Dan: Before that, they had something they had bought from Spyglass or something?

15:37 Adam: Yeah...

15:38 Dan: I remember we had used some of their code too, years before, at...

15:41 Adam: They bought it from Spry, got it from Mosaic, then they'd hacked it and then hacked it again. The reason we were able to replace the code base was it was a code base that had never been that well engineered. It had been rebuilt under the gun three times in a row and was just hard to manage and maintain.

15:57 Dan: We had done some work with some Spyglass stuff. It was designed for print, originally, some of the basic stuff.

16:02 This is the re-implementation for Microsoft, from scratch, of the Trident engine that we still use the name today, started for IE4, was it?

16:13 Adam: IE4, yep.

16:14 Dan: And it was a big team?

16:16 Adam: We built it in '96, and it was a big team. It was 60 people.

16:18 Dan: Wow.

16:19 Adam: It was 60 really, really good people. In fact, there was a lot of grumbling at Microsoft, because in those days there was what was called D13s, which were sort of godlike dev figures. You had one per product, and we had six. It was a really good team, very strong, and it had to be. It's hard to build a really good, dynamic rendering engine.

16:41 In fact, we made one trade-off early on. We were looking at this and we realized that, for really large pages, the text engine we had wouldn't scale well. But we also realized to rebuild that from scratch would take us too long.

16:53 We launched it knowing that we were going to have to rewrite this piece of the logic, basically the rendering engine. But it was launched, turned around and built IE5 with this horrendously difficult thing called the "Fun Fork." We basically changed the rendering engine, broke every test case, and for six months just soldiered on to fix everything, but ultimately had a rendering engine that could run against arbitrarily big pages, at a reasonable speed.

17:19 Dan: You were balancing both knowing that you were going to do it in CSS and knowing that you were going to have JavaScript playing with the DOM. You have to render existing stuff, and it has to be fast.

17:32 Adam: Yeah, it had to be faster than Netscape. The one requirement we gave the entire team is that we had to render faster than Netscape, period. In fact, that was a key feature.

17:41 I shifted over in '97 to build the XML stuff. I had a guy working for me on the iTeam called Jean Paoli. He was one of the first three people to build the XML spec. It was Jon Bosak, Jean Paoli, and someone...he's at Google, great guy.

18:02 The three of them had done this, but they were thinking of XML as something very different. I went down to the working group and said, "I don't want XML to replace HTML. I don't think that's going to work. I know you do, that's nice. I don't think that's going to work. But I do want it as the datagram language to move data around and to be able to dynamically load data into the browser from the server."

18:25 They agreed, very nicely, to work with me. We teamed up on that. We built the XML engine, stuck that in IE5, so in IE5, for the first time you actually had what today we would call AJAX. You had asynchronous loading of data, obviously with the DOM, but then you had a rendering engine that could handle all this. That all launched around, I want to say early '99.

18:46 Dan: So the XMLHttpRequest object, you realized you were going to need it. You knew that it should be XML. You decided it should move around XML as opposed to binary data.

19:00 Adam: We didn't know about JSON in those days. If we'd known about JSON, we probably would have picked it, quite frankly. But we didn't know about it.

19:08 A second thing was that we thought dates were very important and JSON doesn't have a date type. It didn't actually occur to us that this was enough to describe all the data you would use. One of our first demos was an auction demo that we put up on the web and gave open source too. We did a lot of open source at that point. When we built the XML engine, we built it in Java and we open-sourced it.

19:30 Dan: I remember you were using OWA, the Outlook Web Access, the mail client for Outlook. Did that use this AJAXy, XMLHttpRequest object?

19:45 Adam: It started to. Hotmail had come out and had not yet been bought by Microsoft. In fact, my boss John Ludwig and I had a big argument about the viability -- it sounds funny now -- of web-based email. Later on, among many other things, I ran Gmail at Google, so there's a certain satisfaction in proving this wrong. But I didn't build it. I just ran it. A great guy called Paul Buchheit and a guy called George Harik actually built it.

20:14 We had an argument about this. I said, "Look, you don't understand what's possible with the DOM and with this technology we've built. You can build really good interactive user experiences now in the browser. This will replace the bespoke mail engines as we know them." He did not agree. But later on, as you say, they started to experiment with this.

20:38 Dan: There were all these pieces necessary to be able to do interactive JavaScript, HTML, without going back to the server each time. Were there arguments about not to do that?

20:53 Adam: Oh, yeah. We had very ambitious goals. One of the things we did was we bought a really, really good graphics team to make sure that anything you could render in PowerPoint, you could render on the page. Later on, I ran Google Docs, and we were pretty focused on that vision -- not just making it possible to build apps but actually being a rendering and interaction engine for docs.

21:18 Once it was understood both by the Office team and the Windows team what we were doing, which was essentially building an alternative platform that did not require Windows, conceptually, there was a lot of yelling. In fact, when I say there was a lot of yelling, let me put this in perspective. After the IE5 team shipped, the IE5 team was, largely speaking, disbanded. They were sufficiently worried about it and many of them followed me.

21:49 I went off to do a startup called Crossgain. Many, if not most, of the key engineers on IE5 and on .NET followed me to Crossgain, then to BEA, and then to Google. There was a lot of antagonism at that point towards what we'd done.

22:08 Dan: Like the editor -- they didn't put in a really good editor of HTML as part of the browser for a long time.

22:15 Adam: Funnily enough, that was one of the original visions, and it's one of the reasons we were able to build the DOM. And then we didn't do it. It's actually worth looking at what happened. Originally, when we were building this, we thought we were going to build in an editor. One of the reasons we had the DOM...

22:29 Originally, frankly, we hadn't really understood the power of the programming model. We knew we wanted to be able to dynamically, interactively modify the pages. But we were still figuring this out. We did know we wanted an editor. So we built this object model. So you could write an editor to go and edit.

22:43 And we actually had pages you could dynamically edit pretty nicely and very fast. Then we realized we didn't know what you did with them. In other words, you rendered a page, you looked at it, you edited it, then what? We didn't have a story.

22:56 Meanwhile, we were focused on competing with Netscape. It's one of those things -- when you're focused on what you're competing with, you tend not to do the things that you could do. So we actually deprecated this. We got rid of the UI code. We were buying Charles Ferguson's company anyway.

23:13 Dan: Right. That was FrontPage.

23:15 Adam: Yeah. We got rid of the editor and we just used it as a programming model. We originally had an editor in one of the early incarnations of Trident. You could go and edit the pages.

23:26 Dan: This was like in 19...

23:27 Adam: This is '96. We pulled it out by the end of '96 and said, "You know what? That's not our job. We'll just focus on a programming model, a rendering model, speed, and asynchronous data," and that's what we focused on.

23:42 Dan: You ended up with this XMLHttpRequest as an example of a name. What terminology internally were you using for what you were doing, what it meant to modify the DOM?

23:57 Adam: We were learning as we went. Frankly, originally we didn't understand this that well. We figured out right away that we wanted an asynchronous data-loading model, so we called these asynchronous data adapters.

24:07 What we didn't figure out right away was that there was only one model that mattered. There was going to be one payload. Microsoft was good at adapters. Among other things I'd built ODBC when I was there, before doing any of this.

24:20 Dan: That lets you have all different data sources be accessed using the same API.

24:24 Adam: Right. So we said, "Oh, it'd be good to have an adapter of ODBC," which really showed that we didn't understand yet the web. Because there are ODBC clients on a Windows PC, but obviously that's not a very loosely coupled model.

24:39 We pretty quickly realized, "No, that doesn't work." This is all about HTTP request response. If you can't get the data payload through the request response, this isn't going to work, so we backed off that too.

24:53 The original terminology was data adapters and asynchronous data adapters. Frankly, a lot of credit for getting that right actually goes to Jean Paoli, who worked for me and staunchly argued for his concept of XML. He was smart and I paid attention to him. Then slowly we figured out, "No, this is just like HTML. This is a payload model. This is a text model."

25:18 Dan: And you allowed both types of...you could have both XML or plain. It doesn't have to be XML.

25:23 Adam: No, it could be anything.

25:25 Dan: It could be anything, right. You're allowed to have any...

25:26 Adam: We built in a parser. The problem is we had to build in a parser. Then you had another DOM, the XML DOM. The XML had to navigate it, I mean, JavaScript. Whereas, the great thing about JSON is you automatically parse it. It's just there as an inline data structure.

25:42 Dan: Yeah. What got thrown out of that? Did you have a lot more in the request object and then you threw some stuff out?

25:52 Adam: Yeah, we did. Initially we had things where you could read SQL Server. We had a bunch of adapters we built to read a bunch of data types. When I went off to do the XML team, we were the ones who actually built the request object. We didn't bother doing any of that. We just focused on XML and text.

26:11 We basically wrote a bunch of ASPs that could serve up data. There could be asynchronously requested by that object. If you couldn't express it in text, we didn't do it. That meant that all those other binary formats just went by the wayside at that point. That was '97, '98 we built that.

26:29 Dan: The decision to be all text was an interesting switch that occurred. Before, like in Microsoft, you would just...then the old MFC stuff, you would just serialize everything and who knows what format it was?

26:42 Adam: Well, this is all about Moore's Law. At the end of the day, like everything else in computing, Moore's Law is inexorable. Periodically, you have these inflection shifts, these tipping points, where things that were just not practical before become completely practical because of the power of computing.

26:58 Right now, these days, we take for granted that really serious applications can be built in node.js and JavaScript, in the front end of Ruby, or whatever it is. That would have been unthinkable in those days. You don't need a JVM anymore to get the kind of speed you need, because we have massively parallel computing in the cloud, and there are really, really fast processors. And also we got pretty good at optimizing.

27:23 At the time, we didn't know that. The same thing happened with text. In fact, what happened was kind of interesting. In '98, we built the original XML stuff. One of my friends was a guy who had done DCOM. A very smart guy. And he said, "This is the craziest idea I've ever heard of. You can't actually marshal data between things using text."

27:45 We were having lunch at some Indian restaurant up in Redmond. I said, "Absolutely you can. I bet you that if you do this and you test it compared to DCOM, you'll have, at most, a 10- percent degradation if you do it between two different Internet sites."

27:58 Dan: Because DCOM was all binary.

28:00 Adam: It was all binary. It was super-optimized. It was marshalled up the hilt. The thing was, ultimately, it was pointwise optimization. The actual marshalling was super fast, but you were going through routers. You were going through IP protocols. You were going across the net. There was a ton of stuff going on that had nothing to do with the marshalling.

28:19 He tested it. He actually built the first Web APIs using this. To his amazement, it was actually very quick. It wasn't as quick as DCOM, but it was close, and obviously it was infinitely easier to do and infinitely easier to inspect and introspect.

28:34 Dan: This is like how mail with POP and IMAP and all that beat out X.25, et cetera?

28:41 Adam: That's right.

28:42 Dan: The simple text format that you can do with a text editor and cURL or something actually works.

28:50 Adam: I think that's the big lesson. Simple, easy-to-author text formats...you know, it's "vox populi." Basically, many, many, many more people can build such things and use such things than strange obscure binary formats.

29:05 Because they can and do use such things, the moment Moore's Law makes it possible they will. They're voting with their feet, and you'll get either ten times or a hundred times as many people doing this as you would if it was a binary format.

29:18 That was my insight about Access. I went and I looked at HTML. It was this easy text format that you could actually author with an editor, never mind easily author with a tool. Comparatively speaking, Access's format was this complex binary format. Incredibly, it was even as fast to load, because it was simple.

29:38 Over and over we see this in history. People build these really optimized binary formats and then they're replaced by simple text formats and the world never looks back.

29:50 Dan: Yeah. That's really cool.

29:52 Let's see. Access, and then you said the DHTML stuff. Then you went off to Google.

30:02 Adam: I went off to do cloud computing...

30:04 Dan: The cloud computing, yeah.

30:05 Adam: The interesting thing about the Web was that you had to have arbitrarily fast scale. No one really knew how to do arbitrarily fast scale. That was the one hard thing. If you went and built a website, you were expecting 100,000 people to show up, and suddenly 10 million people showed up, you were in big trouble.

30:20 At the time, no one really knew how to do that. They were still thinking about connection pooling, for God's sake. So I went off with most of these guys who built the XML and IE4 stuff with me to go and figure out how to do this. We started a company called Crossgain to be an easy programming model for massively scalable computing on the cloud.

30:42 As it turned out, Ballmer was pretty pissed about this and tried very hard to close us down for a year. It's hard to compete with a company like Microsoft when you're a 20-person startup. We actually had to fire ourselves, wait out our non-competes for a year, come back, and by then it was 2001. 2001 was not a good time to be building cloud computing. So we sold the company to BEA Systems and pivoted to basically focus on making it really easy to do J2EE.

31:10 I didn't go to Google until a couple of years later. I sold the company to BEA Systems. Worked there for a couple of years, and at a certain point got interested in mobile, because mobile was starting to look like the new frontier. I started building a framework and platform for how to build mobile apps. At that point, Google, which had reached out to me in 2002 to come aboard, reached out to me again and I said, "Boy, I'd love to come, but I really want to bring my team with me."

31:36 BEA agreed in theory. We had this whole deal worked out. Google was going to pay BEA for this team. There was a press release written about, "BEA and Google team up to do this," which was a polite way to say we moved, but money transferred.

31:49 Then at the last minute, BEA decided no, they didn't want to do this. What happened is we all left anyway and went to Google, but we were enjoined from working on mobile -- which was really annoying, because that's really what I wanted to do. So I ended up doing Google Docs for a couple of years, and the team...

32:08 Dan: How did it feel when you saw Google Maps and Google Docs for the first time?

32:16 Adam: You can imagine how it felt. Google Maps and Google Mail were so validating that words can't describe it. By now, Moore's Law had come to our aid. This technology we built was viable. Frankly, we had never thought of something like Google Maps. We looked at this thing, went, "Oh my God, we thought we knew what we were doing but we didn't," which I think is true of all platform developers.

32:39 Dan: Oh, yeah. Tell me, yeah.

32:40 Adam: You built spreadsheets once upon a time.

32:43 Dan: Who would have thought what people were using them for? It's unbelievable.

32:48 Adam: The funniest thing I ever remember was I was building Quattro, and we had to be compatible with Lotus. These guys sent in this spreadsheet saying "It's not working." I said, "What do you mean, it's not working?" They said, "Look at it on 123." I bring up this thing on 123 and there is a circuit diagram. They've used the x-y charts to do a complete circuit diagram.

33:06 I stare blankly at this. It's turtle graphics done on top of a spreadsheet, essentially. I go, "Oh my God." I go and look, and our rendering is all off. We had to go fix it. Who would have ever thought you did circuit design, visually?

33:19 Dan: That's incredible. That's all you saw when you saw...if Jon Sachs looked at that, that's how you felt when you saw Maps.

33:25 Adam: When I saw what they'd done with Maps, and then I also built Calendars and then the spreadsheet stuff at Google. I ran Gmail to get it...there were some operational issues, and took over Blogger from Evan Williams and Biz Stone.

33:38 It was extraordinarily validating to see that now this stuff worked and it worked really well, because we now had broadband and we had very fast processors. All of a sudden, people were experimenting with using HTML to build really rich, interactive applications that scaled really well. So it was great. I loved being there. I loved building that edifice.

34:02 Dan: What do you think of the difference, in the mobile world, between tablets and smartphones? Given your background, that's interesting.

34:12 Adam: I just bought a 6 Plus. It's very interesting. Now that I have the 6 Plus, I've stopped travelling mostly with my Mini. The only reason my Mini is still even relevant to me is I've been using the PowerPoint that Microsoft shipped for the iPad Mini, which is surprisingly good. I can build every presentation I want to build on PowerPoint on the PowerPoint for the iPad Mini.

34:36 And the iPad apps don't actually run on the bloody 6 Plus. I'm like, "Please fix that."

34:41 Dan: It's hard, because they also then have to run on the 5, sort of.

34:46 Adam: Yeah, I don't want it to run on the 5.

34:48 Dan: I know, if only they made the 6 Plus run in iPad mode, we'd all switch.

34:51 Adam: ...saying, "If only the 6 Plus could run in iPad mode." And I'm sure they'll fix that sooner or later.

34:55 But I give this talk at Salesforce, because people don't always understand that. I say, "Look. When you started this company, we had this thing called Model View Controller, and that's how apps worked. The model and the view and the controller basically were all built on the cloud, and then you delivered the view language up to the client and the client rendered it. The only thing that really was running on the client was the view."

35:21 Then I said, "Now, that's not true. With mobile, everything lives on the...the model and the controller and the view all live on the mobile device, because otherwise you don't get the latency and user interaction you want."

35:33 And by the way, that's what I had been building at BEA Systems, a model where all three of them lived on the mobile device. Think of it as a different kind of HTML5.

35:41 When that happens, the role of the cloud changes fundamentally. It's not about building the model logic or the view logic or the controller logic. It's about acting as an orchestrator. It's about basically keeping the master data in sync with the client.

35:56 It's about, if exogenous events occur that you need to know about or you're doing machine learning and there's now things that you want to recommend, those things flowing to the mobile device. It's about invoking remote services like PayPal or Stripe.

36:17 All of the logic is moved to mobile. I think we've changed as profoundly with mobile as we changed when we went to the web. The program model changes again completely. It's no longer about a web-based HTTP protocol. Now what's really important is putting logic on the device and then having REST APIs just to keep you in sync and keep you in sync efficiently.

36:45 Dan: So you like the bigger device. In terms of business use, you come from the world of Access and stuff like that -- those types of applications. Are all those going to migrate to either big phones or tablets or big tablets?

37:08 Adam: Largely speaking, we're figuring out how to get rid of a lot of those things. Access was a forms tool, and forms don't work well on mobile devices. There's too much typing. But what we've learned is there's a lot less typing required. We can predict. We can anticipate. We can give you nice drop-downs. We can auto-complete.

37:29 Mostly, we've tried to get rid of the forms model entirely and say with some swipes and some clicks, you can describe what you want.

37:36 Dan: You can draw on it. I have an Ink app on the iPad.

37:42 Adam: The other day I had to do a PowerPoint thing. I was on the road and all I had was my iPad Mini. I had to do a very complicated graphical diagram describing the architecture of what I was building here. An hour later, I'd done it, and it wouldn't have been much faster on PowerPoint. I don't bring my Mac with me anywhere now. I just travel with my phone and my Mini, and I think very soon I'll just travel with the phone.

38:07 Dan: As the phone becomes the size of the Mini.

38:12 Adam: Yeah, half the size. It's a little funny. My wife laughs at me when I hold it up to my ear. But it works OK.

38:18 It's not about productivity apps anymore. The world is really about consumer apps. The world is about how do you get the right information at the right time in the right way -- without overwhelming or pissing off your customer -- to the customer? It's a push world, not a pull world.

38:39 And that's the big difference between the mobile and the Web. The Web was a pull world. You went to a site and the site pulled data from somewhere. Now you have an app and data flows into the app, and a badge tells you that there's new data to operate on.

38:53 It looks like I'm going to have to run in a minute.

38:56 Dan: Quick thing on Reflex. In the old days, Reflex was known for being very fast and incredibly detailed, careful UI. Was that true with the mindset back then?

39:13 Adam: Yeah.

39:13 Dan: And is that what you've pulled with you ever since...

39:16 Adam: Ever since.

39:17 Dan: ...all the way through, or the speed?

39:18 Adam: When I was doing Reflex, the venture capitalists asked me, "What are the important things in user interface?" I said, "There are five, and the first three are speed, speed, and speed." I have believed that ever since. I still believe it. Larry had a different way to express it at Google. He used to count keystrokes, but he also counted milliseconds. The goal was to have everything rendered in 300 milliseconds or less.

39:38 I firmly believe this. This was one of the reasons for DHTML. I didn't think it was viable, every time you clicked on a drop-down, you'd have to wait two seconds or even a second for a new page to render. That had to happen in a split-second time.

39:54 From my point of view, there's a huge psychological difference between an app responding immediately to what you do and you waiting for the app. In one case you're in charge and it's a tool. It's like a pencil. In the other case, you're not in charge. You're waiting on this thing, and you feel like a slave. You don't want to feel like a slave. You want to be the boss. You don't want to be the slave.

40:21 Even before you get cleanliness and beauty, you have to have responsiveness. It's the number one feature of user interface. We learned how to do it with a browser. Now we're learning how to do it with the phone. When it's done wrong on the phone, you get pissed. It's like, "Wait a minute. I use other apps on the phone that respond immediately."

40:36 There's no excuse for it, because BlackBerry showed us a long time ago on a pager network, for God's sake, that you could do this. You do it through asynchrony. The big magic word is asynchrony. You basically let the user do whatever they're doing immediately on the device. Then, in the background, asynchronously, you catch up based on the quality of the network. But you don't block. You don't put gears up.

41:00 But that model requires a user interface that is much more organized around tasks and information than it is around filling in forms or, worse, retrieving rows. The way you want to get around retrieving rows...I have 128 gig on my phone right now. Five years ago, I couldn't have had more than 16. Three years from now, I'll have a terabyte phone.

41:24 Well, it turns out a terabyte is a lot of data. You look at what most employees need to have access to, most of the time a terabyte is more than they need access to. For productivity apps, I think the data will just be on the phone, and you'll just keep it in sync. There will be no concept of you waiting for data. Data will just be on your phone.