Last week I defended and filed my Ph.D. dissertation. Rather than letting the acknowledgments page languish in a library somewhere, I thought I would post a nicely-hyperlinked version here. There are probably many people that I missed (I have already thought of a few after the document went in for binding), but here’s to those I didn’t:

This all started in the summer of 2003. A freshly-minted Harvard College graduate without any better plans, I replied to a forwarded email from a new Harvard Computer Science Professor who was looking for research assistants. That was Matt Welsh. Matt saw something in me that I didn’t yet see in myself, and stuck with me through the years, through my stubbornness, intransigence, bad habits, and willful disobedience. Along the way I’ve thought about leaving for law school, or get-rich-quick schemes like Facebook, but I’m glad I’m going to keep building and studying real systems, since that’s been more and more fun as we’ve continued working together. I know I’ll think about Matt a lot as I start my own group, and I can only hope to do as well as he has.

Margo Seltzer deserves credit for helping me discover the thing that I’m perhaps starting to get good at. Taking Operating Systems from her in 2001 is the highlight of my college experience, turning me in the direction I continue to travel. She, Matt, and Michael Mitzenmacher all provided valuable commentary on this dissertation, and improved it.

Building volcano monitoring sensor networks requires people who know something about volcanos, and this project really came about because we met two great ones: Jonathan Lees and Jeff Johnson. They offered us a huge amount of support in the field, patiently answered many questions, and really embraced the technology we offered. I am extremely thankful for them, as well as the wonderful staff at the IGEPN in Ecuador, and the Ecuadoreans we’ve had the chance to work with — Mario Ruiz and Omar Marcillo.

I have had the pleasure of spending a lot of time with Harvard undergraduates over the past seven years, through my affiliations with CS161 and Eliot House. I am thankful for all of my former students, especially those that came to work with us: Pat Swieskowski and Stephen Dawson-Haggerty. And without the community at Eliot House I probably never would have completed this degree. I thank Lino Pertile and Mike Canfield for giving me a chance to be a tutor, and all my former Eliot students and friends for their love and support. Floreat Domus de Eliot!

None of the projects described in these pages was done alone, and I have been blessed with fun, intelligent, and forgiving colleagues at Harvard. Thaddeus Fulford-Jones designed our volcano sensor board, experienced the joy of sharing an office with me and has become a good friend. Konrad Lorincz joined our deployment team in 2005 and did a huge portion of our volcano monitoring system. Jason Waterman has been a joy to work with and contributed greatly to the IDEA project. Rohan Murty tolerated my many attempts to annoy him before I discovered what a special person he is. Mark Hempstead has always been willing to offer an electrical engineer’s biased take on things. Bor-rong Chen and Geoff Mainland have been supportive of my work, offering a great deal of constructive criticism. Lex Stein was always available to offer advice, most of it helpful, the rest amusing. People like Joanne Bourgeois, Gioia Sweetland, Tristen Hubbard, Susan Wieczorek, James MacArthur, Lars Kellogg-Stedman and William Walker make it a pleasure to work at the School of Engineering and Applied Science. Additionally, I thank all of the members of the SYRAH and Welsh groups not mentioned by name, travelers on the Maxwell-Dworkin Spaceship, and the interns in MSR 112/3001 that kept me sane in the summer of 2007.

I couldn’t ask for better parents. They started me on this journey of discovery years and years ago, and look how far we’ve come! My mother also provided helpful feedback on the amount of time that my Ph.D. was taking, and I think she’ll be pleased that I’m receiving a degree… at last. My brother Jonathan and sister Amy will no doubt be receiving their own doctorates very soon, and I look forward to celebrating with them when they do.

My wife Suzanna is my favorite person and the reason I get up joyfully in the morning. I can’t wait to see what life holds for us, together: all the days, all the ways.

And to Chuchu — WOOF!

Sensys’09 Program

As Matt has announced, the Sensys 2009 preliminary program has been released. I’m proud to say that it includes a contribution from our group on Mercury, a wearable sensor network for high-fidelity motion analysis. This is largely Konrad’s work (in fact, his thesis work), but I was peripherally involved and the Mercury download manager architecture borrows heavily from Lance. It’s a solid engineering effort and I’m pleased that it was accepted &mdash particularly as its good exposure for both Konrad and Bor-rong, both of whom are graduating next month.

I am disappointed, however, that our Draft paper didn’t make the cut. I blogged recently about the paper submission and my feelings about it pre-decision. After the decision came down I think I went through the usual post-rejection phases: anger, depression, careful consideration[1. Facilitated by reviews.], acceptance, imagination, reinvigoration. While the reviews weren’t quite as helpful as I would have liked, Jason and I are up and spinning together an NSDI’10 submission and are exploring some exciting new directions for the work. Given that this is the last piece of real research I imagine I’m going to get a chance to do before pulling together my thesis this winter and then (hopefully) interviewing next spring, I plan on enjoying one more trip out. As Suzanna put it, despite the inevitable feelings of failure that accompany a paper rejection, I had wanted to write an NSDI’10 paper, and that would have actually been quite hard had I had to spend August tightening up a Sensys’09 submission. That said, I would have loved to be able to get up at a fall conference and give a talk, particularly with the job market looming, but I guess I’ll have to hope people remember best talk award at Sensys’08.

Personal mutterings aside, this post was supposed to be a preliminary look at the Sensys’09 program, particularly in light of the comments Matt has made about the process on his blog. At first glance, most of the papers seem to break down into some well-defined categories[2. Note that I'm breaking these down by their titles, which can be misleading.]:

  • No MAC Papers (!): perhaps this is a function of Matt and Jie as program chairs, or maybe the community is finally just really tired of the (IMO) largely useless proliferation of MAC protocols, almost all of which were never compared against other research MAC protocols or ever canonicized in the standard TinyOS distribution. I remember during a question Matt asked at either Sensys’08 or Sensys’06 he argued that really what we needed was a MAC sMACdown, i.e. a paper that would actually compare a number of contributed MAC protocols using a consistent set of experiments, methodologies and benchmarks. Don’t see that paper, but it seems like the MAC sMACdown just ended up taking a slightly different form this year. No complaints here.
  • Multiple Link/Routing Protocol Papers: maybe these are what replaces MAC protocol papers for the next few years. Just based on the titles I see “ADB: An Efficient Multihop Broadcast Protocol based on Asynchronous Duty-Cycling in Wireless Sensor Networks”, “Collection Tree Protocol”, “M&M: Multilevel Markov Model for Wireless Link Simulation in Sensor Networks”, “Explicit and precise rate control for wireless sensor networks” and “Bursty Traffic over Bursty Links”; “The Case For A Network Protocol Isolation Layer” may be making an architectural contribution or may fall into this category. So it seems like we have at least one dedicated routing session, with a number of papers focusing on link-level dynamics and/or simulation.
  • Time Synchronization: several years after the FTSP and Firefly Sensys papers — which I mention here due to my familiarity, not due to any seminality — another batch of papers addressing time synchronization are here. “Optimal Clock Synchronization in Networks”, “Low-power clock synchronization using electromagnetic energy radiating from AC power lines”, and “A Tale of Two Synchronizing Clocks” look like they compromise a dedicated time synchronization session.
  • Applications: Sensys has a strong history of application papers, and this year is no exception, with “Canopy Closure Estimates with GreenOrbs: Long-Term Large-Scale Sensing in the Forest”, “DCNet: A High-Fidelity Data Center Sensing Network”, “Suelo: Human-assisted Sensing for Exploratory Soil Monitoring Studies”, “Mercury: A Wearable Sensor Network Platform for High-Fidelity Motion Analysis”, “Experiences with A High-Fidelity Wireless Building Energy Auditing Network” and “VTrack: Accurate, Energy-Aware Traffic Delay Estimation Using Mobile Phones” all seeming to present application case studies or present experiences deploying real systems. I probably have a more mixed view of application papers than my CV would suggest. Some I find extremely interesting and edifying. Others seem to have impressed reviewers with a complete, well-engineering system, but really don’t contribute many or any new ideas. That said, based on the titles alone I see a number of projects represented here that I’ve known about and am excited to hear and read more about.
  • Programming/Debugging: this category includes “FIND: Faulty Node Detection for Wireless Sensor Networks”, “TOSThreads: Safe and Non-Invasive Preemption in TinyOS”, “Darjeeling, A Feature-Rich VM for the Resource Poor”, “Macrodebugging: Providing Abstract Views of System State”, and “Evaluating A BASIC Approach To Sensor Network Node Programming”.

Interesting that only one paper — “Achieving Range-Free Localization Beyond Connectivity” — out of the 21 accepted escapes this categorization. I haven’t tried a similar title-based categorization for other preliminary programs at other conferences, but part of me wonders if this is a function of the topically-based decision making process that Matt seems to imply went on at the PC meeting. I don’t have enough experience with program committees to know whether or not this is standard operating procedure, but I wonder how you combat the danger of category-driven selection, namely that you don’t get the strongest 21 papers but rather the strongest three routing protocol papers, the strongest three programming/debugging papers, the strongest six application case studies, and so on. The other danger of early categorization is that papers that span multiple areas or don’t fit cleanly into boxes end up being left out.

Specifically, I’m disappointed this year to see a program bereft of architectural approaches to reducing power consumption. I’m willing to presume that some of the programming papers may address this more directly, but one of the more exciting things (for me) about the past few years of Sensys was the emergence of papers like Levels (Sensys’07), Eon (Sensys’07), Pixie (Sensys’08) and of course Lance[3. This list is obviously too tilted towards our own work at Harvard, and plenty of other good papers in this area exist.] which took large-scale, top-down approaches to controlling network-wide power consumption. (Or were getting there, slowly.) I’m hoping that as I learn more about the papers that were accepted a broader focus on energy will emerge from papers where it is not evident in the title, but as of now I’m disappointed that this area seems poorly represented.

Community Service

On the train back from HotOS’09 Prabal Dutta and I entered into a discussion about “service to the community.” Of all the people I’ve met in the wireless sensor network community Prabal is one of the more interesting and thoughtful. I’ve always enjoyed discussing research and other things with him, and this was one of those conversations that stuck in my mind.

I think that we entered into this topic when I remarked that the research homepage of someone I had Googled listed serving on program committees under the heading “Service.” Growing up as a Boy Scout[1. Topping out as an Eagle Scout, in fact.], and having to accrue the service chits to apply to a selective east coast college, defining service on a program committee as “service” seemed a bit of a stretch to me. This is something that seems fairly clearly in the best interest of faculty members[2. And yes, by this definition some of the "service" on my college application wasn't really service either.] involved, and I’m guessing is also properly incentivized by tenure committees when the time comes.

So if program committee participation isn’t service to the community, what is? And if researchers don’t do it, is it important?

My definition of service to the (research) community would be activities or actions performed that both a) benefit other researchers directly and b) are not directly compensated or undertaken with no clear expectation of eventual reward. Of the top of my head, I can come up with a few[3. Not as many as I would like to be able to bring to mind quickly...] examples in the WSN community:

  • FTSP @ Vanderbilt: After the original FTSP Sensys’04 paper, the researchers at ISIS along with (I believe) others came through in a big way by closing the loop. FTSP is now part of the standard TinyOS 2.x distribution, and receives all of the testing attention and hardening one would expect of something canonicized in this way.
    Did the FTSP team have to do this? No, of course not. They had already had their paper published! Usually the next step is to drop the code on the floor, or dump it into contrib where you don’t need to support it and nobody can complain about it. But they took the time to close the loop, which I applaud them for.
  • The Sensor Network Museum @ ETH: I first got wind of this a few years ago when I received (and completed) the deployment survey that Jan Beutel had distributed. The museum seems to have links to a great deal of relevant WSN material, and while I’m not sure who’s maintaining it they’re definitely doing a great service for the community[4. At some point though, I am hoping that Jan uses the survey results I sent him for something useful...].
  • MoteLab @ Harvard: I can’t finish this list, unfortunately a bit short, without tooting my own horn as well as the horns of my advisor and a lot of other people at Harvard[5. In no particular order: Bor-rong Chen, Konrad Lorincz, Geoff Mainland, Pat Swieskowski, Glenn Holloway and all the EECS support staff deserve mention. I'm sure there are others I'm forgetting.] and elsewhere[6. Kyle Jamieson (now at University College London) and Brett Hull, both at MIT CSAIL at the time, did a significant re-factoring of one of the uglier pieces of MoteLab code I had written.]. MoteLab is a wireless sensor network testbed that currently supports over 500 researchers from around the globe[7. A few days ago I got a very nice email from Muhammad Hamad Alizai in the Distributed Systems Group at RWTH Aachen University (which I had never heard of). Their Sensys'09 paper used MoteLab extensively and he was writing to say thanks.].

I’m sure there are many additional examples — and I hope a few people will enlighten me through comments or email — but in general these sort of contributions seem a bit problematic. Speaking for myself, my own work on MoteLab started before I began the Ph.D. program, during the year I worked as a research assistant for Matt. This meant I had fewer ambitions in terms of paper submissions, and less of a research agenda (to the degree that any first- or second-year student typically has much of a coherent research agenda).

As time has passed I’ve had to moderate periodic urges to improve the MoteLab codebase against the realities against which those efforts will be measured. We had our one MoteLab paper in the SPOTS track of IPSN’05. It’s extremely unlikely we’d be able to publish anything else on MoteLab. And yet, improving the testbed — either increasing the stability, improving job scheduling and workflow, or creating a more interesting heterogeneous environment — would greatly benefit a lot of other researchers who make use of it. Just not me so much.

A great part of me hates to have to make that calculation, but those are the realities. The optimist in me wants to believe that these sort of contributions and community spirit are measured and weighed on the academic job market I’ll be venturing into next year. The cynic is less sure. My conversation with Prabal? Ammunition for the latter. When I asked him whether, during his job interview process, anyone had ever asked him “Tell me about a contribution you have made to the community that I wouldn’t know about from examining your CV, something that has benefited a great deal of other researchers and facilitated their work?” his answer: no.

Forward References

One of the many interesting things about IJ, at least to me, was its use of forward references in the endnotes. E.g., endnote #45, which reads “See Note 304 sub.” Actually I think there are a few like this. When I came across endnote #45 I actually didn’t skip forward to the forward-referenced note, since I thought, wait, 304 > 45, so WTF? Is this a trick? Why not just reverse the ordering and make 45 the long essay on Québécois separatism? It wasn’t until I read this note on Infinite Zombies which references that essay that I thought it was OK to go ahead and move forward and read it. Which I did.

Taking that as loose inspiration I want to toss in a few forward references of my own, since I find that my ability to come up with good subjects for blog posts outpaces my ability to write them. So here are things that I have been mulling about and hope will come out in these pages soon:

  • I’d like to do a series of posts based on a long conversation I had with Christoph Freytag while he was visiting us at SEAS. It was several days after I had presented some ongoing work at our weekly group meeting and we had a great, wide-ranging chat that touched on a large number of things: life, research, mentoring, etc. The parts I’d like to cover here — assuming I can get his permission to do so — were a series of observation he made of the sensor network field at large as a sage, external reviewer. I’ll get in touch with him and see what he thinks about me stealing some of his thunder here.
  • After HotOS’09 I’ve had a few posts bouncing around, including one on anonymity in reviewing[1. Which was re-invigorated by a strange path of link-clinking which lead me, IIRC, from something about IJ to this post on Planned Obsolescence, which deals with anonymous reviewing and quotes this piece from Anyway, these thoughts lined up very well with my own and this post is actually already in the draft stage.], another on the aesthetics of computer systems design, and a third — already covered here — on an idea to increase the sustainability of computer science conferences.
  • Along those lines, I have another idea on improving the related work section of peer-reviewed papers, similar but not identical to the “novelty timeout” I proposed here.
  • I wanted to offer another perspective on the Vanity Fair article on Harvard that Professor Mitzenmacher[2. Clicker beware: Professor Mitzenmacher's homepage at present contains a massive unscaled image that caused my browser to lock up for ~60 seconds.] has already discussed in this post on his blog. I actually found the article and it’s tone extremely frustrating and wanted to assess it even before Professor Mitzenmacher beat me to it.
  • I have a bit of musing to do about my own approach to computer science research, motivated by the realization that I don’t enjoy writing computer code as much as colleagues and how that changes my approach to building systems. It’s also an excuse to connect with a great quote from a wonderful poem called “Top Story” by Mark Yakich[3. Who's married, in fact, to the sister of a friend of mine from college, which is how I learned of and acquired the excellent volume Unrelated Individuals Forming a Group Waiting to Cross. To confess fully, I actually (accidentally) lifted my copy from my friend's parents' home several years ago. I'm considering sending them one but I'm guessing they've acquired another already.]:
    …They say, you must not force sex
    to do the work of love or love to do
    the work of sex, but I’m not completely convinced.
    I mean, something has got to work somewhere,

    even if in reverse…

    Have I given the whole post away already? Probably not.

  • I wanted to review the movie (500) Days of Summer, which Suzanna and I saw yesterday on our six-month anniversary (!).
  • I obviously need to write the second half of this post, which really should be the next order of business, but which is frustrating and sad and head-of-the-line-blocking and preventing all the other wonderfulness above from getting done.
  • Finally, I wanted to write a Google fanboy post now that they’ve activated my Google Voice subscription. I’ve also been thinking a lot recently about and their sequestering of information, but I need to make sure I have all the details before I wade into something like this.[4. Unusual for me, I know.]

So now that I’ve forward-referenced these topics I have the incentive to follow through, to make sure that the references aren’t broken, forever dangling sadly in space, pointing at nothing…

Pinned and Needled

Today is the Sensys’09 programming committee meeting, going on just down the street in our spaceship home, Maxwell-Dworin. So fairly soon we’ll hear about the fate of two papers our group sent in, one on system called Mercury — a paper I was peripherally involved with — and another on a system called Draft, which I lead authored along with my advisor and the fantastic Jason Waterman.

The review process is always fraught with tension, particularly around decision time, but I’m finding myself struggling a bit harder that usual to wait quietly by the internets for a verdict. I think a combination of various factors has led me to feel more invested that usual. Enumeration follows the break…
Read all »

More Blogs

A few I missed earlier, all tech:

Blogs I Read

I thought about putting up a blogroll, but integrating it into my existing site seems like too much work and its not clear where it would go. This seems easier. Blogs I read on a daily basis fall into roughly two categories: politics and technology. To enumerate (in no particular order):


  • Talking Points Memo: I’ve been reading TPM for years and just can’t quit. Some of their new features annoy me1, but in general I think that Josh Marshall has an interesting take on a lot of things. Highly recommended.
  • Eschaton Blog: Another blog I’ve followed for a while but one I’m losing interest in faster than in TPM. Still plays a nice meta-blog role with links to a lot of interesting posts on blogs I don’t normally read. But a lot of the posts now are just little pieces of not-so-funny snark or pure comment threads, which I don’t bother with.
  • Glenn Greenwald @ Salon: I really enjoy Glenn’s style, his strong opinions, the sometimes bracing clarity he brings to issues. A good read.
  • Paul Krugman’s Blog: An obvious choice. Extremely insightful. Very shrill! Good stuff. Somewhat erratic posting schedule, however.


I’m still hunting around for blogs written by contemporaries, that is late-term students considering the academic market, certainly systems types. Shoot me a note if you write or read one.

  1. 1. The "Day in 100 Seconds" feature seems to reduce news from a series of soundbites to a series of mini soundbites. Is this useful? []

Old Idea Statue of Limitations

As far as ideas that came out of discussions at HotOS’09, this one I can’t really take credit for: credit goes to Colin Dixon at The University of Washington. But as far as I know he doesn’t have a blog1, so I get to blog the idea!

I remember this idea emerging out of the one of the typical conversations carried out by young CS researchers after meeting, which is animated by the irritation associated with the feeling we get at times from more senior people that “everything old is new again.” All great systems research was done in the 70s and 80s. There’s no such thing as a new technology. Every idea you have someone had before. Every system you build is just a reflection of earlier glories. And on and on. It’s pretty depressing, really, and makes you wonder why anyone would get excited about a future building systems listening to some of these voices. This sort of attitude also tends to leech away any enjoyment we (junior people, that is) get from new, to us at least, discoveries and revelations. Who cares if I’m late to the party? I’ve arrived! I made it! Let’s party!

It also seems, at least to me, that an overdeveloped concern for intersection with the past seems to emerge from a type of technological (over)determinism that’s hard to justify once bared. It’s the sort of thinking that believes that, if we are ever at point A, then we are going to be next at point B. So if you find yourself at A, why brave ahead yourself? Save yourself the trouble, cut out the middle man, join the conversation at B. This sort of thinking also seems linked to considering the act of building a system in an overly-scientific way as an experiment, rather than as a set of design decisions made in a certain (time varying) context. I can certainly imagine that sciences that seek to develop an understanding of a (at least, fairly) fixed universe, like Physics2 would frown on performing the same experiment twice. After all, it’s unlikely that the laws governing the universe have changed much sense (Newton, Bohr, Insert Favorite Famous Physicist Here) performed it (centuries, decades) ago. (If they had changed, would they be laws?)3

Of course, in Computer Science everything needs a (t) attached to it, since our world does change. We are simultaneously building and studying it. So rather than being at point A, we are at point A(t), and then we make a bunch of decisions at times t + Δ1, t + Δ2, etc., and we end up at B(t + Δtotal). So what? Well, if at some later point, say t’, we again start at A(t’), we might not end up making the same choice. We might end up somewhere else, maybe at C(t’+Δtotal). We might deploy a different set of ideas, which maybe have been around for some time, but maybe now we’re ready to take this whole journey seriously. This time.

So what can we do here? Is there a way to simultaneously accomplish two things:

  • Encourage researchers, particularly younger ones, to take the past seriously and avoid making the same mistakes over and over again.
  • Ensure that ideas aren’t excluded from the present discourse simply because they might have been explored in a similar, or different, context years ago, on the premise that some of those ideas might simply not have found their time yet?

I wasn’t sure there was, but Colin made a brilliant suggestion: a statue of limitations on old ideas.4 The idea is simple: we set a reasonable time period, say 10 years, after which ideas go “out of scope”, meaning that they are no longer fair game for dinging a new paper for repeating. Individual conferences could each set their own “novelty timeout”5, with some venues emerging out a desire to reexamine the quite recent past (low novelty timeout), and others preferring a high bar on originality (high novelty timeout).

To those that might fear that this would further reduce the burden on authors as far as understanding and citing related work, I would argue that it might have the opposite effect. With an understanding of the pertinent novelty timeout, authors will be less afraid of finding out that some guy at Xerox PARC scribbled out the outline of my SOSP’09 paper on a napkin in a bar in 1972. A novelty timeout could also be paired with a recommended reading list for each conference. Essentially, Sensys might say to submitting authors: we expect you to be familiar with work that appeared in Sensys, IPSN, DCOSS, HotEmNets, etc. for the last 5 or 10 years, as we will be and will penalize those who have missed pertinent related efforts.

A novelty timeout seems like a reasonable way of balancing competing goals: ensuring that researchers have enough time and rope to do fresh things, even if they revisit old ideas; and incentivizing proper consideration of the past.

  1. 1. Pourquoi pas, Colin? []
  2. 1. Where I started. []
  3. 2. I have a separate set of ideas brewing about Computer Science as science or art, but those will brew until another day. []
  4. 3. There's probably a snappier way of phrasing this... ideas? []
  5. 4. Another attempt at a name, maybe an iota snappier than the first? []

The Teddy Ruxbin Talk

More post-HotOS’09 thinking1, though less directly-relevant.

I would like to lay claim to coining the term “Teddy Ruxbin Talk” to describe a talk that is a) overly-rehearsed, b) extremely overly-rehearsed c) almost feels like it was acted out, rather than given or d) a mind-numbing mixture of a-c above.

