Where your conference fees go to

Fees for scientific conferences can be a cause for concern. Since most researchers are paid by public money, the question is whether this money is put well to use.  So where do your conference fees go?  Let me illustrate this on an example – the ISSTA conference I organized in 2016.

ISSTA is a nonprofit event, run by dozens of volunteers who run the conference as part of their paid job (or throw in extra hours for fun and honor); none of the researchers presenting, reviewing, or organizing make any profit from this.  ISSTA is run by ACM, which means that it covers losses but also gets any surplus; again, ACM is a nonprofit organization.

ISSTA 2016 attracted 113 visitors to its main conference, and 48 visitors to its workshops.  As with most conferences in our domain, students make the majority of visitors to the main conference, followed by ACM members.  (As an ACM member, you get a discount that is higher than the annual ACM membership fee, so it pays off to join ACM even if just for one year.)

Registration fees for the main conference vary between 300€ for students registering early and 750€ for non-members registering late; workshops fees were between 125€ and 300€.  On top of these fees comes a VAT of 19%.  These attendees make the conference, and their fees make the conference income – in the case of ISSTA 2016, exactly 70,460€.

When setting up the budget, you make non-students subsidize students: At ISSTA 2016, an additional student would actually incur a small cost; but this would easily be covered by additional non-students coming in (especially when showing up on-site!).  We also got a small amount of donations; other conferences and conference chairs are much better at getting these.

Of course, you do not know how many people will attend, so you calculate conservatively – I estimated 100+ visitors for the main conference, and planned accordingly.  The key point in planning, though, is the expenses.  This is what the expenses for ISSTA 2016 eventually broke down to:

Starting clockwise at the top, the biggest category is food and drinks, including social events like reception and dinner.  We spent about 50€ per person and day, which is pretty reasonable for two full meals, coffee, drinks, snacks, and all.  We ran ISSTA at my university, meaning that we could buy drinks and snacks at retail price; if you run a conference at a hotel, you would be charged hotel prices, say $3 or more for each and every can of soft drink, and you don't want to know about beer or wine. Workshops at ISSTA 2016 had relatively high fees, but little cost (essentially coffee, cookies, and a light lunch), and thus brought in revenue.  All expenses also incur taxes – in our case, again 19% VAT.

The next big block is registration, which covers most of actually organizing and running the conference.  Most of this is the fee charged by the conference organization agency of my university. They run a few dozen conferences every year and are very well-organized: their fee includes organizing costs (the folks who answer your queries and write visa letters), university overhead, and more. This item also includes the staff on site – in our case, student aides who gave out bags, served drinks, handled your queries, or oversaw the AV – as well as free bus tickets for all attendees (rides from hotel to the conference venue and back).  Overall, I estimate that the agency saved me two months full time of planning and organizing, so contracting them was a great return on investment.

Financial refers to 2% credit card fees.  Depending on your country and your financial provider, these may vary considerably.

ISSTA features a physical meeting of the program committee – that is, all reviewers meet for two days to discuss which papers should be presented.  This contributes to the quality of the conference, but also is very expensive.  The reviewers have to assume their travel, and the conference pays for meeting rooms, day catering, and a dinner.  We co-located the PC meeting with the ICST 2016 conference in Chicago.  This attracted more attendees to ICST; in return, ICST subsidized the PC meeting from the extra revenue, keeping the cost low.  This item also includes invited speakers, for whom ISSTA 2016 covered travel expenses as well as free conference and workshop tickets.

On-site logistics primarily refers to meeting rooms. These can be expensive, depending on the venue.  My university has reasonable prices for scientific meetings, including all technical equipment. Hotels often offer meeting rooms for free if you bring in sufficiently many guests, but then they may charge you for extras such as AV or Wi-Fi – and the rental of a single AV system can easily exceed the cost of an entire meeting room at the university.

The program needs to be printed; for publicity, we distributed leaflets at conferences and otherwise used free Facebook and Twitter channels. Other conferences would throw in paid advertising and throw in extras such as the proceedings on a USB stick.  ISSTA gave you a linen bag and an online access code for the proceedings.

Conference management refers to services around the conference, notably Proceedings, the cost of editing the accepted papers and making sure they all end up in the digital library, all properly tagged; as well as the Conference Management System, which handles submissions and the review process.  We used specialized services for both, again at reasonable cost.

