Jon Howell from MSR came to visit yesterday and we got into an interesting discussion about the risk versus reward tradeoff for different approaches to research. Two of my Ph.D. students (Bor-rong Chen and Konrad Lorincz) are graduating this year -- you should hire them, of course -- but they are facing a weak job market and the need to rack up publications is as important as ever. The question is, had we worked on problems in the more traditional systems space, would we have been more successful cranking out the papers?
It has long been my belief that doing research in wireless sensor networks -- especially the applied and experimental variety, where you actually have to build something that works -- involves a (nontrivial) degree of difficulty that is not present in "traditional" systems research. Think of it: Programming motes requires that everything fit into 10KB of RAM. You don't get malloc, threads, or printf. All you get are three LEDs to tell you what's going on. Half the time a mote you have on your desk doesn't program correctly, or is simply fried, requiring that you go hunt around for another one. Scaling up to a full network requires debugging complex interactions between all of these motes, and keep in mind you typically don't get to inspect what each one is doing -- and comunication and node failures are rampant.
And God forbid you try to run anything in a real field setting (like a redwood forest, or even a volcano) -- then it really, REALLY has to work. As David Culler says, in a field deployment you can't just throw away the data you don't like and rerun it. You have to take what you get. More often than not the network doesn't work as you expect, or seemingly trivial problems (like water getting into the cases) causes nodes to fail.
It's been a while since I focused on conventional distributed systems, nodes running UNIX, connected to the Internet, that kind of thing. But it seems that it is considerably easier in that environment to build up something complex and debug it to the point where it works. After all you can ssh into the nodes, dump everything to a log, use tried-and-true methods and tools like gdb and strace. Of course, there's still plenty of heavy lifting involved. Hakim Weatherspoon's work on getting the OceanStore prototype to run on 400+ PlanetLab nodes for several months is no mean feat. But if I took away his ssh connections and replaced them with 3 LEDs, I wonder what he'd do. (Of course, Hakim would have still rocked it. But that's Hakim.)
This is not to diminish the intellectual contribution of mainstream systems research at all. Indeed, one could argue that the lower barrier to entry has made it possible for those working on conventional systems to innovate more rapidly and produce deeper insights than those of us battling broken motes and crappy radios. So, I wonder what advice I should be giving new grad students wading into the field. A lot of the low hanging fruit in sensor nets has been taken. To make a substantial contribution in the area you need to take things in a different direction than those before you. Fortunately, the TinyOS community has been doing a much better job lately at providing standard libraries and protocols to lower the bar. But there's still a lot of pain involved in getting to the research frontier. (Another post, I'll muse on why so many people work on MAC protocols. I suspect it's because it requires a lot less reliance on other people's code.)
My group has been doing more work with the iMote2 platform lately, precisely because I think it provides an easier-to-use, more functional vehicle for driving research. Mostly this is because it has a good enough CPU and enough memory to push on some interesting ideas without having to wring your hands over every byte of RAM your code uses. But going forward, I wonder if some of the "gap" that people see in the sensor nets space isn't merely due to the blood, sweat, and tears that goes into getting anything complicated to really work. We should think about how to remove some of those obstacles to innvoation, not to mention publication.
I've posted a story to Medium on what it's been like to work at a startup, after years at Google. Check it out here.
The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in ...
My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go . I say "almost" because ...
I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds l...