Read Part twoLet's start from where you are now, what are you currently working on at Sun?
Well, a single developer doesn't scale very well. Java was actually developed by a single developer, originally. It was just me working alone, like the first four years of Java's life. And then popularity happened and the demands got that crazy. It also didn't help that at about that time I developed really severe carpal tunnel syndrome and I spent three or four years being almost completely unable to type. But there's been this real spread of use of it and an in-pouring of talent. The number of really smart people who have put a lot of energy into Java is just enormous. It's just amazing the spread of things that you can do with it. So, do you feel more comfortable with the Java community process than when you were sort of the sole Java programmer in the world?
It's sort of a bit of this and that. There's no way that I could have done all of this alone. There's just too much really cool stuff in the Java world. It's certainly the case that when one person works on it alone you can make sweeping changes and deeply impactful decisions in 10 minutes. But when you've got a lot of users, you don't get to do a lot of that anyway. You have to be extremely careful. I mean, you can screw them all over making huge changes, but once you have a user base you have to be really respectful of them and that makes life difficult. Plus, I'm certainly not the smartest person in the world and there are a lot of domains where I am not a world expert. There are one or two areas where I actually kind of know what I'm doing, but I think there is tremendous value in being able to tap other people and to get other people involved. For me, that's a lot about what's really cool about the open source movement. It's not the licenses or the source code, it's the social experience. Do you sense any danger with so many inputs and so many decision makers, that you design a horse, but the committee comes up with a camel?
Well, the fear isn't so much that they come up with a camel instead of a horse, but that they come up with something like Frankenstein's monster that's stitched together out of a wide variety things that have nothing to do with each other. And that is a constant fear. One of the interesting things about technology these days is that it really needs to expand a huge spread of domains. So we put a lot of energy into organizing the domains to keep them from sort of polluting each other, so that things are reasonably well packaged. This is one of the areas where the object-oriented technology really shines. The fact that there are packages and classes and such that allow us to organize things so that the bits that have to do with Web services are independent from the bits that have to do with say, driving cash registers. These things end up needing to talk with each other because everything everybody is building is so integrated. It's quite a balancing act. Speaking of open source, how do you feel about the way Sun's going about open-sourcing all of Java?
Well, I'm really happy with it. I'm happy we're finally getting around to it. It's been a long argument and there are still a big pile of big issues to get around. But we're committed to making this happen as soon as we can. Did you start working on Java in what we would call a pre-Web world, when it would still mostly be networks inside of a building?
Yes and no. Certainly, Java got started before the Web existed. But everything that we did was around Internet technology. Everything in Java is deeply, deeply affected by networking technologies and the Internet. You made the comment about networks being inside buildings. At the time we were building Java that had been solved for decades. The Internet spanned the planet 30 years ago. Of course, 30 years ago it was called the ARPANET. But the transition was mostly one of protocol. All of the stuff that went into Java was about networking. What people tend to refer to as the Web has sort of emerged when Tim Berners-Lee came up with the HTTP protocol and the HTML file format and the first Web-browsers happened. That got started shortly after Java got started and so the Web technologies were happening as Java was getting finalized, as we got towards the first releases of Java. So, all the Web stuff was already there. Did you originally envision what Web services has now become in the application development world?
I wouldn't say that I envisioned it in the sense that I woke up one day and had this vision of Web services everywhere. It's more that I assumed it. Because the structure of the network as a collection of services that all work together was this big architectural concept 20-30 years ago. And that's really all the Internet ever really was, is a collection of services that talk to each other. Which protocol they use, whether they use XML over HTTP or CORBA or God knows what doesn't matter. That's kind of how you spell the words, the context has been a piece of bedrock philosophy for a very, very long time. There's all this complexity in the languages used for SOA and Web services applications, will it ever be possible to simplify it or will it continue to grow in complexity?
Complexity is a really hard topic. Because… there's this game if you go to the Santa Cruz beach boardwalk called Whack-a-Mole. Whack a mole, like the animal. And the way Whack-a-Mole works is there's a board and there's this three-by-three grid and a little mole sticks its head up and you're standing there and you've got a baseball bat and you're supposed to whack the mole before he goes back down into his hole. Then he'll pop up somewhere else and you've got to whack him down. A lot of engineering and in particular the engineering around complexity is like Whack-a-Mole. You can make things like programming languages incredibly simple but then what tends to happen is complexity emerges somewhere else because people are trying to get around the stuff that's missing in the language or in APIs or whatever.
A lot of the complexity that we have is sort of driven by a sort of inevitable consequence of the activities that people are trying to support. If you think about just a cell phone or a Web page, what does it take to pick up a phone, place a call from standing on top of the Great Wall of China where the other person you're talking to is on a bus going from Monterey to Salinas? And managing that while the bus is in flight. Oh, and by the way, the piece of the Great Wall you're on is a long way from Beijing. I actually did that. I was talking to my daughter going to a track meet and I was on a business trip and if you think about all of the stuff that has to go on to do that, a lot of that complexity is pretty much inescapable.
Lots of folks come up with solutions to make life simpler but really all that they've done is move the complexity somewhere else. What's really, really hard is not making any particular technology simpler or making a particular API simpler, but standing back from complete systems and making the whole system simpler. And you don't get away with making one piece simpler and then realizing that this caused emerging complexity in other places. Yeah, we can live a whole lot simpler by going back and being an agrarian society. I don't think anybody wants that.Do you think it's the job of architects to look at the entire system and see what if any simplifications can be done?
That is certainly what architects ought to be doing. It's a really difficult thing because you find people who are in companies and their title says they're an architect. But they are often so divorced from the actual detail that they make architectural decisions that make absolutely no sense. Because when you dig down a few layers to see how that decision would have to be realized it's just totally out of step with technology. It's a really hard challenge in architecture to have both deep knowledge to make credible architectural decisions and broad knowledge to be able to span all the different technological areas. And trying to do large system architecture is unbelievably difficult. Do you think architects need to be knowledgeable at the bits and bytes level and the overall business processes level?
Yeah, and you try really hard to construct systems so that you don't have to know the low level details. But the saying goes, that's where the devil is.