Low cost and high attendance, especially at workshops, gave ISSTA 2016 a high surplus of 25,000€ – which all went to ACM such that ACM and SIGSOFT could keep on organizing and supporting research in our field.  Note, though, that such a surplus is not the rule.  You are supposed to plan for some contingency and overhead, but most conferences have a much smaller surplus. Despite best efforts of conference organizers, some conferences come up with a loss that would then be covered by the sponsoring society.  With ISSTA 2016, we were lucky – and if you ever go and organize a conference, I wish you the same luck, too!


I am leaving Saarland University, and the call for my successor is open

This year, I will leave Saarland University, where I have been professor for software engineering for 16 years.  Our CISPA Center for IT Security is about to segregate from Saarland University to become a Helmholtz Center, and I will be moving with it.

With base funding for 500 researchers, the new Helmholtz Center is set to become one of the largest research institutions in IT security – and hopefully one of the most renowned, too.  The recent research of my group in program analysis and test generation (watch out for papers this year!) positions us right at the intersection of software engineering and security, and I will be happy to contribute both to the research agenda as to the management of CISPA.  I will retain a footprint at Saarland University, though, keeping my professor title and reduced teaching obligations.

While the label on my office will change, my loyalty to the Saarland Informatics Campus will not falter the slightest.  I am grateful to work in one of the greatest research environments that could possibly exist, surrounded by colleagues who have proven their incredible excellence again and again, and who all work together every day for the excellence of the site as a whole.  When I started 16 years ago, we were maybe 15 professors in Computer Science; when I retire, there will be ten times as many.

This great environment can be your environment, too.  If your work is related to IT security, please check out our tenure-track and tenured career options at CISPA.  If your work is in Software Engineering, though, the call for my successor (German / English) is open as well.  It has been one of the best positions I could ever think of, and I am sure it could be the same for you!


The Rejection Song

To be performed by a scientific program committee (choir) and its chair (solo voice) to the tunes of the song "Go West" (Village People / Pet Shop Boys).  A program committee decides which scientific works get published.

(Together) We‘re the committee
(Together) We‘re the experts, see?
(Together) We will read your work
(Together) We will make us heard

Re-ject! This is our song
Re-ject! cos the data‘s wrong
Re-ject! it’s been done before
Re-ject! send it out the door

(Together) We select the best
(Together) We reject the rest
(Together) and the best is us
(Together) so why make a fuzz?

Re-ject! This is out of scope
Re-ject! it’s a slipp‘ry slope
Re-ject! It’s irrelevant
Re-ject! I don’t understand!

(Together) We define the field
(Together) We do form a shield
(Together) We are the elite
(Together) Life can be so sweet

Re-ject! no related work
Re-ject! you are such a dork
Re-ject! not my expertise
Re-ject! would you fix that, please

Re-ject! cos it’s really bad
Re-ject! cos I’m getting mad
Re-ject! there’s a missing bit
Re-ject! it‘s a piece of (fade out)

Music: Victor Willis, Henri Belolo and Jacques Morali
Above lyrics: Andreas Zeller


Mit dem Fahrrad aus der Saarbrücker Innenstadt zur Uni

Ich bin die meisten Tage des Jahres mit dem Fahrrad aus der Saarbrücker Innenstadt zur Uni und zurück unterwegs.  Für alle, die auch gerne mit dem Fahrrad zur Uni wollen, habe ich hier meine drei Lieblingswege auf einer Google-Karte zusammengestellt; Details folgen unten.

Und hier sind die drei Wege, sortiert von Nord nach Süd:

Der Schnelle: Am Meerwiesertalweg entlang

Ein nützlicher Weg, getrennt geführt neben starkem Autoverkehr.

Hier geht es lang: Vom Hauptbahnhof aus über den Bormannpfad (Alternative: durch Parkhaus Hela schieben), die Dudweilerstraße kreuzen und auf den Meerwiesertalweg.  Dort führt ein für Radfahrer freigegebener Radweg immer geradeaus mit zunächst moderater Steigung bis hoch zur Uni. Auf dem letzten Stück zwischen Uni-Parkhaus und Pforte wird es steil.

Ein Weg für: Normalfahrer, die schnell von A nach B wollen.

Aufpassen: Am unteren Ende des Meerwiesertalwegs sind zahlreiche Einmündungen, wo Autofahrer  insbesondere von den stadteinwärts auf der linken Seite fahrenden Radfahrern überrascht werden; erst ab der Jugendherberge wird es entspannt.  Der Weg am Meerwiesertalweg ist ein für Radfahrer freigegebener Gehweg, also gilt es, besondere Rücksicht auf die (wenigen) Fußgänger zu nehmen.  (Radfahrer dürfen zwar auch auf der Fahrbahn des Meerwiesertalwegs fahren, was aber wegen starken Autoverkehrs auf enger Fahrbahn keinen Spaß macht.)

