Summary
No one likes to change. But if we continue to solve the same problems (in slightly different contexts) we will be replaces by others who view the problem differently. Or at least that will happen in the area of ubiquitous computing.

I'm spending my day in the dark insides of a big silver bird, at an altitude and speed which are not natural for someone who is a member of Aristotle's feather-less biped class. I'm in cramped quarters, finding that the airline now wants money for the marginally more spacious seats they used to give out for free to those of us who spend too much time in this position. I've dined on a soggy sandwich that I brought on board to avoid paying even more for a soggy sandwich that the airline brought on board. The person in front of me has fully reclined her seat, and is now strengthening her six-pack abs by doing a continuous crunch that puts her into an upright position.

All of which, for some reason, has gotten me thinking about ubiquitous computing. I guess it is either that, or chew my leg off trying to escape.

We in the computing industry think that we have invented ubiquitous computing, and to some extent I guess we have. But given our background, we tend to have a somewhat strange view of the field. We often think of it in terms of user interfaces, or of how we can get content delivery on our mobile phone, or how we can use mobile computing devices to do, on the run, what we now do with our desktops when we are stationary.

All of that is fine and good, but we tend to ignore some other uses of computation that have been embedded in the real world for some time. There all all sorts of simple computing devices used to control the heating and ventilation in most commercial buildings. There are lots of sensors on all kinds of moving things (like this plane that I'm trapped in). There are systems for getting telemetry data from sensors on space vehicles. In point of fact, there are few places where computing is more ubiquitous than those places bearing the NASA logo.

But those of us who do ubiquitous computing tend to ignore these other groups, labeling them industrial automation or telemetry rather than ubiquitous computing. They tend to have computers that only talk to other computers, with a fairly long set of filters before a human gets involved, if one gets involved at all. They program in real-time languages on real-time operating systems. They worry about things we've decided we don't need to worry about (like very high reliability, and failure characteristics, and determinacy). The work they do is really different from the work we do, and we don't understand it, so we do the kinds of things that we are good at, and that we understand (which generally looks like n-tier computing with a human looking at some kind of screen at one end and a database of some form at the other end). And we call that ubiquitous computing.

I think we may be missing out on a lot of expertise and a lot of interesting problems and techniques. If the best user interface is no interface at all, then a lot of the industrial automation systems have pretty good user interfaces. Telemetry systems deal with large amounts of information in ways that let that information be used to make things that are more reliable, more predictable, and more useful without requiring the intervention of the users of the things that are generating the telemetry data.

Every time I read a ubiquitous computing paper about delivering ads for local restaurants to my car as I drive by, or systems that will tell me (and everyone else using the system) where the best parking place is (can you imagine the carnage this would cause in Boston?), I have to admit that I'm not at all sure that I'm seeing the future of computing. I'd much prefer sending a bunch of data to my car manufacturer so that I could be emailed about a problem before the problem happened. I don't want to see all the information, but I'd love it if some computer in Detroit was analyzing the information, looking for anomalies.

Of course, this would require that we think about new and different problems, rather than clothing our old problems in new devices. It is harder, and riskier, and takes us into areas where it isn't clear that there are journals for publishing (for the academics) or a business case (for those in industry). Maybe those doing industrial automation or telemetry will come in and make all of our work irrelevant, showing everyone who spends money on this sort of thing what ubiquitous computing could be.

Which is just the sort of thing that is happening to the airline companies like the one that I'm currently using. They haven't really changed the way they do business for a long time, so the really cheap carriers are undercutting them, and the luxury carriers are siphoning off the specialized runs that are less price sensitive. The ones who can't change make some minor alterations that only irritate their clients, find themselves bankrupt, and try to keep flying anyway. If you don't change, you may find that you are no longer able to survive.

But, of course, that won't/couldn't/isn't going to happen to us....

Talk Back!

Have an opinion? Be the first to post a comment about this weblog entry.

RSS Feed

If you'd like to be notified whenever Jim Waldo adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Jim Waldo is a Distinguished Engineer with Sun Microsystems, where he is the lead architect for Jini, a distributed programming system based on Java. Prior to Jini, Jim worked in JavaSoft and Sun Microsystems Laboratories, where he did research in the areas of object-oriented programming and systems, distributed computing, and user environments. Before joining Sun, Jim spent eight years at Apollo Computer and Hewlett Packard working in the areas of distributed object systems, user interfaces, class libraries, text and internationalization. While at HP, he led the design and development of the first Object Request Broker, and was instrumental in getting that technology incorporated into the first OMG CORBA specification.