2014-10-07

Wie Universitäten die "Industrie vor Ort" unterstützen können: Firmen gründen, statt Firmen nachzueifern

Forscher stehen unter Druck, Probleme der Industrie vor Ort zu lösen.  Dies verkennt jedoch die Rolle der Universitäten.  Würden Länder und Universitäten aber Firmengründungen besser unterstützen, wäre allen geholfen, meint Andreas Zeller.

Ein Kollege von mir hat sich unlängst an einer deutschen Universität auf eine Softwaretechnik-Professur beworben.  Im Bewerbungsgespräch ging es neben zukünftiger Forschung und Lehre vor allem um die Frage, "wie er denn der lokalen Industrie helfen könnte".  Die lokale Industrie: das ist ein Mix von mittelständischen Unternehmen, die vor Ort Produkte wie Bleistifte oder Autoteile produzierten.  Mein Kollege gab wahrheitsgemäß zur Antwort, dass seine Forschung vorwiegend in der Software-Erstellung eingesetzt werde; er wäre dementsprechend international ausgerichtet.  Diese Antwort schien der Kommission aber nicht zu gefallen; und so erhielt er eine freundliche Absage.

Die Frage, "was man denn für die lokale Industrie tun könnte", ist mir als Forscher schon mehrfach begegnet.  In Verhandlungen für eine Professur an einer norddeutschen Universität wurden mir stolz die fünf Büroräume präsentiert, die für die "vielen lokalen Projekte" reserviert waren, die ich sicherlich "bald akquirieren würde".  Die Landesregierung des Saarlandes hat die hiesige Informatik durch die Blume wissen lassen, dass sie es trotz aller Erfolge der Saarbrücker Informatik gerne sähe, wenn es mehr Kooperationen "vor Ort" gäbe, von denen die "lokale Wirtschaft" profitierte.

Die Forderung nach "Kooperation vor Ort" ist zunächst einmal nachvollziehbar.  Hier bin ich, der Leiter eines mittelständischen Unternehmens, und ich habe große Probleme mit meiner IT.  Zufälligerweise gibt es nur wenige Kilometer entfernt eine große Universität, voll mit Informatikern, die Ahnung haben.  Da liegt es doch nahe, zu fragen, ob die nicht helfen können.  Und da die Universität meistens aus Landesmitteln finanziert wird, die zudem aus meinen Steuern kommen, könnte das Land doch entsprechend Druck ausüben, richtig?

Diese Denkweise verkennt jedoch die gesellschaftliche Rolle einer Universität.  Universitäten haben zum einen die Aufgabe, Forschung zu betreiben – und sich mit Fragen zu beschäftigen, die in der Regel zu abseitig oder zu risikoreich sind, um damit unmittelbaren wirtschaftlichen Gewinn zu erzielen.  Es kann Jahre, gar Jahrzehnte dauern, bis Forschungsergebnisse außerhalb der Universitäten aufgegriffen werden.  Immer wieder aber gelingt der eine oder andere Durchbruch, der ohne langjährige freie Forschung gar nicht möglich gewesen wäre, und davon profitiert die Gesellschaft als Ganzes.

Damit die Gesellschaft aber Nutzen von Forschung ziehen kann, müssen Forscher wissen, welche Probleme es zu lösen gibt.  Als Informatiker muss ich mich damit auseinandersetzen, wie ich komplexe, vernetzte Systeme sicher und verlässlich mache, wie ich wichtige Daten schützen kann; und ich muss über kurzfristige wie langfristige Lösungen nachdenken.  Im Gespräch mit der Industrie bekomme ich einen Eindruck davon, welche komplexen Nebenbedingungen es gibt, und welche Lösungen zumutbar sind; auch dies ist ein wichtiger und wertvoller Teil meiner Forschung.  Geht es jedoch darum, die konkreten Probleme "vor Ort" zu lösen, muss ich mich fragen, inwiefern ich aus einer Lösung ein allgemeines Prinzip ableiten kann.

Wäre ich Maschinenbauer in Braunschweig oder IT-Forscher im Silicon Valley, hätte ich vor Ort jede Menge "lokaler" Industriepartner, bei denen dies problemlos ginge – Firmen nämlich, die im Kernbereich meiner Forschung produktiv tätig sind, und die daher meine Interessen teilen, innovative, tragfähige, und möglichst allgemeine Lösungen zu finden.  Kümmere ich mich jedoch um die konkreten Probleme der Anwender, etwa der Bleistiftfirma, die ihre IT neuorganisieren muss, geht Zeit und Energie für die allgemeinen Lösungen verloren – und das sind die, die zu finden ich bezahlt werde.

Wenn ich es will, kann ich natürlich "vor Ort" auch mit IT-Anwendern arbeiten.  Ich mache einen Schwung Beratungsverträge mit der lokalen Industrie, und stelle billige Doktoranden ein, die dann die Probleme vor Ort lösen (und "nebenher" irgendwie promovieren).  Ich generiere jede Menge "Drittmittel" aus der Industrie.  Ob dies zu einem allgemeinen Erkenntnisgewinn führt, bleibt hintenangestellt – Hauptsache, die Zahlen stimmen.  Will ich das, und warum?

