Sunday, October 28, 2012

Call for tutorial proposals for ICSE 2013

Call for tutorial proposals for ICSE 2013
San Francisco, CA, May 2013

ICSE is soliciting high-quality tutorial ideas that will attract both practitioners and researchers.  Proposals are due on November 2, 2012.

ICSE Tutorials present the state of the art or the state of the practice in a topic related to software engineering. A tutorial can be aimed at researchers, practitioners, managers, teachers, or students; different styles and topics would be appropriate in the different cases. For example, a tutorial might provide an overview to a new research area for researchers who wish to enter it or understand it; skills to use state-of-the art development techniques; an explanation of a development or research methodology. Tutorials on both mature and emerging topics are welcomed. The length can be 90 minutes, 3.5 hours, or 7 hours.

For more details, please see

Saturday, October 27, 2012

SPLASH 2012 Doctoral Symposium

This week, I participated as a mentor in the SPLASH Doctoral Symposium.  A doctoral symposium is an opportunity for a small group of students to get feedback about their research.  The students also got to learn from watching other people go through the same process.  (This is a rather different format than the "PhD Working Groups" I wrote about previously.)

The event was so productive that it ran 2.5 hours over its scheduled time.

I had expected that the committee would give the students concrete suggestions about their choice of problem, the evaluation methodology, related work, and the like.  Instead, our feedback focused primarily on presentation issues.

One recurring problem was that the talks — and even the 2-minute "elevator talks" — often didn't state the concrete problem until midway through.  It is essential that the first sentence of an elevator pitch, or the first slide of a talk, states the problem, the key idea of the solution, and any evidence such as results.  If you do not grab the attention of the audience from the first moment, your presentation will be a failure.  You can proceed to general background and motivation later, but don't start with generalities that aren't directly relevant to your work, and don't dwell over-long on them.

Neither the students nor the other committee members was familiar with the Heilmeier Catechism, which is a set of questions for evaluating a proposed project.  I've found it very helpful:

  • What are you trying to do? Articulate your objectives using absolutely no jargon.
  • How is it done today, and what are the limits of current practice?
  • What's new in your approach and why do you think it will be successful?
  • Who cares?
  • If you're successful, what difference will it make?
  • What are the risks and the payoffs?
  • How much will it cost?
  • How long will it take?
  • What are the midterm and final "exams" to check for success?

After a round of feedback, we gave the students time to revise their elevator pitches and their formal talks, which led to significant improvements, though there were still plenty of comments from the committee.  Congratulations to the students for the progress they made!

Thursday, October 4, 2012

A conceptual introduction to version control

Version control is a commonly-used, essential tool, but one that often confuses beginners.  I often find myself often repeating the same explanations about version control concepts and the same advice about best practices -- especially for people who are new to distributed version control.  I haven't found a good source for this information, so I have written it up in a webpage that I hope others will find useful: