if you plan to invite me for your upcoming event, please avoid nightmares like this one

I frequently get invitations to give talks at conferences, summer schools, and other events.  Normally, it is an easy thing: I check my availability, agree, book travel and hotel, prepare and give a talk, have fun, get reimbursed.  Not so with this recent summer school in France, though.

January.  I get an invitation to lecture at a summer school in France.  Sounds fun and exciting, but it is in our exam week.  I go for a compromise: I accept, but will be able to join only for one day.  As usual, I don't get paid for such events, but the trip will be taken care of.

February.  The organizers ask all speakers for a flight connection, such that they can book a flight for us.  I spend an hour looking up possible flight connections on Expedia, only to find that the plane will be cumbersome and expensive.  I send the quote, adding that going by train will be cheaper and faster, an assessment shared by the organizer.

February.  The summer school asks me for a quote of the train ticket.  This is not possible yet, as the ticket can only be booked three months in advance.  I give an approximate price based on next month's connections.

March.  I send title and abstract and state my availability for the lecture (Tuesday or Thursday).  Everything is fine.

April 17.  The summer school produces a flight itinerary and asks me to confirm the booking.  Flight?  I reply stating that we already agreed to have me travel by train; I again retrieve and provide a quote for the train ticket.  As the flight itinerary assumes that the talk be on Wednesday (which does not fit me), I ask that my talk be moved according to my availability.  The organizers agree.

April 17.  In return, the summer school produces a train itinerary, again asking for confirmation.  The itinerary also assumes my talk is on Wednesday.  I cannot confirm the itinerary, repeating that the date does not suit me and that my talk date will be moved to either Tuesday or Thursday.

April 22.  I get a tentative program, where my talk is scheduled on Wednesday morning.  This is the day on which I am not available, and I curse between my teeth.  I again ask for the talk to be rescheduled.  The organizers apologize for their mistake and schedule my talk for Thursday.

April 29.  I get an electronic train ticket.  This booking is still the same itinerary as on April 17, assuming my talk would be on Wednesday.  I am pretty upset and state that the ticket neither fits my schedule nor the revised schedule of the summer school.  Rather than exchanging more mails, I suggest I book the ticket myself, saving time and money.

April 30.  The organizers apologize for their confusion, and ask me to please book a ticket myself.

April 30.  I book a train ticket on the SNCF site.  This takes me 10 minutes.  I send the itinerary to the organizer, who again apologizes.  All seems to be set.

May.  The administration asks all speakers for bank account information, address, and passport copy, which I all provide.

June 5.  I get a hotel voucher for my stay.

June 27.  The organizers ask all speakers for rechecking the information on their Web site.  I am busy in a PC meeting and postpone the check for a few days.

July 1.  The organizers urgently ask me if it would be okay for me to chair a session on Wednesday morning.  Wednesday?  I will be traveling on Wednesday morning, so no.  I remember the earlier message to recheck all information.  It turns out that on the Web site, my talk is still scheduled on Wednesday, and my hotel is booked wrongly, too.  As I realize this, I jump up and scream, literally banging my head against the wall; my secretary comes in and asks whether everything is okay.

July 1.  As I cool down,  I write to the organizers. I repeat my travel details and for the last time, ask the organizers to reschedule my talk as confirmed multiple times.  The organizers again deeply apologize for the confusion and promise that the schedule will be fixed.

July 2. [Update]  I cancel my participation, wishing all the best to the summer school, and bearing the ticket expenses myself.  I feel relieved and relaxed.  All is well that ends well.

Lesson learned #1: While this trip has easily caused me more trouble than all my other trips combined, let me state that almost all of my business trips are painless, including all my trips to France so far.  Also, other lecturers at the same event report that their booking all went well, so I guess I just had a long series of unfortunate events which is not typical for France at all.

Lesson learned #2: If you organize an event, make sure you have a single point of contact – there should be precisely one person to talk to the invitees, who keeps track of all information and (possibly) interacts with the administration.  Do not have your administration interact with the invitees directly, bypassing you; likewise, keep the administration updated at all times.

Using Microcontrollers to teach Programming to Engineers

This Summer, I am exceptionally busy.  I am teaching a course "Programming for Engineers" – a first-year course (twelve 90-minute lectures, plus exercises) for 120 engineering students who are to learn programming in C (and a bit of C++).  In the past years, this has been one of the less popular courses both among its teachers and its students, so our Dean of Studies was very astonished and happy to have me volunteer for it.