Die zweite Aufgabe der Universitäten ist es, junge Leute zu bilden – oder weniger vornehm, auszubilden.  Meine Kollegen und ich haben den Anspruch, Menschen zu produzieren, die die jetzigen und kommenden Herausforderungen der Informatik meistern können. Wir tun dafür, was wir können – und mit Erfolg: Unsere Absolventen können sich in der Regel aussuchen, wo sie arbeiten; und sie gehen dorthin, wo sie die beste Arbeit bekommen.  Firmen wie Google oder Microsoft sitzen nicht nur an angesagten Orten, sie zahlen auch sehr gut; und sie sorgen dafür, dass sich unsere Absolventen um nichts kümmern müssen, einschließlich Wohnung, Mahlzeiten und Wifi-Shuttle.  Unsere besten Absolventen sind weltweit begehrt, und sie wissen das.

Dies wiederum macht der "lokalen Industrie" zu schaffen, die nicht mithalten kann oder möchte.  Ein örtlicher Vertreter einer großen deutschen Telekommunikationsfirma hat mich vor kurzem besucht, und gefragt, wie es denn sein könne, dass so wenig unserer Absolventen sich bei ihnen vor Ort bewürben  – schließlich sei es doch eine spannende Herausforderung, das Zusammenspiel von nicht weniger als zwölf Alt- und Neusystemen zu orchestrieren.  Ich fragte zurück, ob er mit den Sozialleistungen etwa von Google mithalten könne.  Nun ja, sie würden nach Tarif bezahlen, hat er geantwortet, und Essen und Massage – nein, das sei nicht drin.  Und da ist das Problem.

(Was das ganze noch pikanter macht, war die Forderung eines IHK-Vertreters, wir mögen unsere Ausbildung weniger international gestalten, damit die Firmen "vor Ort" mehr Chancen hätten, unsere Absolventen anzuwerben.  Muss ich das kommentieren?)

Was die lokale Industrie will, ist die Lösung ihrer Probleme.  Das ist völlig legitim.  Was sie vermeiden möchte, ist einen Marktpreis dafür zu zahlen.  Es gibt sehr gute Absolventen, die ein Problem nach dem anderen lösen, doch die kosten Geld – und schlimmer noch, sie verlangen gute Arbeitsbedingungen und das Gefühl, etwas wichtiges zu tun.  Es gibt hervorragende Beratungsfirmen, deren Problemlösung man einkaufen kann; doch die kosten noch mehr Geld.  Wer fordert, Forscher an den Universitäten mögen doch bitte die Probleme "vor Ort" lösen, verlangt staatlich subventionierte Dienstleistungen – die in Konkurrenz zu Absolventen und IT-Industrie stehen.

Ich habe nichts gegen Subventionen, wenn sie als Investition dienen, also langfristig Gewinn versprechen.  Wenn ein Land, eine Universität, aber etwas langfristig Gutes für die Industrie "vor Ort" tun will, und dabei freie Forschung nicht nur nicht behindert, sondern unterstützt, gibt es einen anderen, weit besseren Weg, nämlich aus der Universität heraus Firmen zu gründen.  Eine Neugründung kann einerseits spannende Forschungsergebnisse vermarkten, und so Teil der Industrie vor Ort werden.  Sie kann aber auch Dienst- und Beratungsleistungen vor Ort anbieten, und so der Wirtschaft weiterhelfen. Eine Neugründung kann sich die Arbeitsumgebung schaffen, die die richtigen Absolventen anzieht.  Das Land freut sich über Arbeitsplätze und erhöhtes Steueraufkommen; die Universität profitiert durch Lizenzeinnahmen und einfacherer Legitimation ihrer gesellschaftlichen Relevanz.

Bin ich als Forscher mit einem Startup assoziiert, muss ich mich nicht fragen, wie ich Anfragen der Industrie im Universitätsalltag lösen kann; ich kann einfach auf die entsprechende Firma verweisen.  Ich habe ein Ohr an den zu lösenden Problemen, und kann meine Forschung anwendungsnäher gestalten, ohne den Anspruch auf Allgemeinheit aufzugeben.  (Wenn dabei eine neue Forschungs- oder Firmenidee abfällt, um so besser.)  Und ich kann den Absolventen, die nach ihrem Abschluss weiterhin spannende Arbeit machen möchten, die Startups "vor Ort" empfehlen.  Jeder kümmert sich um seine Aufgaben: Die Universität schafft Wissen, das Startup schafft Umsatz.

