The XML.com Interview: Jeff Barr

As part of XML.com's ongoing series of interviews with personalities from the XML world, I talked to Jeff about XML, web services and Amazon.

Q: How did you first come across XML and web services?

Jeff Barr: I've always been interested in software platforms, because they reduce complexity, enhance portability, and provide a strong base for innovation. In the early 1990s I spent a lot of time in the cross-platform user interface toolkit business, working on a very complete platform known as Galaxy. After that I spent some time at Microsoft, where I first learned about XML and SOAP. My first practical experience with XML revolved around the use of RSS to distribute news headlines in 1999 or so. I built one of the first desktop news clients at that time.

The emergence of XML-RPC and SOAP really brought all of my interests into focus. XML provided portability, and the protocols provided the way to create a platform that could be programmed not just locally, but from anywhere. Based on what I had learned in my work with cross-platform toolkits, it was clear that a solution which was independent of any particular platform, language, and networking topology would definitely be a big winner -- they would enable anyone, on any type of machine, anywhere on the network, to use the platform to create cool applications.

Q: How did you come to join Amazon?

JB: I was consulting for some VCs and startups in the areas of XML, XSLT, real-time notification, and web services tools. One day I logged into my Amazon Associates and saw a message which said "Amazon Now Has XML!". I clicked on it, registered for a developer token, downloaded the SDK, and was immediately captivated by the possibilities. Within an hour or so I sent a message back to Amazon with my feedback, both positive and negative. Turns out that they had just released the beta version of the XML interface that very day, and that my feedback was among the first that they had received.

A month or two later Amazon hosted a small conference to discuss their web services plans with outside developers. I was fortunate enough to be invited to that conference. After listening to the first couple of speakers, several things were very clear to me. First, Amazon would become a locus for developer activity, and that they would need all of the traditional "trimmings" needed to attract developers. Second, Amazon was chock full of smart people. Third, that something this cool wouldn't happen that many times in my lifetime.

The Amazon folks were very interested in getting feedback from each attendee, and it was clear that they had done enough homework to know who we were and what we were interested in, up to and including Jeff Bezos himself. By the end of the day I decided that I wanted to be a part of what was clearly and obviously going to be something of tremendous importance to Amazon, of direct interest to developers and to entrepreneurs, and that was a leading indicator of where the industry would be heading -- the programmable web site. I mentioned my interest to my host, interviewed at the company later that year, and before I knew it I was part of the team.

Q: Do you still do much programming? If so, what's your favored environment?

JB: I get to write sample and demo code, and I also work on personal projects from time to time. For web work I am definitely a devotee of LAMP, having written lots and lots of PHP over the last couple of years. I also do some Perl, and would admit to being pretty good with C and VB6. My fingers are hardwired to type Emacs commands without any conscious thought, and the oldest entries in my .emacs file date back to the 1980's. Lately I have been noticing that programming is less and less about the language and more about the toolkits and platform underneath. This seems especially relevant in the era of web services, where developers can use almost any language, tool, or toolkit to make SOAP or REST calls, and process the results. After many years of trying, we have finally reached that long- elusive goal of creating cross-platform, language-agnostic services.

Q: Have web services been successful from Amazon's point of view? What do you think the reason for the success is?

JB: I am very pleased with the things that I have seen coming from our developer community. When measured by the number of developers, number of sites, and the number of applications, I think we are doing great.

The reasons for this success are simple to state, yet sometimes difficult to put in to practice. To me, a lot of it goes back to that first pre-release conference, where the Amazon team members were so eager to listen to and learn from the developers. Since then I have in fact learned that one of our primary rules is in fact "start with the customer and work backward."

We listen to our developers in a variety of ways -- feedback on our discussion board, messages in our weekly chats, some surveys, and email sent to us in response to articles in our newsletter. Each of these messages gives us the info that we need to provide an even better service in the future. Many features of each release were implemented in response to specific requests from developers. Since we are web-based, we can close the feedback loop really quickly -- from request to implementation to deployment in a matter of weeks in many cases. From our side it is great to be able to listen, but it is even better to be able to respond. In some cases a developer might be "one bug" away from releasing something cool. It is gratifying to be able to help them realize their dreams.

Another aspect of our success is the fact that we made sure that the web services were actually supported by a sound business model at the time of release. This is important. Web services done as a "science experiment" will never produce the return needed to ensure a continued investment. We made sure that there were reasons for developers to use the services and for Amazon to continue to support them.

Q: Doesn't it worry Amazon that they're giving away so much computational power and data for free?

JB: There is now a real awareness that we have unlocked lots of latent creativity and untapped talent within the developer community, and that this is a good thing. We have a lot of hard-core developers within the company. These developers are very pleased to see Amazon on the leading edge of a new, public, and very exciting technology and are very eager to do what they can to help further the cause. I am often asked "how many people are on the web services team?" I honestly tell them that the entire developer team within the company contributes to the success of our web services product in some way, shape, or form. This is literally true, because the web services are effectively an alternate interface to the technology "behind the glass" of the web site.

Q: Simplicity seems to be key to some of the Amazon API. What do you think about the increasingly complex world of web service specs?

JB: Indeed, we have tried to keep things simple. As you probably know, achieving simplicity is a lot harder than it looks. One of our goals has always been to make sure that it is possible for a developer to make something work within a very short time frame. It doesn't have to be complex, but they should be able to see some data on their screen on the same day that they get their developer token and download their free AWS SDK. The REST model is particularly good in this regard, since they can do their prototyping and initial exploration in the browser, modifying the URL and refreshing (which I sometimes like to call "URL surgery.").

Standards are very important. Off the top of my head, I can say that we depend on HTTP, DNS, XML, XSLT, SOAP, Unicode, and also some ISO standards for data representation. With that said, I believe that it is very important to implement standards based on real needs from real developers. Striving for total "buzzword compliance" can be an expensive and frustrating exercise. There is always a gap (sometimes several years) between the introduction of a standard and widespread understanding and adoption. Once again, listening to developers and paying attention to what they say pays off big-time here. Developers will often ask for features or capabilities, not always adherence to particular standards. I have noticed that our developer community is quite pragmatic, focused on getting the job done. If a standard can help them then they are happy to use it, but in general they don't want to sit around and wait for the standard to emerge.