Talk video: "Software evolution then and now: the research of David Notkin"

On Friday, February 1, at an event honoring David Notkin, I gave a 30-minute talk that surveyed a few of his research contributions.

The talk video is available, for download or streaming, at http://www.cs.washington.edu/events/colloquia/search/details?id=1334

The title and abstract are as follows:


Software evolution then and now: the research of David Notkin
by Michael Ernst
February 1, 2013

Abstract:  Software engineering is a deep and important field that has been tremendously successful. David Notkin has contributed to that success during a distinguished career spanning three decades. This talk discusses a few of his research projects. For each project, the talk explains the problem and the solution. The talk highlights ways in which David Notkin's work has impacted not just other software engineering researchers, but also working programmers.

Responding to conference reviews

I have added a section "Responding to conference reviews" to my webpage about writing a technical paper.

An easier way to make exams

Recently, some of my colleagues bemoaned the effort of making up exams at the end of the term.  I wanted to share a trick that I have used, that makes creating exams much easier.  It might work for you too.

I work on exam questions throughout the term rather than waiting until the end.  A TA is assigned to each lecture, and is required to make up a couple of questions during or immediately after the lecture.  This way, we get ideas that pop into the TA's head but that might have been forgotten by the end of the term.  Another excellent source is student questions during class.  Likewise, we harvest common misperception and questions from office hours.  These often turn into excellent exam question as well, since they are topics that could confuse a student but that were covered in class.

More advice about creating an exam appears at http://homes.cs.washington.edu/~mernst/advice/exams.html

Don't scan your recommendation letters

Faculty are writing lots of recommendation letters right now.  One of my colleagues went to extra effort to print his letter, sign it, scan it, and then upload it.  Unfortunately, this was counterproductive.

If you are requested to provide a letter in PDF, provide the original PDF that was created by your word processor or typesetting program.  Don't scan the document, which makes it much harder to read.  You don't want eyestrain (or anything else) to lessen the impact of your letter.  You can either insert a PDF signature, or have just a typewritten signature; no one really cares whether your signature is on the letter.

Another irritation I have seen:  don't use "watermark" letterhead that puts a large, dim image (for example, of the university crest or logo) behind the text.  Some people apparently think this looks cool and sets their letter or institution apart (MIT CSAIL, I am looking at you), but in fact it makes the letter harder to read without impressing anyone.

More advice on writing a letter of recommendation appears at http://homes.cs.washington.edu/~mernst/advice/write-recommendation.html

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 http://2013.icse-conferences.org/content/tutorialsCFP

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!

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:  http://homes.cs.washington.edu/~mernst/advice/version-control.html