Wednesday 9 June 2010
Sleepless In Toronto
For some reason I often don't sleep very well on trips these days. So despite having had exhausting days and only about five hours sleep a night, I find myself awake in my hotel room at 5am reflecting on the last few days. Quite possibly I'm awake because the sheer excitement of this trip has my head buzzing. Maybe the good food, lack of exercise, and almost complete confinement to the hotel has thrown me off. I also suspect that over the years I'm becoming more dependent on home, my wife and children --- that's a good thing. Anyway, this has been a good time to take a mental break, to reflect, pray, recenter myself on God and update my blog :-).
It's been amazing to attend PLDI and the workshops after not having been to a major conference for five years. Even after five years away, I still feel like I fit right into this research community. I know a surprising large fraction of these people --- ex-colleagues and friends one or two degrees removed --- and more surprisingly, I remember most of them; normally my memory of faces and names is extremely poor. I've even found people I haven't met before who know who I am; that's gratifying, since I've been off the radar for so long and was never prolific.
Research trajectories have continued as one might have expected. Interest in parallelism has increased sharply, for obvious reasons. Interest in Web browsers and Javascript has increased even more sharply, since there was none among PLDI researchers five years ago. This is great; it gives me something to contribute to conversations in lieu of research results :-).
I am surprised to find that interest in parallelism has kept work on dynamic data race detection very active --- I thought that DRD work was being mined out in my day :-). There's not as much good evaluation on real systems as I'd like to see, though. I've also been sharing my anecdotal experiences with thread programming at Mozilla, which boil down to the observation that races and deadlocks are not actually a huge problem in themselves, since we try hard to minimize sharing between threads and keep communication patterns simple. The way threads hurt us is by adding nondeterminism, which can make reproducing even simple bugs much more difficult.
I think my LFX talk went pretty well. A few people told me it made them take notes and think, which is a good sign. I managed to get my slides online in spite of the hotel network being awful, at least in my room. The talk is basically a summary of what we do in Mozilla development, followed by requests for research in specific problem areas. One key idea I pushed is that the right place to introduce analysis results into the development process is probably during code review --- in other words, we should apply static and dynamic analysis tools to assist code review of specific changes, rather than in the traditional mode of analyzing large bodies of code to try to find important bugs. In general, finding bugs in code we've already shipped is less interesting, because either we've already found the bug, or the fact we haven't found the bug is evidence it's not important. Interestingly, Bill Pugh --- who has been pushing static bugfinding at Google for a few years now --- has independently come to similar conclusions.
I've also been advocating researchers work more on improving the process of fixing bugs, rather than just finding bugs, since it's bug fixing that is probably our true bottleneck for improving code quality. There's some sympathy, but it will take a while for that ship to turn.
Before I came here I wondered whether PLDI would give me an urge to get back into research. I certainly miss the people, the work and the environment, and it would be incredibly fun to get into research again, but so far nothing has challenged my view that my work at Mozilla is far more important than the impact I would have in research. The parable of the talents applies. It sure would be nice to figure out a way to push out a PLDI paper once in a while, though :-).
Comments
--
"One key idea I pushed is that the right place to introduce analysis results into the development process is probably during code review ..."
--
and
--
"...work more on improving the process of fixing bugs, rather than just finding bugs, ..."
--
so you must have some example of failures or quality problems related the bug fix patches in mind. Or maybe your point of view is related to working on a very mature code base? I guess that in these cases, bug fix patches have a higher-than-expected probability to be bugs themselves. The system is very complex and yet it has a lower than normal amount of buggy code. So errors in bug fixes are easier to create and stand out from the crowd more than might be true in a younger project?
jjb
I downloaded the slides in the hope I'd get some fresh insights, but they are too outliney for me to get much out of them.
Do you know if there is there video online of the talk anywhere? Are you planning to give a version back in Auckland sometime (umm ... because it's a good time to start trawling for prospective hires from the University)?
I'd be more than happy to visit the university, but someone has to invite me :-).