Cool Geek Toy: iRobot Roomba Vacuum

For my birthday my father got me an iRobot Roomba vacuum. This is something I would have never bought for myself but now that I have it I wonder how I ever lived without it.

This is not, strictly, speaking, an XML-related tool but it's such an interersting bit of technology that I feel compelled to talk about it. And I think it has something to teach us about tools that don't suck (in the metaphorical sense--obviously the Roomba literally sucks as it is in fact a vacuum).

First the Roomba is practical: it's a darn good vacuum (my only complaint is that it's dirt container is small so you have to empty it often). I have been responsible

The Kirby

for the vacumming in my home since I was a lad and I take it pretty seriously (even if I'm a total slacker about actually doing it). Growing up we had a Kirby with all the attachments and I loved that machine--it was so versitile and it was a good vacuum. But the Roomba has something I never had with respect to vacuuming: tenacity and focus. The thing has sensors that tell it how clean the floor is and it will not stop until it feels the floor is clean enough or its battery runs out (it supposed to last about 2 hours). It's sort of the Terminator of vacuums. By contrast, I'll vacuum thoroughly but not that thoroughly--after all I have a life.

I've only had a chance to run it once so far, but by the time I had to turn it off so I could go to bed, it had actually started to restore the knap to the high-traffic area of our worn-out berber carpet. We have two bassett hounds, so I had to empty it about every 10 minutes (because, being a slacker, it had been a while since I had last run the vacuum). But I was happy to service the little guy if it meant really getting the floors clean for once.

Second: it's clearly a very sophisticated bit of artificial intelligence. When you watch it work a room you can see that there are some sophisticated algorithms and strategies that it uses to follow walls and work around obstacles. It is also remarkably determined when it gets stuck, acting in a way that seems very lifelike. It reminded of nothing so much as a crustacian when it go stuck under the couch--it would try to back out, wiggle around, stop, move a bit side to side, then try again before I finally got it unstuck. It's clearly not just randomly roaming around.

Third: it's pretty flat so it can go under higher furniture, get into the kick space under cabinets, and so on. It's fun to watch it go under a chair, do it's thing, and emerge again.

Fourth: it has an API so you can hack it.

So what can we learn about tools from the Roomba?

First, while it's cool, it's not about being cool, its about being a good vacuum and a practical tool. It's coolness is a side effect of how it goes about being a good vacuum. I think that's important for any tool--tools that set out to be cool tend to not have much staying power. But tools that set out to do something useful in a new and better way tend to end up being cool. I've had many conversations over the years along the lines of "this would be a really cool thing to do with XML" and I don't remember any of those coming to much. Note how this is different from "this does this useful thing with XML in a cool way". Those tools tend to have staying power.

Second it's well executed--the engineering quality is very high. It has to be just to survive in the harsh environment of the typical home. To be more than a toy it has to be rugged and durable and easy to use--all the things one looks for in a production tool. The Roomba can serve as inspiration and example to those of us who create tools.

Fourth: while it does a very mundane job it serves as a platform for testing concepts and approaches that have much wider application. The same attributes that make a good vacuum also make a good battlefield robot or construction robot or whatever. The iRobot guys clearly understood that by tackling the relatively narrow task of building a useful, practical, affordable vacuum robot that they would learn lots of important things that they would need to know to do more challenging things. They also knew that a cute robot that vacuums is something everybody can understand and relate to, making it an excellent marketing tool for robots in general and their company in particular.

In XML you often have a similar marketing challenge: you have a very general, very powerful, very abstract technology with lots of potential applications but most people have a hard time seeing it in that way--they need concrete examples they can relate to. I've seen tools and created tools (and standards) that were very powerful but very abstract and it became difficult to sell them because there was no easy-to-relate-to concrete application. Again, the Roomba can serve as an example of how to do it right. The Roomba, while focused and concrete and easy to relate to, is not trivial--it's useful in its own right and so should be any demonstration or foot-in-the-door tool you create in order to market a more general or abstract technology.

At the same time the Roomba has an API that lets you change and extend its behavior. I haven't had a chance to study its API in detail but a quick review of the docs indicate that it has the features I look for in an API:

- It's complete over the features of the tool. That is, you have access to all the primitives

- It's well documented

- It's accessible through a variety of languages (their API spec has Python examples of how to use the API--yeah! [Did I mention that I'm a Python fan? Did I mention that I will dive under a train before I'll ever right another line of Perl? Does that sound like another rant waiting to happen? Can you already see where that rant would end up? Should I appologize in advance to all those well-meaning people who still think Perl is a good language? I suppose so. Is this irresponsible flame bait? Do I care?]

As an integrator, while I look for good user interfaces and solid engineering, what I really want is a solid API that is complete, well documented, well designed (consistent method names and signatures, sensible object models, etc.), and so on. At the same time it should not be bigger than it needs to be. Also, poor APIs tend to reflect generally poor engineering quality and visa versa--a good API is usually evidence of overall good engineering (although this is not always true--sometimes a good API is just lipstick on a pig, hiding bad code underneath it).

So as tool creators and integrators we can take the Roomba as an inspiration and example of how to do it right. Among the XML tools you use are there any Roombas? Are there any "man this is so not a Roomba"s?

As tool users and evaluators we can take the Roomba as an exemplar of what to look for in a good tool: has a clear purpose, performs it well, is durable and reliable, has a good user interface, has a good API, is extensible, is appropriately priced (provides good value), and is a joy to use (for a certain value of joy).

Dr. Macro says check out the Roomba.