Bester Moment: Wenn es auf dem Rückweg am Parkhaus entlang steil herunter geht – das ist der Rücksturz zur Erde.

Alternativen: Innenstadt über Scheidter Straße verlassen (siehe unten), dann über den Ilseplatz und Waldhausweg in den Meerwiesertalweg umschwenken.  Wer die Steigung am Parkhaus nicht mag, kann auch das Gelände der Sporthochschule erkunden.

Der Sportliche: Durch den Stadtwald zur Uni

Mein morgendlicher Weg zur Uni – steil und schön

Hier geht es lang: Die Innenstadt über Beethovenstraße/Blumenstraße verlassen (eine ruhige Strecke entlang Einbahnstraßen, die laut Verkehrsentwicklungsplan irgendwann zur Fahrradstraße ausgebaut werden soll), auf die Scheidter Straße wechseln und bis zu deren Ende immer höher fahren.  Hinter der Wendeschleife geht es in den Wald, wo wir sofort links an der Schranke vorbei auf einen asphaltierten Waldweg wechseln, der uns bis zur Uni führt. Der Weg führt steil durch den lauschigen Stadtwald hinauf.  Etwa auf halbem Wege geht es dann bergab, man rollt entspannt zur Uni herab, und lässt den Schweiß im kühlenden Fahrtwind zurück.

Ein Weg für: Mountainbiker, Elektroräder, Naturliebhaber.

Aufpassen: Der Radweg entlang der Scheidter Straße ist durch parkende Autos von der Fahrbahn getrennt; ausfahrende und parkende Autofahrer übersehen hier Radfahrer gerne.  Der Waldweg ist unbeleuchtet; Schnee wird spät geräumt.  Auf dem Rückweg geht es auf der Scheidter Straße steil bergab, also besser auf der Fahrbahn bleiben.

Bester Moment: Morgens im Wald den Berg hinauf.  Nichts zu hören außer Vogelgezwitscher.

Anschlüsse: Noch höher hinaus?  Auf den Schwarzenbergturm für ein kleines Workout und oben die Aussicht genießen.

Der Flache: Über Schafbrücke und Scheidt

Feierabendstrecke mit nur moderaten Steigungen, die Hälfte auf ruhigen Wegen.

Hier geht es lang: Die Innenstadt an der Saar entlang verlassen; spätestens an der Ostspange nach links abbiegen und auf die B51 nach rechts fahren. Auf dem Radweg geht es an der B51 eher unproblematisch immer geradeaus. Nach den Römerkastell geht es auf einer Fahrradspur leicht bergauf; danach geht es nach links in die Breslauer Straße, und dann gleich rechts auf die andere Seite der Bahnstrecke.  Jetzt kommt der schöne Teil: Es geht auf ruhigen Wegen durch Schafbrücke immer an der Bahn entlang, bis wir in Scheidt nach der Überführung links abbiegen und wieder mit leichter Steigung zur Einfahrt Ost der Uni fahren.

Ein Weg für: Entspannte Kilometerfresser.  Leute, die zum Ostteil der Uni wollen.

Aufpassen: In der Innenstadt sind entlang der Mainzer Straße wie auch an der Saar viele Fußgänger unterwegs, also Rücksicht nehmen. Der Abschnitt Römerkastell-Breslauer Straße ist verkehrsreich; beim Linksabbiegen in die Breslauer Straße auf eine Rotphase warten, dann den Extra-Wartebereich für Fahrradfahrer nutzen, um sich links einzuordnen. Von Scheidt zur Uni führt der Radweg getrennt auf der linken Seite entlang; Vorsicht bei Einmündungen.

Bester Moment: Auf ruhigen Wegen flott durch Schafbrücke.

Alternativen: Zwischen Römerkastell und City sind Preußenstraße und/oder Halbergstraße verkehrsarme Fahrrad-Alternativen zur B51.  Wer im Saar-Basar einkaufen mag, kann das Gelände im Westen über eine Pforte via Eschberger Weg und Im Heimerswald erreichen.  Statt des asphaltierten Radweges von Scheidt zur Uni kann man auch am Rückhaltebecken links abbiegen und einen unbefestigten Waldweg nehmen.