Wer also "vor Ort" wirken will, soll Firmengründungen unterstützen – zum einen durch Fördergelder, vor allem aber durch das Schaffen von Strukturen, die das Gründen vereinfachen.  Dazu gehören Anlaufstellen für Beratung und Information; Netzwerke und Veranstaltungen zum Finden von Mentoren, Mitstreitern und Investoren; bezahlbare Firmensitze in Uni-Nähe; und generelles Werben für die Fortführung der eigenen Ideen in einer eigenen Firma.  Spezielle Kurse für Firmengründer.  Mix-and-Match-Veranstaltungen zwischen Forschern und Betriebswirtschaftlern. Treffen mit erfolgreichen Gründern.  Macht Eure eigene Firma auf – und tut was "vor Ort"!



Eine Universität soll gründen, statt sich selbst als Firma aufzuspielen.  Wenn sich dieser Gedanke in den Hochschulleitungen durchsetzt, werden zukünftige Bewerber vielleicht gefragt, ob und wie sie helfen können, Firmengründungen zu unterstützen.  Und das wäre nicht das schlechteste.


Andreas Zeller ist seit 2001 Professor für Softwaretechnik an der Universität des Saarlandes, einer EXIST-Gründerhochschule in Saarbrücken.  Seine mehrfach ausgezeichneten Test- und Analyseverfahren werden in zahlreichen Unternehmen eingesetzt.  Die von ihm 2013 mitbegründete Testfabrik AG, ein Startup zum automatischen Testen von Web-Anwendungen, siegte 2014 im Europäischen Ideenwettbewerb für Startups.  

Die Firmengründung wurde durch den Gründer-Campus Saar an der Universität des Saarlandes unterstützt und durch einen EXIST-Forschungstransfer mitfinanziert.  Die Firma sitzt derzeit in einem der drei Starterzentren der Universität.  Neue IT-Gründungen profitieren zudem vom IT Inkubator der Max-Planck-Gesellschaft und der Universität des Saarlandes.



2014-07-07

This day in my history: The 1974 World Cup Final as seen from Beirut, Lebanon

Today exactly 40 years ago, on May 7, 1974, my family and I watched the Football World Cup Final between Netherlands and West Germany on a tiny TV in Beirut, Lebanon.  1974 was the last year before the civil war broke out, and Beirut was still a wonderful post-colonial middle-east city with clear Western (and mostly French) influence; it also was a major tourist destination for Westeners.  I remember Beirut as chic, white and golden, the Beeqaa Valley as green and incredibly fertile, and the Roman temples of Baalbek as white and green – it was about the first time my then nine-year old self fully realized the beauty of landscapes and architecture.  All the charms and beauty of Beirut would get lost in the 16 years of civil war that would ignite only a few months later, and well-armed soldiers on every major crossing were a sign of things to come.

How would we get to Beirut, you may ask?  At the time, my father was a German teacher in Bangui, Central African Republic, and we lived there in a nice house with a lavish garden; every Summer, we would return to Europe, though, and on some of these return trips, we would include stopovers in locations on the way.  At the time, the Western and Eastern blocks were still fighting for dominance in Africa, and consequently, the Central African Republic was well-connected – both by Western Airlines (UTA and Air Afrique), as well by Soviet Airlines (Aeroflot).  With Aeroflot being cheaper than the others, we would use the saved money for stopovers, which is how we ended up for short trips to Moscow, Russia; Cairo, Egypt; and, in 1974, Beirut, Lebanon.

The flight crew and us were in the same hotel, and my father and the crew had already made acquaintances during the trip from Africa.  It turned out that this very day was the finals of the 1974 Soccer World Cup in Munich, with the Netherlands playing against West Germany.  The crew also knew that we were Germans – and one of their rooms had a TV!  So at breakfast in the restaurant, they approached us and told us that they wanted to watch the finals later today.  Would we like to join them?  Of course, my parents gladly accepted.

So my sister and I found ourselves in a stuffy Beirut hotel room with our parents and a Russian flight crew, in front of a tiny, blurry, black and white TV screen with the audio in a language I did not understand (Arabic? Russian?).  It was even hard to distinguish the teams, although the light grey team seemed to be the Germans, and the darker grey team seemed to be the Dutch.  And I occasionally got the words "Beckenbauer" and "Cruyff", whom I identified as the main protagonists of their respective teams.  On every goal shot, vodka bottles were passed, and the crew's eyes got more and more watery.  The game lasted for 90 minutes, and at the end, the Germans won.

At this time, I was a nine-year old boy, and you might think I would have been super enthusiastic about watching the World Cup Final, captured by the game, and knowing each single player in the team.  Unfortunately, this wasn't the case.  Having spent the past year in Africa, I knew nothing about German football, its teams, or its players; nor did I know how the world cup went so far.  All the news we had were a weekly news magazine, Der Spiegel, which normally would arrive one to three weeks late; occasional short-wave radio news; and French Newsreels, to be shown in the local cinemas.

Still, I was glued to the screen, like my parents, like the crew with their wide open, bright blue eyes.  But in this moment, what I found thrilling was not so much that Germany was just about to win the World Cup.  It also wasn't that I was in a hotel room in Beirut with a bunch of Russians on my way back from Africa.  It was that I was looking at real live TV.

2014-07-02

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.

2014-05-13

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).

2014-01-20

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...)