The reason I had volunteered is that earlier this year, my 12-year old daughter and I had toyed with an Arduino micro controller board, writing simple programs that would cause LEDs to blink and buttons to be checked.  Left on her own, my daughter (who had no C experience before) already had produced a full traffic light control for an intersection, together with a button to trigger a pedestrian crossing – and all of this within a few hours.  The Arduino board served very well as a motivator: Controlling a set of LEDs and buttons is so much more concrete, tangible, and direct than printing "Hello, world" on a screen.

As computer scientists, we tend to abstract away the concrete machinery – because computer science is the science of abstraction, getting rid of concrete details until all that remains is the pure beauty of computation.  Unfortunately, this is not the mindset of engineers at all, who see programming not necessarily as an exercise in elegant design, but mainly as a tool to get their actual job done.  A micro controller board is a great device to connect between the world of programming and the world of engineering; all of a sudden, everything you learn during programming becomes directly usable for engineering contraptions of any kind.

So, I set off to build the programming course around microcontrollers.  Intel donated us 40 Galileo boards (thanks so much!), which we fitted with electronic equipment such as LEDs, 16x2 LCD displays, photo resistors, microphones, speakers, breadboards and (many) cables – all of which would be used to motivate specific programming exercises.  Each set would be shared by a group of four students.  The process is that we give out a programming assignment each week, which each student solves and submits individually first (using only static checking, without executing them – welcome, cleanroom software engineering), followed by a group session in which the students jointly put together their programs to then test and demonstrate their final working solution on their wired board.  Each student must be able to explain the group's program, so they get some exposure to teamwork and understanding programs, too.

So far, it has been a great course.  We set off with getting LEDs to blink, subsequently defined our own functions for sending Morse messages.  Checking whether a button is pressed is surprisingly hard, as you have to introduce timer checks to handle possible contact bounce.  Introducing multiple LEDs to display a voltage level led to arrays and loops; I used the final 20 minutes of the lecture to demonstrate how the Heartbleed bug works through buffer overflows.  Later today, we will explore interactive automata, using the LCD display to select drinks from a soda machine.  I don't know yet what will be up next week, but I reckon it is time to convey some algorithmic thinking, and by the end of the course, students will be left to their own devices to work on self-designed projects.  From what I hear from tutors, students so far are very motivated and eager to learn.  What else could you ask for?

The only downside of this course is that it requires quite a lot of preparation.  Before each lecture, I have to set up and wire my own microcontroller board, and it takes an extra ten minutes to set up and tear down the mounted camera to transmit live pictures of the board on my presentation; there's also plenty of live programming and interaction, which means I have to build and test all programs in advance.  Giving out thousands of electronic pieces to students also was a logistic challenge (thanks to all tutors!).  Furthermore, I have to build this course from scratch.  Together with my other new course on "Generating Software Tests" (more on that in a later post), I am currently producing no less than 140 slides a week.  So if you are eagerly waiting for my response, or wonder why I say "no" to almost everything these days – just keep in mind that this Summer, you are competing with 120 students who all await my latest and greatest.

For those interested: Here is the website of the course, with slides and all (in German).

Since I follow "Getting Things Done", I get more reminders, not less

As a professor, I have many responsibilities and tasks to take care of, and many of these have deadlines.  To keep track of them, I use an automated "To-Do"-Tracker, which allows me to enter new tasks (and ideas!) quickly, to assign categories and priorities to them, and to mark them as completed when I'm done.  Most importantly, I can attach a "due date" to every task, and tell my tracker to automatically have a task pop up a few days in advance – typically the number of days I will need to complete it.  So far, this works pretty well: When someone asks me whether I'd be available for a task, I can get a good assessment of my commitments (implying the answer is typically "no"); but if I commit to a task, it will almost certainly be done by its deadline.

Now, here's the fun thing.  Since I use this approach, I get way more reminders than before.  Journal editors tell me that my review is due in only five days.  PhD students send me worried letters that I haven't sent out the referral letter yet, due on Friday.  Conference chairs send me friendly reminders that I am an author, yet haven't registered for the conference, due in a week.  Thank you for the reminders – actually, I know all that, as my to-do tracker nicely tells me so, and it is all factored in. Today, I need to work on this paper, this book chapter, this slide deck – all stuff which gets better the earlier it can be reviewed; and I know that the task you remind me off can still wait until due day, or the N days it will take me to complete it.  In 2013, I completed 700+ tasks, and there was only one reminder which was effective (because I had mistyped the completion date).