Anschlüsse: Sehr schöne Radwege gibt es die Saar entlang Richtung Saarlouis oder Sarregemuines.  Der Radweg nach Scheidt führt auf ruhigen Wegen weiter an der Bahn entlang Richtung St. Ingbert.  Alle Radwege sind ausgeschildert.

Hinweis: Als Rückweg (also von Uni zur Innenstadt) attraktiver, da (a) leichtes Gefälle (b) am Römerkastell weniger Kreuzungen und (c) der verkehrsreiche Abschnitt zwischen Breslauer Straße und Römerkastell ist schnell überwunden. 


Twelve LaTeX packages to get your paper accepted

(with Abhik Roychoydhury and Aditya Kanade)

Why do some people get all their papers accepted, and others do not?  You may already know that in many disciplines, using the LaTeX typesetting system correlates with having your paper accepted (in contrast to, say, Word).  What you may not know is that there is a number of LaTeX packages whose usage may be crucial for success.  Here we go:
  1. The pagefit package.  This immensely useful package makes your paper exactly fit within a given page limit, applying a genetic search algorithm to reduce baseline distances, white space, font sizes, or bibliographic references until it exactly fits.  Just write \usepackage[pages=12,includingbibliography]{pagefit} and enjoy.  
  2. The autocite package. Cites all relevant work that needs to be cited.  The "citepc" option additionally cites the entire program committee, whether their work is relevant or not.
  3. The translate package.  Auto-translates your paper into a given target language (default is English).  Just type


PostDoc Position, Software Testing and Analysis / Software Engineering

At my Chair at Saarland University, we currently have a PostDoc position available, to be filled during the Spring of 2017.  We are looking for applicants in all areas of Software Engineering, with a special focus on experience in
  • Software Testing and Analysis
  • Security and Privacy
  • Specification and Specification Mining
  • Data Mining and Machine Learning
Your job is to conduct bold and risky research, possibly interacting with the several great PhD students at the chair.  Our most recent projects include
If such work inspires you, and if you see chances to combine your expertise and creativity with ours, we'll be happy to hear from you.  Please have a look at the official announcement and apply before December 1.


On Facts and Dreams in Software Research

Where is the economic argument in program verification research, and where are the salvation messages in software engineering research?

I just had the pleasure of attending David Rosenblum’s keynote at ASE 2016, in which he praised the power of probabilistic thinking (using stochastic reasoning to estimate risks and support decisions) versus an absolutistic view in which there is only 100% truth or 100% failure.  His takeaway message was that software engineers should embrace probabilistic methods and permeate them throughout the development process.

As a software engineer, probabilistic thinking is a central part of my day-to-day job – in development as in research.  Whatever I build and design, I think about how useful it might be, which benefits it may bring, and what the associated risks are.  In Software Engineering research, the dominating metric is usefulness, which eventually translates into an economic argument: What does it cost? What are the benefits? What are the risks?  These are day-to-day questions in software development, and my research is expected to provide facts to help answer them.

In other fields of computer science, such as software verification, the economic perspective is much less argued about.  Instead, the message touted is an absolutistic message of salvation: If you apply this technique, you will get a 100% guarantee that your software satisfies certain requirements – that the computation will be correct, that it will not crash, or that it will terminate within specific time bounds.  For developers and society, this message feels like the second coming of Christ: The day will come and all your problems will be gone.  

Up to now, there are great examples of how software verification works, and there are impressive examples of it being successfully used in practice; and just to be clear: By no means would I want to reduce these research efforts.  But the systems formal verification is applied to are still small and constrained; and getting it to scale and widen will require enormous human effort reshaping existing systems – before salvation comes repent.  Do we actually know how costly formally verified software is?  Do we know how to teach its techniques to developers who do not hold a PhD?  Can we estimate the risks it brings to rely on freshly written specifications, rather than on mature systems?  Might "good enough" software be good enough?  When talking to researchers in software verification, such economic arguments are frequently missing in the debate. But as a society, we need to understand where money is best spent, and answers to such questions could very well guide the field of software research.

Conversely, just as formal verification may benefit from introducing an economic perspective, Software Engineering may profit from adapting a stronger salvation perspective.  What is it that Software Engineering research could produce that would be seen as a salvation in software development – a significant reduction of costs or risks?  Recent topics that come to my mind are automatic software debugging and repair, steering development processes based on mining software histories, or massive automated test generation.  Can we translate our capabilities into grand challenges that will provide salvation in the future, possibly even including guarantees?  Yes, I know there are “no silver bullets” in software development.  But any great research community should pursue great dreams as well as provide facts – and in this, all of us computer science researchers are in the same boat.