I think most people who lived through the 80s at whatever age will catch the reference. Here’s Teddy Ruxpin[1. Who's back, apparently. Yay!] Teddy will talk to you, but first you have to put a tape in Teddy’s back and hit PLAY. Then Teddy will talk to you. He will say what is on the tape. With the same wording, timing, and inflection. Every time.

I dare say we’ve all given the Teddy Ruxbin talk. Sometimes this is referred to as the “elevator pitch”, when given clumsily. I myself find myself lapsing into this when presenting a poster, and beginning my spiel for about the 20th or 50th time. 2 I noticed a few Teddy Ruxpin talks among the job talks that faculty candidates gave at Harvard a few years back. I guess those are the most common places: poster presentation lends itself to repetition, and you get it from all sides as far as how important jobs talks are which probably explains their tendency to be over-, rather than under-, prepared.

Maybe people will give me a hard time for pointing out the downside of over-prepared-ness, given that many conference talks suffer from the opposite problem. And I’m not exactly sure why I’m opposed to the Teddy Ruxpin talk. It seems to run counter to the reason that it’s so thrilling to watch someone like Yo-Yo Ma perform, the utter ease and comfortability that puts you, the listener, completely at peace. Contrast this to the delicate, difficult appreciation that you experience hearing a young child play something that is clearly just a bit beyond their technical or musical grasp, the slight strain of being put into the position of rooting them on, praying just a little bit that their fingers won’t slip, that their memory won’t fail them.

But maybe over-prepared-ness shouldn’t lead to scripted-ness. Maybe it should lead to a fully natural presentation in which the requisite practice recedes into the background entirely, and you are left without a feeling of intense, deliberate, repetitive preparation, and instead just left with the ideas the speaker wanted to impart. This is probably something akin to what actors strive for, since nobody wants a chump that forgets what comes after “Romeo, Romeo, wherefore art thou Romeo?”, but nobody wants to hear the lines read to them either. It’s a tough balance to strike, but we have Teddy Ruxpin manning one edge of the abyss to let us know when we’ve gone way, way too far.

  1. 1, 2 []
  2. 2. I actually tend to fight against this to somewhat ridiculous lengths, meaning that latecomers to the poster tend to look a bit confused as they receive an extremely weird, highly-obfuscated poster pitch completely driven by a strange need to keep my cranial circuitry alive. []

A Tale of Three Talks

Continuing my commentary1 on HotOS

Like my advisor, I share a fondness for the non-non-interactive talks (i.e., hold the “hold your questions until the end”, thanks). It’s unclear whether or not people really understand the value of the back-and-forth that occurs, how to steer it, or how exciting it seems to those present. Take the opening session of HotOS’09 as an illustrative example. A tale of three talks, if you will.

Margo kicked it off with a great talk2 claiming hierarchical file systems are dead[3. Interesting to look up the Urban Dictionary definition of "hFAD": "hot from a distance." Any reflection on the work? Beats me.]. Most of the 30 minutes was spent in a rolling back-and-forth that really got things off on the right foot. To my mind, a great example of a confident researcher able and willing to roll with the punches facing, what was at that point a very punchy audience.

Colin went next, presenting a paper that claimed that middleboxes are dead. 3 Coming on the heels of Margo’s talk, Colin’s got a rise from the already fairly well-stirred room, and I think he thought that things got off the rails a bit. Completing the triple feature was Mike Walfish claiming that asynchrony, too, was awaiting reaping. (Ahh, Rushdie: “Hierarchical filesystems are dead! Middleboxes are dead! Asynchrony is dead! Aargh, they’re all alive, and they’re coming after us!”4) In contrast to the prior two talks, Professor Walfish asked us to hold our questions to the end. It was amazing how quickly the audience went limp, how fast the air rushed out of the balloon. Twenty minutes later, at the close of his talk, he couldn’t even get a rise out of the crowd with the (fairly apropos, to be fair) bad pun that closed out the deck.

Now there was probably a certain degree to which a fair amount of nervous, excited energy had been pent up and was waiting to leave the room during the first couple of talks. (Remind me to beg for an early slot at HotOS-XIII.) That said, after the excited discussions that accompanied the first two talks, slamming the door on the audience was probably not the wisest move. To me it seemed like, “OK, that was fun for a bit, but now back to normal conference mode, open laptop, begin email…” (Actually I was good about staying away from my laptop throughout. It helps to have read the papers beforehand.) Interestingly enough, while I didn’t talk to Professor Walfish afterwards I did see Colin who seemed a bit shaken up, and I got the impression he didn’t think that his talk had gone that well. Au contraire, mon amis! The talks where people opened up and let the audience participate stand out in my mind as the best. Something worth thinking about when you’re hiking back into town after being tarred and feathered by a technological lynch mob. At least that’s exciting!

For me, that sort of back-and-forth produces multiple concrete benefits (besides being pulse-raising):

  • It’s a test of character. Working with someone who is so defensive that they can’t even internalize any criticism of their work is really, really hard and rarely worth the effort (IMHO). Being on the spot in front of an audience is tough. It tends to favor those that are quick-witted, able to dismiss questioners with a joke, a bit of self-deprecation, acknowledgement, or (on the rare occasion) a succinct, intelligent answer. For the rest of us, the majority that can’t answer questions on the spot without relying on some form of pattern matching (see next), our best hope is to allow the questions to steer us without giving away too much ground (see below).
  • It shows how well you understand your own work. If you’re really thought through multiple aspects of a project you can let the questions lead you and further focus the talk. It’s hard to know what a particular audience will be curious about, or what objections they’ll have. Most slide decks take a particularly safe path through the material, doing their best to obscure, minimize, or skirt dangerous territory, i.e. limitations, drawbacks, etc. And in the typical conference format with large number of attendees and limited question time, many questions are dealt with by “pattern matching”, essentially picking the answer out of my pre-determined deck of question answers that seems to address your question. It probably doesn’t, but you won’t follow up, will you? Oh, all right, let’s take the whole thing offline!
  • It lets the audience guide the talk. Interfacing with the crown means that the vulnerable points mentioned above get noticed and commented on. This might lead you towards things you might not have wanted to talk about. It also allows the audience to feel out where your Alamos are. What intellectual or design territory will you abandon if faced with even a modest assault, and where are you really going to dig in and protect this house? Finally, it lets the audience lead you toward what interest them. This is good for them, and good for you. Even if it doesn’t feel good.

I would love to see what would happen to slide decks for HotOS-XIII if the conference organizers decide to dictate that presenters must handle questions during the talk. Maybe instead of trying to steer away from tender spots you just get right to them, let it all hang out, practice intelligent and pithy justifications, and thereby avoid becoming bogged down in sniping caused by those who see through overly-rosy claims. I don’t know. A middle-ground approach would be to hold questions for the first 5 or 10 minutes of the talk, to let people get their one point across, then let the next 10-15 be more interactive and then open up for full-on Q&A.

  1. 1 []
  2. 2. The talk was great. I'm less sure about the idea, which seemed, at least based on the comments in the room, to have been rolled multiple times before. []
  3. 4. Actually, the session would have been much funnier/more interesting had the authors had to argue about which, of the three papers, had identified the thing that was really did, maybe finishing with an audience vote. Idea for HotOS-XIII: every session ends with a vote, of some kind. []
  4. 5. From "The Ground Beneath Her Feet". []