Overall, I believe that this "just in time" production makes me more effective, as it puts things in the right order (and the right priority).  But then, it apparently strains the nerves of everyone else involved.  Should I set up a rule to complete everything a week before it is due?  Or should I set up a disclaimer of sorts?

(And now back to my "To-Do"-tool: Five days left to complete this paper.  Better start today...)

Post-Doc Position with Andreas Zeller at Saarland University

[Update 20-01-2014: The position is no longer available.  Thank you!  -- Andreas Zeller]

At the Software Engineering Chair at Saarland University (Andreas Zeller), we have a post-doc position available for initially two years, starting March 1, 2014 or later.  We are looking for applicants in all areas of Software Engineering, with a special focus on experience in

• Program analysis and testing
• Specification and specification mining
• Empirical software engineering
• Security and privacy

Our group currently consists of one professor, two post-docs, and ten PhD students, all working on how to increase programmer productivity and program quality. We have a record of substantial impact at international venues, are well funded, and are fun to work with. We cooperate with researchers around the world, including companies like Google, Microsoft, or SAP. Our students are constantly looking for research challenges in their BSc and MSc theses.

Saarbrücken is one of Europe's leading places in computer science research. It features Computer Science at Saarland University, two Max-Planck-Institutes for Informatics and Software Systems, the German Center for Artificial Intelligence, the Intel Visual Computing Institute, an Excellence Cluster in Multimodal Computing and Interaction, as well as the Saarbrücken Graduate School for Computer Science totaling more than 400 researchers. There are ample opportunities for local cooperation beyond the chair.

English is the working and teaching language all over computer science. Germans generally have reasonable command of English; and in day-to-day life, you can easily get along with English as your only language. (You may wish to learn the German food names, though, to avoid surprises.)

Mandatory conditions of employment are:

• PhD in Computer Science or Software Engineering
• Fluency in English

Full-time positions are divisible in principle (§ 7 Abs. 1 TzBfG).

Salary will be paid according to German TV-L.

The university aims to increase the number of women in this field. Therefore, women are especially encouraged to apply for this position.

Severely handicapped persons are preferentially employed in case of similar qualification.

The position is available as of March 1, 2014. You should apply before December 22, 2013, although later applications may also be considered.

Please send a detailed CV, including two referees, as a PDF document to:

Prof. Dr. Andreas Zeller
Saarland University – Computer Science
office@st.cs.uni-saarland.de
Tel.: +49 681 302-70970

Applications have to include reference no. W793.

Summarizing your presentation with miniature slides

The slide that drives me nuts

As part of my job, I listen to talks a lot.  There's good talks, and there's bad talks.  But nothing can drive me as crazy as making a slide like this your final slide:

What's wrong with showing "Thank you!" at the end?  Or "Questions?"?  Or both?  The problem is that most talks are followed by a discussion.  With a slide like this showing up at the end, there's three problems:

• Parts of your audience will have lost contact during your talk, and wake up for the final slide only.  With this showing up, they won't get the message.
• The idea of the discussion is to get valuable feedback.  But to ask questions, your audience will have to get the technical terms right.  If they don't remember the exact name of your technique, they won't ask questions for fear of embarrassment.
• If the discussion goes for five minutes, this is the single slide that shows up for the longest time.  This is such a missed opportunity for delivering your message!

The bullet summary style

A much better alternative is to simply say "Thank you" and to use the screen space for summarizing your talk.  In standard bullet style, the slide would look something like this:

Your audience can now use the slide to ask questions ("Your... errr... Bumblebee technique: If it is better for amblefuns, wouldn't it be worse for fumbleduns?"); people who have slept throughout your talk still get the message; and anyone who finds the discussion too special have all the time to enter the URL into the browser of choice to learn more about the project. Much better already.

Summarizing with miniature slides

The "bullet style" summary still has issues, though.  Many talks have diagrams that summarize processes or results.  These won't show up on a bullet style slide, and as these invariably attract the most questions ("Why is it that this column is so high?"), you frequently have to switch back to earlier slides, which (a) takes time and (b) again takes the summary of your talk away from the audience.

Here's my solution for the last slide.  Take the four most important slides of your talk (say: problem, process, results, and discussion), and paste them together on one single slide.  The result looks like this:

