One thing we have discussed a bit in my graduate seminar this term is the tension between complexity and simplicity in system designs. As a simple illustrative example, consider B-MAC versus Z-MAC, two MAC protocols for WSNs with very different underlying design philosophies. B-MAC (the B stands for "Berkeley") is a simple, almost minimalist approach to MAC design: a couple of simple primitives (low power listening and ACKs) with a lean API permitting a layer on top to tune the LPL check interval and to turn ACKs on and off. That's it. The paper argues that with this basic set of mechsnisms you can build a wide range of policies on top, including more sophisticated protocols using RTS/CTS or TDMA. Of course, that is largely left to the reader.
Z-MAC, on the other hand, takes quite the opposite approach. It is a hybrid between CSMA and TDMA, includes mechanisms for two-hop neighbor discovery, slot assignment, time synchronization, and adaptivity to low- and high-contention modes using an epidemic ECN protocol. None of these mechanisms are exposed or tunable by the layers above; none of them can be disabled in different situations. Z-MAC is like a rich, sumptuous meal at a two-Michelin-star restaurant (I'll reserve the three stars for later work); whereas B-MAC is like the menu at In-n-Out: "Hamburger. Cheeseburger. Double Double."
Personally, I tend to recoil at designs that pack in so much complexity, especially for something so fundamental as a MAC protocol. (If for no better reason than code footprint -- with Z-MAC, how much memory is left over for the application, anyway?) This leads me to what I like to call the Berkeley Systems Model: a certain approach to doing systems research that strives for elegance and austerity above all. I'm sure it's not unique to Berkeley -- perhaps I should just call it the Harvard Systems Model -- but it seems to be best characterized by work such as Patterson's RISC and RAID, and Culler's Active Messages (by which I mean the original work, not the TinyOS manifestation of the same idea). Compare Active Messages to its main competitor at the time -- distributed shared memory -- and you'll understand immediately what the B.S.M. is all about. The B.S.M. is found in many other places (not all of which are populated with Berkeley alums); and arguably one could claim it actually originated at MIT or UCLA, but let's not split hairs.
Having thought a fair bit about this, I think there are two factors at work in shaping the B.S.M. mindset. The first, frankly, is simply a distaste (or perhaps a fear?) of complexity, irresepective of the merits of whatever system embodies it. Culler is well known for pushing back on work that has too many knobs, bells, or whistles -- he engrains in his students a deep appreciation for minimalism. If you compare some of the earliest systems work in sensor nets -- the TinyOS model and its own version of Active Messages with, say, directed diffusion -- it is immediately evident that the whole idea of combining naming, routing, querying, aggregation, and MAC into a single layer is just not written in the Tao of Culler.
But the deeper, and more important (I think) motivation is the desire to obtain clarity in terms of the fundamental underpinnings for a given system design. Much of the B.S.M. is about stripping away the layers, pulling a system apart into its many constituent pieces, reasoning about how they fit together, which ones belong, and which ones don't. To take another Berkeley example, Eric Brewer is fairly adept at this incisive mode of thinking; you can talk to him for 10 minutes about a system he's never heard of and he'll make an observation that forces you to rethink your whole design. So, I think of the B.S.M. as, essentially, about mediating on a system design, focusing on a mantra while opening one's mind to the whole.
All of that said, there are some real merits to the "kitchen sink" approach. The main one being that a heck of a lot of intellectual satisfaction can be derived from reading such a paper. While a paper from the B.S.M. school has a clean, sharp edge and leaves little aftertaste, something like Z-MAC really gives you something to sink your teeth into. There is so much going on in that paper: an intricate object with innumerable facets and hooks to explore. Of course, there are risks on both sides. A B.S.M. paper might feel vacuous, or fluffed-up, if the One Good Idea is just not profound enough. A kitchen sink paper tends to have a lot of territory to defend, especially in the initial reviewing round when PC members are looking for whatever chinks in the armor to shoot the thing down.
Also, it is clear one can take either approach to research and be successful; within a single community or conference there are plenty of examples of both types of work. It would not surprise me to learn that one's school of thought largely shapes how one approaches these papers, on PC meetings for example. This debate does not usually rise to the surface of the discussions we have in PC meetings themselves, but I think it underlies much of the dissonance between scores that some papers receive, touching a nerve in one camp while mollifying another. In co-chairing Sensys 2009 I'll be interested to see how this plays itself out.
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...