All these are slides that were shown earlier during the talk; hence, I can make it easy for my audience to recapitulate what I said.  During discussion, I can simply point to the appropriate detail on the slide, and I never have to switch back to an earlier slide.  Even if the text is hard to read at 50% of the original size, this does not matter much, as the audience will remember most from the talk anyway.  I have been using this style for eight years in a row now, and it has worked ever since.  Enjoy!

Update 1: How do I produce such miniatures?  On a Mac, the process is straightforward.  In Keynote or Powerpoint, select a slide and copy it to the clipboard.  In Preview, use Command-N to open the clipboard, and Command-C, which copies it back again, but now as a bitmap.  Go back to Keynote/Powerpoint, paste it in, resize and position appropriately.  That's all!

Update 2: Actually, it might have been me who invented this style of summary, or at least introduced it to the community.  On December 6, 2005, I gave my first talk on "Model Mining", using miniatures on my final slide, and I don't think having seen this before. Anyone with earlier "miniature" slides? Please step up!

Update 3: Here's my (or "the"?) first slide with miniatures from December 2005:

Faster, better, stronger: The case for one-phase reviews

When running a scientific conference, one has to decide which submitted papers get published (and presented), and which ones are not.  Each paper gets a number of reviews; and based on these, the program committee decides which papers get accepted.

Flooded with submissions, several SE conferences went for a two-phase model to reduce workload: A paper first gets two reviews, and only if at least one of these favors acceptance, the paper gets a third review.  As PC chairs of ASE 2013, we went back to a single-phase model, though.  Several people have asked us why this was so.  The answer is: time.  With a one-phase review, you can cut the time required for reviews in half, thus allowing for more, better, and more recent papers.


The math is as follows. Let's assume your conference gets 314 papers submitted (as we had for ASE):

• In a two-phase model,
•  314 papers would have gotten two reviews, totaling 618 reviews.
• 1/3 of papers are eliminated in the first round, leaving 210 which get a third review.
• Total number of reviews: 618 + 210 = 828.
• In a one-phase model,
•  314 papers get three reviews, totaling 942.

By having the one-phase model, your conference will thus have 14% more reviews – in our case, 22–23 papers to review per PC member instead of 20.  However, going for two phases requires a lot more administrative overhead – for the PC chairs, of course, but also for the reviewers.  In particular, you need to allocate two phases in which to do the reviews – instead of, say, eight weeks, where reviewers would be free to allocate their load, you now have six + four weeks, each of which may be more easily blocked by travel, holidays, etc.  Plus, as a PC chair, you need at least another week in between to reallocate and inform the new reviewers.

All in all, you thus trade 14% more reviews against an extension of the review period by three weeks.  Not necessarily a good thing.  In addition, this assumes that papers are all equal; but they’re not: The 14% extra papers are mostly papers that would be quick rejections anyway.  So, not much damage either.

Assuming that more than a third of papers may be rejected in the first round favors the two-phase model.  But then, there’s the concern that by having only two reviewers, you run a greater risk of one reviewer being incompetent, unwilling, lazy, etc.  (It happens to anyone.)  So you may be have to introduce rebuttals to compensate for potential misjudgments, and here go another two weeks of reviewing period.  And then, someone will have to read these rebuttals, which adds more overhead.

To illustrate how two-phase reviews and rebuttals eat up time in contrast to one-phase reviews, let's take a look at ICSE 2014, whose papers are due September 13, 2013.  Notification is January 17 – that is, more than four months later.   For ASE (one phase, no rebuttals), this was May 17 to July 25 – two months and one week, or roughly half the time ICSE takes.

With its short reviewing period, ASE 2013 had more than three times the number of submissions compared to last year, which gave us a great choice of papers.  ICSE will also have a record number of submissions; but if you miss the deadline, chances are you will find another conference which will publish your paper well before ICSE.

Summary: Get rid of frills, and allow authors six more weeks to prepare their submissions.  You will get more, better, and more recent papers – and more, better, independent reviews at the same time.

A Slide Generator for EasyChair

If you chair a program committee with a physical meeting and use EasyChair as a conference management system, then the EasyChair Slide Generator is your friend. This script

• generates slides structuring the discussion at the PC meeting
• generates personalized discussion lists for each PC member
• generates a conflict-free seating order for all PC members.

EasyChair Slide Generator comes as a Python script, tested on Mac and Linux systems. As input, it takes an EasyChair data export; see the included README.txt file for details.  Enjoy!

=>  EasyChair Slide Generator