Bonn, das universitäre Bundesdorf am Rhein

Im Herbst 1952 begann ich das Studium der Geodäsie in Bonn. Das Fachgebiet war mir vorher als Vermessungstechnik geläufig. So heißt es auch an allen technischen Hochschulen und Fachhochschulen. Hätte ich an der Technischen Hochschule in Aachen begonnen, hätte ich nach dem Vordiplom wechseln müssen. In Bonn ist die Geodäsie in der landwirtschaftlichen Fakultät der Universität angesiedelt. Diese ging aus der ehemaligen Landwirtschaftlichen Hochschule Poppelsdorf hervor. Eine ‚richtige‘ Universität hat auch etwas für sich – so dachte ich. Außerdem ist Bonn ja Bundeshauptstadt.

Mein Trierer Kommilitone und ich fanden unser erstes Zimmer in Endenich. Das war damals ein Dorf südwestlich von Bonn. Man konnte von dort gut zu Fuß die zwei Kilometer nach Poppelsdorf laufen, zur Not gab es ja Fahrräder. Bereits im dritten Semester zogen wir um. Inzwischen kannten wir den Markt besser. Wir bezogen eine Zweizimmerwohnung, nur 100 Meter vom Poppelsdorfer Schloss entfernt. Ich habe nur die allerbesten Erinnerungen an unsere damalige Lebens- und Haushaltsführung. Alles was ich kaufen musste, waren Brot und Getränke. Ich hatte von zuhause den allerbesten Schinken, sowie Gläser und Dosen mit Wurst, Fleisch, Butter und Marmelade. Mittags und manchmal auch abends gingen wir in die Mensa zum Essen. Mein Freund aus Trier brachte weniger Lebensmittel von zuhause mit als ich, dafür aber mehrere Flaschen Zeltinger Himmelreich oder Ürziger Schwarzley. Seine Mutter stammte nämlich aus Zeltingen und besaß eigene Weinstöcke in den allerbesten Lagen. Das Geodätische Institut der Uni Bonn liegt direkt gegenüber vom Poppeldorfer Schloss und war im Stil eines Renaissance-Palastes vor etwa 100 Jahren errichtet worden. Das Vorbild soll der Palazzo Strozzi in Florenz gewesen sein.
 

Geodätisches Institut in Bonn

Das Geodäsie-Studium hatte einen festen Rahmen. Etwa 25 Studenten, die im selben Semester begonnen hatten, trafen sich immer wieder bei denselben Vorlesungen. Die Kernfächer waren Landvermessung, Kartografie und Erdmessung. Zu alle Vorlesungen gab es praktische Übungen. Neben dem Messen waren Rechnen und Zeichnen die Grundtechniken, an denen niemand vorbeikam. Für die Landmessung gab es eigene Gelände, in denen Generationen von Studenten jeden Winkel und jede Strecke x-mal vermessen hatten. Diese Messübungen förderten unter anderem eine gewisse Team-Bildung. Für die Erdmessung kamen neben trigonometrischen Verfahren auch gravimetrische Methoden zum Einsatz. Unser Lehrkörper setzte sich zusammen aus überzeugten Geometern, bei denen man zum Teil ihre preußische Offiziersausbildung noch erahnen konnte, aus Mathematikern und Physikern, und aus Lehrbeauftragten von Landes- und Bundesbehörden. Besondere Beachtung erhielt ein Leitender Ministerialdirektor aus Düsseldorf. Ihm unterstanden alle Vermessungsbeamten in Nordrhein-Westfalen. Er schien auch für das Wohl der geodätischen Institute in Bonn und Aachen verantwortlich gewesen zu sein, weshalb er schon Mal als ‚graue Eminenz‘ tituliert wurde.

Das Studium bis zum Vordiplom entsprach einem typischen Ingenieur-Studiengang. Über alle vier Semester zogen sich die Vorlesungen zur praktischen Mathematik. Diese wurden auch von Physikern und Chemikern besucht. Leute, die von einem humanistischen Gymnasium kamen, taten sich spätestens bei partiellen Differenzgleichungen ziemlich schwer. Meine Leistungen reichten aus, um in den Übungen als ‚Hilfsbremser‘ mitzuwirken, d.h. ich durfte die Arbeiten von Chemikern und Physikern korrigieren. Die Technische Mechanik dagegen zog bei allen die Noten im Vordiplom nach unten. Die Photogrammetrie, also die Luftbildmessung, war ein Spezialfach und technisch anspruchsvoll.

Geradezu erholsam waren die Vorlesungen, die uns betriebswirtschaftliche und juristische Grundkenntnisse vermitteln sollten. Noch übertroffen wurden sie von Pflichtvorlesungen in Geografie, genauer in Geomorphologie, und in Städte- bzw. Landschaftsplanung. Einen relativ hohen Stellenwert hatte damals das Studium Generale. Unvergesslich sind hier Theodor Litts philosophische und pädagogische Aperçus und Heinrich Lützelers Einführung in die Philosophie des Kölner Humors. Mein Studienverlauf wich von der Norm erheblich ab, da ich nach dem sechsten Semester in den Genuss eines Auslandaufenthalts kam. Ehe ich darauf eingehe, möchte ich noch auf den Teil des Studentenlebens eingehen, der nichts mit dem Vermessungswesen zu tun hat. Dieser Teil spielte auch deshalb eine besondere Rolle, weil ich glaube, dass die Studienzeit sich nicht allein auf die fachliche Qualifizierung beschränken darf.

Die Stadt Bonn erstand als römisches Legionslager nach der Varus-Schlacht, also im ersten Jahrhundert nach Christus. Ab dem 16. Jahrhundert residierte hier der Kölner Bischof und Kurfürst, da die Kölner Bürger ihn am Betreten Kölns hinderten. Nach 1815, also nach dem Anschluss der Rheinprovinz an Preußen, wurde Bonn Garnisonsstadt. Nach dem Zweiten Weltkrieg wurde Bonn auf Betreiben Konrad Adenauers provisorische Hauptstadt der Bundesrepublik und blieb es bis 1999. Viele Nicht-Bonner pflegten vom 'Bundesdorf' zu sprechen, weil es im Gegensatz zu Düsseldorf, Frankfurt und Berlin seinen Charme als Kleinstadt bewahren konnte. Zum Teil entstand dieser Eindruck auch dadurch, dass sich in der Innenstadt kaum Regierungsgebäude befanden. Abgesehen von früheren Kasernen belegte die Regierung ein Neubauviertel am Rheinufer südlich der Stadt. Im Stadtbild Bonns fielen die Studenten mehr auf als die Staatskarossen. Die Universität bestand bereits seit 1786, also vor dem Einmarsch der französischen Revolutionstruppen. Nach den Befreiungskriegen, zu denen der Bonner Ernst Moritz Arndt einen intellektuellen Beitrag leistete, haben die Preußen sie wiederbelebt. An den berühmtesten Bürger der Stadt. Ludwig van Beethooven, erinnert dessen Geburtshaus, mitten in der Bonner Altstadt.

Das Studentenleben Bonns drehte sich um die Mensa. Hier traf man täglich seine Kommilitonen aus allen Fachrichtungen. Von Poppelsdorf war es ein halbstündiger Fußmarsch, bei dem man die Bahnstrecke Köln-Koblenz, die die Innenstadt zweiteilt, an einer Schranke überquerte. Da Bonn geografisch am Ende der Kölner Bucht liegt, wo sich die vom Atlantik eintreffenden Tiefdruckgebiete besonders stark bemerkbar machen, wurde Bonn schon mal mit dem despektierlichen Satz charakterisiert: ‘Entweder es regnet oder die Schranken sind zu‘. Das Hauptgebäude der Universität, das frühere Kurfürstliche Schloss, ist das dominierende Gebäude der Stadt. Eine 50 Meter breite Allee stellt die Blickverbindung her mit dem Poppelsdorfer Schloss, der Sommerresidenz des Kurfürsten. Obwohl die Generation der Kriegsteilnehmer, zu erkennen an abgetragenen Militärmänteln, die Universität noch nicht ganz verlassen hatte, überwogen die jüngeren Semester. In manchen Fachgebieten war der Frauenanteil sehr gering oder gar gleich Null, wie in der Geodäsie.

Noch etwas schüchtern wagten sich die ersten Korporationsstudenten in die Öffentlichkeit, zu erkennen an farbigen Brustbändern oder Mützen. Wer erkannt wurde, lief Gefahr von der Universität verwiesen zu werden. Ich selbst wurde im zweiten Semester Mitglied einer nicht-farbentragenden, katholischen Verbindung. Aufmerksam gemacht auf sie (und natürlich geworben) wurde ich durch einen Bonner Professor für Volkskunde, der aus meinem Heimatdorf stammte. Das Zusammensein unter Gleichaltrigen und Gleichgesinnten stellte alsbald ein echtes Gegengewicht dar zu den Fachkollegen in meinem Semester. Man traf dort Agrarwissenschaftler, Chemiker, Juristen, Mediziner, Philologen und Volkswirte. Sehr interessant war auch die landsmännische Mischung. Zu dem Kern aus Eiflern und Münsteranern kamen Bayern, Saarländer und Schwaben. Man lernte ‚Alte Herren‘ kennen, die als Ärzte, Ingenieure, Juristen, Lehrer oder Pfarrer tätig waren. Nicht vermissen möchte ich die Feste (Bälle, Karnevalsveranstaltungen, Kommerse) oder die Ausflüge (Rheinschifffahrten, Siebengebirgswanderungen), die in diesem Kreise organisiert wurden.

Teilnehmer der Fronleichnamsprozession 1954

Die Stadt Bonn bemühte sich mal ihr Kleinstadt-Flair herauszustellen, mal sich weltstädtisch zu präsentieren. Auf der barocken Rathaustreppe gaben sich Marktfrauen und Karnevalsprinzen häufiger den Einstand als ausländische Staatsgäste. Als ein Diplomat sich einmal nach dem Bonner Nachtleben erkundete, soll er beschieden worden sein, dass diese Person wochentags in Köln zu erreichen sei – so kolportierten es böse Studentenzungen. Kirchliche Feiern und das Bonner Münster standen bei vielen Bürgern im Mittelpunkt des Interesses, so auch die jährliche Fronleichnamsprozession durch die ganze Stadt. Dabei waren die katholischen Korporationen natürlich vertreten.

Wie bereits angedeutet, nahm mein Studium – und sogar mein ganzes Leben – ab Sommer 1955 einen nicht vorhersehbaren Verlauf dank eines Auslandsaufenthalts. Wie es dazu kam, und wie es mein Leben beeinflusst hat, will ich in einem separaten Beitrag später erzählen. Hier nur so viel: Ich brachte im Oktober 1956 meine fertige Diplomarbeit aus den USA mit nach Bonn. Ich musste nur noch eine Reihe einzelner Prüfungen absolvieren und erhielt den Dipl.-Ing.-Titel. Meine Semesterkollegen hatten alle bereits die zweijährige Referendar-Ausbildung begonnen, da sie sich alle die Möglichkeit freihalten wollten, in den öffentlichen Dienst zu treten.

Gewählte Berufswege der Semesterkollegen

Auch wenn sie sich später als Öffentlich-bestellter Vermessungsingenieur selbständig machen wollten, benötigten sie die Assessorprüfung. Ich ging als einziger direkt nach der Diplomprüfung im November 1957 in die Industrie. Der Kontakt zu den Studienkollegen riss jedoch nicht ab. Man traf sich alle paar Jahre, das letzte Mal im Mai 2011 in Cochem an der Mosel. Einen Hinweis auf dieses Treffen gab es in diesem Blog.

Erwähnen möchte ich noch, dass ich auch während meiner Berufstätigkeit laufend Kontakte nach Bonn hatte. In der Zeit von 1972 bis 1975 war ich Mitglied des Sachverständigenkreises Informatik des Bundesministers für Forschung und Technologie (BMFT), der sich um die Einführung der Informatik an deutschen Hochschulen kümmerte. In der Zeit von 1994 bis 1997 leitete ich ein vom BMBF finanziertes Verbundprojekt (MeDoc), in dem 30 Hochschulen und 14 Verlage erste Gehversuche mit elektronischen Büchern und Zeitschriften machten. Schließlich bin ich seit 1970 Mitglied der Gesellschaft für Informatik (GI), die ihren Sitz in Bonn hat. Als zeitweises Mitglied ihres Präsidium und diverser Arbeitskreise zog es mich immer wieder nach Bonn. Die Rheinstrecke von Mainz nach Bonn ist zu meiner vertrautesten Bahnstrecke geworden.

Trier, die uralte Stadt an der Mosel

Vorbemerkung: An zehn Städte, in denen ich studiert oder gearbeitet habe, habe ich diverse Erinnerungen. Sie sind sehr unterschiedlich. Auch lassen sie sich nicht unter einem Thema zusammenhängend behandeln, etwa nur die Geschichte oder die Sehenswürdigkeiten. Eine Stadt, in der man arbeitet, erlebt man anders als eine Stadt, die man als Tourist besucht. Deshalb will ich den persönlichen Bezug nicht ganz weglassen. Mal sehen, ob ich alle zehn Städte im Rückblick schaffe.

Ich beginne mit meiner Heimatstadt Trier. Heimatstadt ist eigentlich falsch. Trier ist mit etwa 100.000 Einwohnern die Hauptstadt eines Regierungsbezirks und der Sitz eines Bischofs. Im Gegensatz zu Bitburg, der Kreisstadt, hat es Theater, Museen und viele prächtige Kirchen. Bitburg erreichte man von zuhause per Bahn in zwanzig Minuten, nach Trier dauert es eine Stunde. Das liegt daran, dass die Bahnlinie von meinem Heimatdorf Niederweis nach Trier eine große Schleife entlang der Sauer machte. Seit die Bahnlinie abgebaut wurde, fährt man nur noch per Auto die 28 km. Das geht größtenteils über die uralte Römerstraße von Trier nach Bitburg, die weiter nach Köln führt. Die geht schnurstracks über den Höhenrücken zwischen Sauer und Kyll. Von der Eifel kommend, fällt man quasi in die Stadt hinein. Steil und kurvenreich ist der Abstieg von Westen in die Stadt, entlang den roten Sandsteinfelsen. Wer schlechte Bremsen hat, begibt sich und andere in Gefahr.

 Porta Nigra – Ansicht von Norden (© Stadt Trier)

Trier brüstet sich, Deutschlands älteste Stadt zu sein. Dreizehnhundert Jahre vor Rom soll die Stadt schon bestanden haben. So steht es über einem der Stadthäuser (Lat. Ante Romam Treveris stetit annis mille trecentis. Perstet et aeterna pace fruatur). Kelten haben sie gegründet, Römer machten sie zur westlichen Hauptstadt ihres Reiches. Die Franken setzten sich um 480 fest, nachdem sie die Stadt vorher zweimal verwüstet hatten. In ihrer wechselvollen Geschichte war die Stadt und die Region oft Zankapfel zwischen Deutschland und Frankreich. Die Trierer Kirchenprovinz erhielt ihre Sonderstellung dadurch, dass sie neben Köln und Mainz einen der geistlichen Kurfürsten stellte. Ihr Bischof regierte einen Sprengel der sich weit nach Frankreich hinein ausdehnte (Metz, Toul und Verdun waren Trierer Suffraganbistümer). Das zwang den Trierer Landesherrn, sich nicht unnötig mit Frankreich zu reiben. Dafür stritt man umso öfter mit den Grafen von Luxemburg.

Meine älteste Erinnerung an Trier ist vom Sommer 1938. Es war ein Urlaub weg vom Bauernhof, der mich als 5-jährigen Jungen zum ersten Mal für eine Woche von zuhause wegbrachte. Die Gastfamilie wohnte in einem Mehrfamilienhaus in einer oberen Etage. Alles war ziemlich eng. Die zwei älteren Söhne der Familie hatten kaum Zeit für mich. Die mussten in die Schule. Der Vater war tagsüber im Büro. Ich ging daher mit der Hausfrau und dem jüngeren Sohn zum Einkaufen in die Stadt. Auch besuchten wir Zoo und Theater. Eine Erinnerung überwog alles. Ich hatte schreckliches Heimweh und war froh, als ich wieder nach Hause durfte.

Nach Trier fuhr man später hauptsächlich zum Einkaufen. Für Textilien und Haushaltsgeräte gab es eine große Auswahl. Wir Bitburger Gymnasiasten wurden schon mal nach Trier ins Theater gebracht. Da gab es Lortzings Wildschütz und Wagners Fliegenden Holländer. Die römischen Ruinen wurden bestaunt, vor allem die Porta Nigra (siehe erstes Bild), die Kaiserthermen und das Amphitheater. Auch Trierer Ärzte wurden in Anspruch genommen und Krankenhäuser besucht. Die Sprüche von Fischers Maathes, dem Trierer Original, erfreuten Kinder und Erwachsene. Am Dom rutschte man wie Maathes auf dem Domstein und ging mit zur Bischofsmesse. Die für Trier so berühmten Wallfahrten, wie die zum Hl. Rock, habe ich keine mitgemacht. Dafür fuhr ich in den 1950er Jahren mit, wenn der 1. FC Kaiserslautern bei der Eintracht Trier zu Gast war, und die Walter-Brüder sowie die Eckels und Liebrichs ihre Fußballkunst zelebrierten.

Basilika und Kurfürstliches Palais (© Städte-Infos)

Eine Kultur im anderen Sinne lernte ich kennen, als ich nach dem Abitur ein vermessungstechnisches Praktikum am Kulturamt in Trier absolvierte. Das wichtigste daran war, dass ich hier einen Studienfreund aus Trier kennenlernte, mit dem ich später in Bonn ein Zimmer teilte, und mit dem ich heute noch engen Kontakt habe. Das sechsmonatige Praktikum war für uns beide teils enttäuschend, teils amüsant. Fast hätten wir rebelliert. In den ersten Wochen, die wir im Innendienst verbrachten, waren wir einem älteren Inspektor zugeteilt, der uns die Vermessungsverordnung von 1886 auf den Tisch legte, mit der Bitte sie zu studieren. Zum Glück ging es bald darauf in den Außendienst. Unter der Aufsicht eines Obervermessungsrates arbeiteten wir etwa vier Monate lang an zwei Flurbereinigungsprojekten mit. Das eine lag an der Sauer, nicht weit von zuhause. Das andere lag an der Kyll, im nördlichen Teil des Kreises Bitburg. Wir wurden auf einem alleinliegenden Bauernhof einquartiert, dessen saftige Viehweiden und großzügige Pferdekoppeln rund um den Hof lagen. Zwei Töchter etwa in unserm Alter freuten sich über Gespräche mit den angehenden Akademikern.

Während des Studiums und während meiner Berufsjahre rückten Trier und das Trierer Land in den Hintergrund. Zwar gab es hin und wieder Kontakte zur Trierer Uni, wo ich neue Freunde und Bekannte gewann. Für die Teilnehmer einer internationalen Veranstaltung machte ich sogar den Fremdenführer. Da viele Engländer in dieser Gruppe waren, konnte ich, vor der Porta Nigra stehend, mir nicht verkneifen darauf hinzuweisen, dass von hier aus einst Britannien regiert wurde (‚From here we ruled Britannia‘). Die Stadt Trier oder die sie umgebende herrliche Talaue waren jedes Jahr mehrmals das Ziel meiner Reisen, wenn ich zum Besuch meiner Eltern und Geschwister oft von weither anreiste. Meistens kam ich im Auto mit Frau und Kindern über Hermeskeil und war stets in Hochstimmung, wenn ich über die Feller Talbrücke auf Longuich zusteuerte. Mehrmals kam ich auch das Moseltal von Traben-Trarbach und Neumagen herauf, oder von Siers und Nennig herunter. War ich allein, benutzte ich meist den Zug über Koblenz oder Saarbrücken. Bei den Autofahrten durch das Moseltal machte ich öfters Halt bei einem Winzer, um einige Flaschen Riesling einzukaufen. Der Longuicher Probstberg, aber auch die Zeller Schwarze Katz und das Zeltinger Himmelreich kamen so ins Schwabenland.

Erst im Ruhestand wurde die Stadt Trier wieder wichtig und interessant. Es begann mit einem Besuch des bischöflichen Archivs. Dort befindet sich unter anderem das Pfarrbuch meiner Heimatpfarrei. Leider enthält es nur Eintragungen ab 1704. Die Vorgängerversion sollen Marlboroughs Soldaten mitgenommen haben, als sie nach der Belagerung Triers durch mein in einem Seitental der Mosel gelegenes Heimatdorf zogen. Aus den bei diesem Besuch handschriftlich kopierten Dokumenten habe ich in den letzten 30 Jahren immer wieder zitiert. Ergänzen möchte ich, dass für meine Heimatgeschichte die Trierer Archive nur einen Teilaspekt wiedergeben. Ergiebiger war das Nationalarchiv in Luxemburg und das Landeshauptarchiv in Koblenz.

Auf Trier wurde ich durch meine Reisen und die damit verbundenen historischen Studien immer wieder gelenkt. Beispiele sind Ausonius (310-394), der Lehrmeister und spätere Konsul des Kaisers Gratian, und Honoratus (etwa 365-430), der Gründer des Klosters auf der Insel Lérin bei Cannes. Über Ausonius gibt es einen Eintrag in diesem Blog. Der Bibliothekar der Trierer Stadtbibliothek wurde zum nützlichen Helfer und zum kritischen Gutachter einiger meiner Schöpfungen. Eine Arbeit, bei der ich mich mit der Sprachgeschichte des Moselfränkischen auseinandersetzte, erhielt nicht seinen Segen. Ich konnte sie nur privat veröffentlichen. In einem anderen Falle  gelang es mir ihn auszubooten. Als ich zum ersten Mal über Honoratus schrieb, hatte dies den Tenor, als ob ich der Diözese Trier einen weiteren Heiligen andichten wollte. Der als Gutachter bestellte Theologie-Professor der Uni Trier meinte, das Ganze sei sehr interessant aber spekulativ, und lehnte ab. Ich fand anschließend eine von Laien herausgegebene Trierer Zeitschrift, die den Beitrag [1] mit geändertem Titel annahm.

Schließlich befasste ich mich mit dem nach Karl Marx umstrittensten Sohn Triers, Ludwig Kaas [2], dem ehemaligen Vorsitzenden der Zentrumspartei. Ich kam auf ihn über meinen Großonkel Matthias Neyses [3], der von 1919 bis 1933 Reichstagsabgeordneter für das Zentrum war. Kaas hat es aus zwei Gründen mit den Trierern verdorben. Er hatte Hitlers Zusagen für das Ehrenwort eines Politikers gehalten und seine Partei überredet, dem Ermächtigungsgesetz zuzustimmen. Als das damals zu Frankreich gehörende Saarland in Tholey eine frühere Benediktiner-Abtei wiederbeleben wollte, stimmte Kaas in Rom dafür, dass die Mönche von St. Matthias dorthin zogen.

Von den vielen Trierer Kirchen will ich zwei hervorheben. Die Basilika ist wirklich die ursprüngliche Palast-Aula (siehe zweites Bild), in der Ausonius im August 379 seine Lobrede auf den 20-jährigen Kaiser Gratian hielt. Vor rund hundert Jahren wurde sie ‚auf ewig´ vom preußischen König an die Protestanten Triers vermacht. In St. Matthias, früher außerhalb der Stadt gelegen (in Matheis am letzten, sagen die Eifler, wenn etwas sehr abgelegen liegt), befindet sich das zweite Apostelgrab nördlich der Alpen, und die Gräber der ersten Trierer Bischöfe Eucharius und Valerius. Sie wirkten in der Mitte des dritten Jahrhunderts. Nicht so bekannt ist die reiche Witwe Albana, die auch hier begraben liegt. In ihrem Hause trafen sich die frühen Trierer Christen. Auf einer Säule im Klosterhof befindet sich die Entfernungsangabe für die Jakobspilger. Es sind von dort noch 1395 Kilometer bis nach Santiago di Compostella.

Als Großereignis der letzten Jahre gilt die Konstantin-Ausstellung im Jahre 2007. Hiermit hatte sich das Rheinische Landesmuseum noch einmal in den Blickpunkt gerückt. Monatelang strömten Tausende durch mehrere Trierer Museen und bewunderten die vielen Hinterlassenschaften aus der Römerzeit, seien es Mosaikböden, Skulpturen, Vasen oder das Neumagener Weinschiff. Andere faszinierte die geschichtliche Rolle eines Kaisers, der zwar Trier verließ, um Konstantinopel zu gründen, der aber dem Christentum zum Durchbruch verhalf.

Zum Schluss noch ein Hinweis, nicht ganz ohne Werbeabsicht. Auch einige Trierer Buchhandlungen führen neben allen Bitburger Buchläden meine heimatkundlichen Bücher. In ihnen sind auch alle meine Veröffentlichungen, die Trier betreffen, enthalten.

Zusätzliche Referenzen:

1. Endres,A.: Das Kloster Lérin bei Cannes und sein Bezug zur Stadt Trier. Neues Trierisches Jahrbuch 2001, 221-230
2. Endres,A.: Ludwig Kaas und seine Zeit. Eine Erinnerung anlässlich seines 50. Todestages. Neues Trierisches Jahrbuch 2002, 95-109
3. Endres,A.: Matthias Neyses - Reichstagsabgeordneter und Agrarpolitiker der Weimarer Republik. Kurtrierisches Jahrbuch 1999. 427-438

Herbert Bellem über Software-Projekterfahrungen, Management-Training und Agile Methoden

Herbert Bellem war von 1981 bis 2012 in verschiedenen Funktionen in der Software-Entwicklung des IBM Labor Böblingen tätig. Er begann seine Karriere in der VSE- und MVS-Entwicklung. Als Leiter der Qualitätssicherung der Unix-Entwicklung (IX/370) stellte er die technische Verbindung her zu einer Partnerfirma in Kalifornien. Nach einem Aufenthalt in den USA übernahm er die Verantwortung für das System-Management auf MVS-Systemen. Parallel dazu koordinierte er das Management-Training. Später hatte er Verantwortungen für die Entwicklung von Programmen für das System-Management und für Finanzanwendungen. Zuletzt oblagen ihm die Entwicklerunterstützung für den Bereich Information Management. Bellem hatte in Saarbrücken Informatik studiert und bei Kurt Mehlhorn seine Diplomarbeit gemacht. Im Juli 2012 tritt er nach 31 Jahren bei derselben Firma in den Ruhestand.

Bertal Dresen (BD): Sie vertreten die erste Generation, die mit einer Ausbildung in Informatik zur IBM kam. Um sich an die Schwaben zu gewöhnen blieb Ihnen nicht viel Zeit. Gleich wurde ihre Arbeit international. Sie pflegten die Kooperation mit der Firma LOCUS in St. Monica, Kalifornien. Das Locus System des leider früh verstorbenen Jerry Popek war ein Unix, das es heute noch nicht gibt. Wie erlebten Sie Ihren Berufseinstieg? Was hat sich geändert für heutige Berufsanfänger? Was ist Ihre Erinnerung an die LOCUS-Gruppe und das LOCUS-System? Wo lag der Unterschied zur IBM als Großfirma?

Herbert Bellem (HB): Was den Berufseinstieg angeht, muss ich rückblickend sagen,  dass ich zwar von der Uni einen sehr guten theoretischen Background mitgebracht habe, was aber Programmiersprachen, Entwicklungsumgebungen und Entwicklungsprozesse angeht, habe ich doch vieles erst im Beruf gelernt. Zum Teil lag das daran, dass Rechner in meinen Studienjahren gleichzusetzen waren mit Großrechnern und damit ein knappes Gut waren, von dem man nur kleine Zeitscheiben an der Uni abbekommen konnte. Das hat sich in der Zwischenzeit dramatisch verändert: Rechenleistung ist überall zugreifbar und billig. 

Jeder Informatikstudent hat selbstverständlich einen eigenen Webauftritt und jede Menge Erfahrung in Sprachen und Entwicklungsumgebungen wie sie auch in der Industrie eingesetzt werden.  Firmen schätzen natürlich, dass Neueinstellungen so schnell produktiv sind. Was sich nicht geändert hat ist,  dass neue Mitarbeiter das aktuelle Wissen aus den Universitäten mit in die Unternehmen tragen. Das habe ich in meinen ersten Jahren erlebt und erlebe ich noch heute. 

Mit dem LOCUS-Projekt hat sich damals für mich ein erster Traum erfüllt – ich durfte mehrfach nach Kalifornien reisen und das in einem Zeitalter, wo es noch keine Billigflieger gab und Firmen ihre Mitarbeiter noch die Business Class gegönnt haben. Technisch fand ich das Projekt sehr ehrgeizig und viele Ideen finden sich heute in ‚Software as a Service‘ und in Cloud-Implementierungen. Zum damaligen Zeitpunkt war das System allen anderen weit voraus. Es fehlte aber die Robustheit und Stabilität. Ich war ja damals mit der Qualitätssicherung betraut und wurde von der dynamischen uni-nahen Startup-Mannschaft am Anfang manchmal mitleidvoll belächelt. Sie hielten sich alle für große Programmierer, die keine Fehler machen. Als unser Team dann mit automatisierten Tests und Coverage-Messungen verifizieren wollte,  dass das auch stimmt, haben sie uns anfangs noch tatkräftig unterstützt. Erst als die ersten Ergebnisse vorlagen und Qualitätsdefizite zu Tage kamen, war’s mit der Unterstützung vorbei. Letztendlich hat Jerry Popek dann doch eine eigene unabhängige Testgruppe etabliert. Ich habe in diesem Projekt viel gelernt. Zum einen, was ein kleines motiviertes Team – das waren die LOCUS-Leute – leisten kann, zum anderen aber auch, wie wichtig es ist ein ebenso motiviertes und kompetentes Team zu haben, was sich um die Qualitätssicherung kümmert.

BD: Schon bald nach Beendigung des LOCUS-Projekts verschlug es Sie nach Poughkeepsie, N.Y. Sie befassten sich dort mit Software zur Verwaltung von großen Systemen. Nach der Fusion mit der gleichnamigen Firma wurden diese Programme unter dem Namen Tivoli zusammengefasst. Sie dienen dazu, Rechner zu überwachen, Software zu verteilen, Systeme zu inventarisieren oder Daten zu sichern. Was bedeutete es für Sie, plötzlich ein Teil der Großsystemwelt (MVS, VM) zu sein? Welche Besonderheiten zeichneten diese Programme aus? Spielen sie heute noch eine Rolle?

HB: Ich habe ja im Großrechnerbereich als Programmierer angefangen und insofern war mir die Welt vertraut. Mir war aber auch klar, dass sich die Bedienung dieser Systeme dramatisch vereinfachen musste. Denn die ständig günstiger werdenden Hardwarepreise machten plötzlich die Operator, Systemprogrammierung und Administratoren zu den teuren „Ressourcen“. In meinen Anfangstagen bestanden die Systeme aus vielen Einzelkomponenten. Systemprogrammierer beim Kunden konnten und mussten sich daraus z.B. erst ein lauffähiges Betriebssystem zusammenstellen. Das überflüssig zu machen, war eines der wichtigsten Projekte zu meiner Zeit in Poughkeepsie und die Systemmanagement-Komponenten – für die ich verantwortlich war – waren ein wichtiges Element davon. Heute ist das alles zusammenpaketiert in z/OS.

In dieser Zeit begann auch das Imageproblem der Großrechner. Sie wurden von den Unix- und Windows-Fans als Dinosaurier dargestellt, in meinen Augen völlig zu unrecht. Klar gab es im Benutzerinterface noch Schnittstellen, denen man die Lochkartenzeit angesehen hat, gleichzeitig gab es schon damals auf dem Großrechner Konzepte, die erst viel später – und oft mit großem Hype – auf anderen Plattformen eingeführt wurden: Virtuelle Maschinen und Hochverfügbarkeit. Heute hat sich die Diskussion etwas versachlicht und es geht mehr um Fähigkeiten und Kosten und die Plattform rückt vor allem im Zeichen der Cloud in den Hintergrund.

BD: Später machten Sie einen fachlichen Sprung zu Anwendungen im Finanzbereich (System Merva). So viel ich verstehe, ging es dabei um Erweiterungen von WebSphere, um das SWIFT Internet Protocol Network (SIPN) zu unterstützen. Es heißt, dass Finanzler hohe Ansprüche bezüglich Sicherheit und Benutzbarkeit stellen. Wie machte sich dies für einen Entwickler bemerkbar? Was mussten Sie dazulernen, um Web-Anwendungen zu entwickeln?

HB: Merva war zu diesem Zeitpunkt ein etabliertes Programm, das von vielen Banken auf Großrechnern eingesetzt wurde, um mit dem SWIFT-Netz zu kommunizieren. SWIFT selbst hatte sich entschlossen, die Netzwerkprotokolle von X.25 auf ein modernes IP [Internet-Protokoll] umzustellen. Wir haben im deutschen Labor eng mit dem SWIFT-Konsortium, dem die wichtigsten Banken und Finanzdienstleister angehören, zusammengearbeitet und dabei nicht nur die Großrechnerlösung modernisiert, sondern auch eine UNIX-basierte Lösung mitentwickelt.

Und natürlich ist Sicherheit oberste Priorität für ein System, über das stündlich Milliarden von Euros abgewickelt werden. Hier kam uns die jahrelange Erfahrung der Mitarbeiter im Bereich Zahlungssysteme [im Böblinger Labor] zugute. Sie waren, was Sicherheitskonzepte angeht, auf der Höhe der Zeit und haben letztendlich auch SWIFT bei der Implementierung der entsprechenden Services beraten.

BD: Sie haben sich für die Einführung neuer Management-Methoden und die entsprechende Schulung engagiert. Ich erinnere mich an Wanderungen Im Tannheimer Tal in Österreich, wo wir mit verbundenen Augen durch ein Waldstück geführt wurden. Welche Auswirkungen auf das Team und seine Produkte ließen sich aufgrund dieser Schulung nachweisen? Sind die damals verkündeten Prinzipien der Teambildung und Teamführung heute noch relevant?

HB: Schon immer war ich der Überzeugung, dass es vor allem die Menschen sind, die ein gutes Entwicklungsteam ausmachen, ihr Wissen und vor allem ihre Motivation. Softwareprojekte lassen sich in meinen Augen nicht mit Operations-Research-Methoden managen, sondern brauchen vor allem ein motiviertes und funktionierendes Team. Ich habe im Laufe meiner Karriere einige Ansätze erlebt, Teams zusammenzubringen, Vertrauen ineinander zu stärken, sich auf gemeinsame Ziele zu einigen, offen zu kommunizieren und gemeinsam erfolgreich zu sein. Die Grundprinzipien und Fragestellungen haben sich meines Erachtens nicht geändert und finden sich auch bei der Agilen Entwicklung wieder.

Die „Pfadfinderspiele“ im Tannheimer Tal  ̶  auf die Sie Bezug nehmen  ̶  haben Themen wie Vertrauen in andere, Kommunikation und Verlässlichkeit in einer spielerischen Ebene vermitteln wollen. Wir waren damals eine der ersten Gruppen, die so etwas gemacht haben. Heute hat sich daraus ein ganzer Geschäftszweig von „Outdoor Teamtrainings“ entwickelt.

BD:  Zuletzt leiteten Sie eine Abteilung für Entwicklungsunterstützung. Was änderte sich im Laufe Ihrer Berufszeit, was Methoden und Werkzeuge anbetrifft, am meisten? Welche neuen Werkzeuge stellten besondere Anforderungen? Wo lagen die Probleme? Was sehen Sie als besondere Herausforderungen an, will man Entwickler optimal unterstützen?

HB: Wenn ich zurück denke an meine ersten Berufsjahre, dann kann ich es kaum glauben, wie primitiv die Entwicklungswerkzeuge damals waren: „Dumme“ Terminals dienten der Eingabe der Programme, Editoren hatten keinerlei kontextsensitive Hilfen, Compiler waren separate Werkzeuge. Komponenten und Komplettsysteme wurden zum ersten Mal als Ganzes zusammengebaut, wenn mehr als die Hälfte der Entwicklungszeit um war. Testen war eine weitgehend manuelle Angelegenheit und Projektmanagement fand mit handgemalten Charts statt. Und vielleicht der größte Unterschied: Entwicklungsteams arbeiteten im Wesentlichen an einem Standort.

Das sieht heute dramatisch anders aus: Nahezu alle Entwicklungsprojekte arbeiten mit internationalen Teams, verteilt über mehrere Zeitzonen. Integrierte Entwicklungsumgebungen, wie z.B. die Jazz-Plattform von IBM, unterstützen Entwickler, Tester und Projektmanager vom Requirements Management über Implementierung, Test, Integration und Driver-Bau bis hin zum Projektmanagement mit einem hohen Grad an Komfort und mit jeder Menge Hilfestellungen. Jeder bekommt zu jedem Zeitpunkt die Information, die er braucht, und am Ende eines Projektes weiß ich z.B. genau, welches Requirement durch welchen Code implementiert wurde, wie hoch der Aufwand dafür war, welche Testabdeckung ich dafür erreicht habe, welche und wie viele Fehler ich dabei gefunden und behoben habe. Das heißt auch, dass die Arbeit heute wesentlich transparenter geworden ist, was für manche Kolleginnen und Kollegen gewöhnungsbedürftig war und ist. Die Zeiten, als sich Programmierer noch als Künstler fühlten, sind vorbei. Software-Entwickler sind heute eher Ingenieure.

Wie unterstützt man Entwickler optimal? Indem man ihnen solche Umgebungen zur Verfügung stellt, also Umgebungen, die Hilfestellungen geben, aber auch Flexibilität erlauben, möglichst die Prozesse und Werkzeuge einzusetzen, mit denen sich das Gesamt-Team wohl fühlt.

BD: Sie waren auch ‚Evangelist‘ für Agile Methoden (z.B. Scrum). Ich habe den Verdacht, dass sich die Entwickler freuten, dass sie endlich ohne Planung loslegen konnten und keine Zeit mehr für Dokumentation draufging. Stimmt das? Welche Art von Projekten profitieren von Agilen Methoden? Wie groß ist deren Anteil im Labor? Was sind die harten Fakten, die man als Entwickler und Manager nicht außer Acht lassen sollte (also Dinge, die wir seinerzeit nicht wussten)?

HB: Agile Methoden haben sich zumindest in der Softwareentwicklung in den letzten Jahren weitgehend durchgesetzt. Ja, Sie haben recht: anfänglich hat schon der ein oder andere Entwickler gedacht, dass damit Prozesse und Dokumentation hinfällig sind. Um dieser Fehlinterpretation entgegenzuwirken, hat IBM deshalb seine Implementierung von Agilen Methoden bewusst auch ‚Disciplined Agile Development‘ genannt.

Für mich adressiert dieser Ansatz viele Fragestellungen, die wir eigentlich schon immer hatten, die sich aber in den letzten Jahren noch verstärkt haben: Wie entwickele ich genau das, was meine Kunden brauchen – und nicht mehr? Wie mache ich das effektiv und in hoher Qualität? Wie kann ich in jeder Projektphase noch auf neue  oder geänderte Anforderungen reagieren, ohne Endtermin, Aufwand und Qualität zu kompromittieren? Und nicht zuletzt: Wie sorge ich für eine optimale Einbindung und Kommunikation des Teams?

Viele Methoden und Techniken, die dabei zum Einsatz kommen, hätte man schon früher anwenden können z.B. Scrum Meetings, das Aufbrechen der Anforderungen in kleine Einheiten, die aus Benutzersicht formuliert sind, zeitlich fest terminierte, kurze Iterationen, an deren Ende das Ergebnis demonstriert wird. Andere sind meines Erachtens erst durch moderne Entwicklungsumgebungen möglich geworden, in denen hochgradig automatisierte Tests ablaufen und quasi jederzeit eine aktuelle Version der Software gebaut werden kann und auch wird. Auch das Entwickeln in weltweit verteilten Teams über mehrere Zeitzonen hinweg ist durch diese Tools und die heutigen schnellen Kommunikationsleitungen erst möglich geworden.

BD: Ihre Familie wohnt in Darmsheim, einem Stadtteil von Sindelfingen. Wie ich kürzlich las, sind sie Mitglied des Kirchengemeinderates der katholischen Pfarrei Dagersheim-Darmsheim. Was kann man als erfahrener Manager zu diesem Gremium beitragen? Gibt es ein nicht-fachliches Thema, dem Sie in der Nach-IBM-Zeit verstärkte Aufmerksamkeit widmen wollen? Was haben Sie in den 30 Jahren Ihres Berufslebens fürs Leben gelernt, auf das Sie nicht verzichten möchten?

HB: Ja meine Frau und ich fühlen uns heute im Schwabenland heimisch. Unsere drei Kinder fühlen sich genauso wohl, sind aber in der Zwischenzeit nach Bayern und in die Pfalz – für Saarländer eigentlich ein Unding  ̶  ausgewandert. Wir sind beide im Dorf aktiv. So bin ich seit über 12 Jahren im Kirchengemeinderat. Ja, in solchen Gremien profitiere ich sehr von meinen IBM-Erfahrungen: Strukturen zu verschlanken, effektiv Sitzungen zu leiten, Teams zu motivieren. Die Themen unterscheiden sich nicht sehr von der beruflichen Arbeit, nur dass man es mit Freiwilligen zu tun hat, die jederzeit nein sagen können.

Was habe ich gelernt? Ich denke sehr vieles, und vor allem, dass das Lernen nie aufhören darf. Wenn ich eine Sache herausheben soll, dann ist es die Erkenntnis,  dass für erfolgreiche Arbeiten und Projekte die Menschen und ihre Motivation das wichtigste sind.

BD: Herr Bellem, vielen Dank für das interessante Interview und herzlich willkommen in der Rentnerwelt. Bleiben Sie Ihrem Kirchengemeinderat auch bitte weiterhin treu.

Software-Entwickler gesucht – die deutschen Besonderheiten

In diesem Blog habe ich mich bereits mehrere Male mit dem Thema Programmierer-Mangel beschäftigt. Durch Wiederholung erhöhe ich vielleicht die Aufmerksamkeit der Leser, also die pädagogische Wirkung meiner Worte. Es geht hier zwar um ein internationales Problem, das in allen Industrie- und Schwellenländern (z.B. den BRICS-Staaten) besteht. Es gibt aber einige deutsche Besonderheiten. Ich wähle bewusst diesen neutralen Ausdruck. Mit ihm kann man sowohl Stärken wie Schwächen bezeichnen. Auf keinen Fall möchte ich den Eindruck erwecken, dass ich bei uns alles als schlecht ansehe, und dass ich glaube, dass anderswo alles besser ist. Anderswo bedeutet im Falle der Informatik in der Regel die USA. Ihre Überlegenheit bezüglich produktmäßiger Erfolge auf dem Gebiet der Software kann niemand leugnen. Aber einige Weltmarktführer haben wir auch.

In dem Beitrag von August 2011 setzte ich mich mit den Bedarfsschätzungen auseinander, aber auch mit der Frage, was man der Industrie raten kann. So überspitzt, wie ich es mir vorher nicht zugetraut hatte, schrieb ich:

Eine Branche, in der Fachkräftemangel herrscht, wird dazu tendieren, die Aufwendungen für Dienstleistungen auf das Allernötigste zu reduzieren. Manchmal frage ich mich, warum so viele Informatikerinnen und Informatiker in diesem Punkte so uneinsichtig sind. In emotionaler Voreingenommenheit werden Produktentwickler meist verteufelt. Das Heil wird in der durch Personen erbrachten Dienstleistung gesucht, d.h. in der konsumartigen Verschwendung von geistiger Leistung.

Das ist in der Tat die erste der deutschen Besonderheiten, ja, eine große Schwäche unseres Wirtschaftsstandorts. Warum ist dies so? Es ist in erster Linie die Informatik-Industrie – soweit es sie bei uns gibt –, die hier versagt. Sie denkt immer nur kurzfristig. Heute hat sie zu wenige Leute, morgen sind es wieder zu viele. Für die Planung der Produkte und Dienste fühlt man sich zuständig, nicht jedoch für die Planung des Personals. Da beschränkt man sich aufs Fordern. Die Politik möge es richten. Mal bietet die Politik Grüne Karten als die Lösung, mal längere Aufenthalte für ausländische Absolventen, mal die Verlängerung der Lebensarbeitszeit. Als langfristige Maßnahme versucht man die demografische Entwicklung zu beeinflussen.

Hier geht es aber nicht nur um das Kräftespiel zwischen Politik und Wirtschaft, wobei man auch von Spielchen reden könnte. Irgendwo liegt auch ein Mentalitätsproblem. Dafür habe ich zurzeit keine bessere Erklärung, als auf unser Bildungssystem zu verweisen. Als Ingenieur beobachte ich, dass die Ausbildung von Informatikern sich sehr an den Geisteswissenschaften orientiert. Die starke Präsenz von Mathematikern auf Informatik-Lehrstühlen ist ein Indiz dafür. Nicht nur Philosophen sondern auch Künstler sind stolz, wenn sie es schaffen, andere Leute anzuregen, ihnen nachzufolgen, also auch Philosoph oder Künstler zu werden. Eine Firma oder Behörde, die einen Psychologen anstellt, wird die Erfahrung machen, dass sie bald einen Bedarf für mehr Psychologen hat. Geisteswissenschaftler sind gut, wenn sie sich vermehren bzw. ausbreiten. Ingenieure dagegen wollen den Bedarf an Ingenieuren reduzieren, indem sie alle möglichen Dinge automatisieren. Sie möchten sich und ihre Kollegen wegrationalisieren.

Ursache und Wirkung zeigen sich gleichzeitig in der Struktur unseres Informatik-Marktes. Wenn ich mal von SAP absehe, deren Domäne die kaufmännischen Anwendungen sind, frage ich mich manchmal: Warum kauft die ganze alle Welt ihre Werkzeugmaschinen in Deutschland, aber kein einziges Software-Werkzeug? Meine Antwort: Weil wir nicht gelernt haben, Software-Entwicklung als Ingenieurtätigkeit zu betreiben! Wir lernen es nicht, weil es nicht anerkannt wird. Wir schreiben lieber Fachartikel in schlechtem Englisch als Code in Vulgärsprachen. Solche Sprachen sind C++, C#, ABAP und Visual Basic. Außerdem müsste man Programme, die andere Leute nutzen sollen, gründlich testen und pflegen. Man hat dann weniger Zeit, neuen Ideen nachzuhängen. Schön wäre es, man hätte überhaupt Ideen, die zu etwas taugen. Dann würde man sie schützen wollen, also patentieren. Das wird unsern jungen Leuten jedoch als geistige Schwäche verkauft. Ideen schützen, wer tut schon so etwas Perverses? Vielleicht so alte Industrien wie der Maschinenbau und die Pharmazie. Aber bald werden die Piraten auch diesen Rest entrümpelt haben.

Über die Versuche, Software-Ingenieurwesen als Studienrichtung zu etablieren, ging es im Interview mit Jochen Ludewig im Oktober 2011. Trotz seines großen persönlichen Engagements hat das Stuttgarter Modell keine Nachahmer gefunden. Ich persönlich bin 100% für Ludewigs Ausbildungsinhalte, nur halte ich wenig davon, die Informatik in immer kleinere Herzogtümer (sprich Studiengänge) aufzuteilen. Ich nannte das Balkanisierung. Die Profilierung eines Lehrstuhls führt sehr leicht dazu, dass alle andern Kollegen in Opposition gehen und auf Gegenaktionen sinnen. Wenn Lehrstuhl A seine Spezialität zum Studienfach hochjubeln kann, warum nicht auch Lehrstuhl B. So entstehen aus einem Fach, das man gut abdecken konnte, leicht fünf Fächer, die man nur noch mühsam abdecken kann. Leidtragende sind die Studenten und deren spätere Arbeitgeber. Mir wurde gesagt, dass Stuttgart als Reaktion auf Ludewigs Initiative jetzt weitere Studiengänge anbieten will. Dafür fordert man natürlich zusätzliche Professorenstellen. Schon heißt es wieder: Die Politik soll es richten! Ich hoffe, dass unsere Landespolitiker nicht so dumm sind, wie man glaubt, und dass sie das Spiel durchschauen.

Auf eine weitere Besonderheit verwies ich in einem Beitrag im April 2012. Darin wurden  zunächst Positionen von zwei prominenten Kollegen, Dave Parnas und Manfred Broy, wiedergegeben und kommentiert. Ich wies darauf hin, dass trotz der kritischen Haltung von Parnas und anderen, der US-Arbeitsmarkt den Software-Ingenieur voll akzeptiert hat. In einem Nachtrag zu demselben Beitrag zitierte ich die Stellenangebote einer einzelnen deutschen Jobbörse (StellenMarkt.de). Von etwa 7400 offenen Stellen waren rund 2300 für Software-Entwickler und über 1400 für SAP-Spezialisten, Insgesamt wurden jedoch nur 400 Informatiker und 40 Software-Ingenieure gesucht. Interessant ist, dass in 95% der Angebote Kenntnisse in Informatik gewünscht sind.

Die Kollegen, die heute für die Ausbildung von Software-Entwicklern verantwortlich sind, haben alle Hände voll zu tun. Früher wirkten hier ausschließlich private Firmen. Längst hat sich das öffentlich finanzierte Bildungssystem dieses Massengeschäfts angenommen. Für die so genannten Kunden, d.h. junge Menschen, gibt es in vielen Bundesländern die Berufsausbildung in Informatik sogar umsonst. Bei etwas, das es umsonst gibt, fragt man nicht, ob es so gut ist, wie es sein sollte oder sein könnte. Außerdem ist es nicht Sache der Studierenden ihre Qualifikationsanforderungen zu bestimmen, sondern die Abnehmer (die wahren Kunden) und ihre Fachverbände sollten sich darum kümmern.

Es ist mein Eindruck, dass die von mir festgestellten deutschen Besonderheiten kaum jemanden interessieren. Zumindest scheint dies für die vom Staat festangestellten Ausbilder zu gelten. Für sie sind das doch nur Nebensächlichkeiten. Die Maßstäbe, mit denen sie gemessen werden, sind andere. Einerseits ist man nur dann exzellent, wenn man viel Geld für Forschung einwirbt. Andererseits kann die deutsche Informatikausbildung nicht anders als gut sein. Da wo so viele Studenten sind, kann doch nichts schlecht sein. Ich wette, die Studentenzahlen wären nicht ein Deut geringer, würde man heute noch 100% der Ausbildung in Algol 60 oder Pascal machen. Und Studentinnen soll man auch noch am Stoff interessieren. Das geht wirklich zu weit.

Leider sind es nicht die deutschen Professoren, die darunter zu leiden haben, wenn etwas in der Ausbildung schief läuft, sondern alle diejenigen Absolventen, die nicht eine Hochschul-Karriere machen wollen. Diese sind (zum Glück) noch in der Mehrzahl. Aber wer redet schon von denen oder mit denen. Die GI kann es und will es nicht. BITKOM ist zwar besser, aber oft überfordert. Man ist Teil der Wirtschaft und handelt oft wie diese (siehe oben).

Während ich mich zunächst darum bemühe, unsere Situation zu verstehen und zu erklären, erlaube ich es mir hin und wieder etwas aufzurütteln. Wer das als Provokation empfindet, mag sich fragen, ob die trügerische Ruhe wirklich das kleinere Übel ist. Meinen Blog muss man ja nicht lesen. Erst recht nicht als GI-Mitglied.

Walter Tichy über empirische Software-Forschung und Parallelismus

Walter F. Tichy (Jahrgang 1952) ist seit 1986 Professor am Karlsruher Institut für Technologie (KIT), der früheren TH Karlsruhe. Er ist Mitglied der kollegialen Leitung des Instituts für Programmstrukturen und Datenorganisation (IPD). Seine Arbeitsgebiete sind empirische Softwaretechnik, Konfigurationskontrolle,  paralleles Rechnen und Sprachverarbeitung in der Softwaretechnik. Im Forschungszentrum Informatik (FZI) leitete er u.a. das von der Firma SUN autorisierte Java Center. Bevor er den Ruf nach Karlsruhe annahm, war er Senior Scientist bei der Carnegie Group, Inc., in Pittsburgh, PA, und Assistenzprofessor an der Purdue University in West Lafayette, IN. Er ist in Fachkreisen bekannt als der erste Entwickler eines Software-Versionsverwaltungssystems  (RCS). Mehrere seiner Fachbeiträge erregten weltweites Aufsehen. Nebenbei übt Tichy eine intensive Beratertätigkeit in der Industrie aus. Nach dem Studium der Informatik an der TU München (1974) absolvierte Tichy ein Masterprogramm an der Carnegie Mellon University (CMU) in Pittsburgh (1976) und erlangte dort 1980 den Ph.D. 

Bertal Dresen (BD): Als ich Sie das letzte Mal bei einer Veranstaltung Ihres Instituts besuchte, war ich überrascht, welche dedizierte Meinung Sie bezüglich gewisser Software-Produkte und ihrer Hersteller äußerten. Das passte eigentlich nicht zu dem Bild, das man sich in Deutschland allgemein von einem Universitätsprofessor macht. Hängt das mit Ihren ‚Lehrjahren‘ in Amerika zusammen? Sollten Ausbilder in technischen Fächern verfolgen, was in der Praxis geschieht? Wie weit dürfen Akademiker sich zu Fürsprechern bestimmter im Markt vertretener Produkte oder Methoden machen?

Walter Tichy (WT): Zunächst hat jedermann Meinungs- und Redefreiheit, auch Professoren. Während Universitäten gut beraten sind, sich neutral zu verhalten, müssen sich Professoren nicht unbedingt zurückhalten. Im Gegenteil! Manchmal müssen sie unangenehme Wahrheiten aussprechen. Insbesondere dürfen sie die Tauglichkeit von Produkten und Methoden wissenschaftlich vergleichen und die Ergebnisse publizieren. Dahinter steckt dann natürlich eine ganze Menge Arbeit und mehr als nur eine Meinung.

Selbstverständlich verfolge ich die Entwicklungen in der Praxis, denn mein Fachgebiet, die Softwaretechnik, wird in Lehre und Forschung wesentlich von Entwicklungen in der Industrie beeinflusst. Das hat mit meinen Lehrjahren weniger zu tun als mit meinem Anspruch, zeitgemäße Lehre und international beachtete Forschung zu leisten. Diesem Anspruch gerecht zu werden, sollte Ziel jedes Wissenschaftlers sein, egal wo er auf der Welt arbeitet.

Stellen Sie sich vor, ich würde noch in der Sprache Pascal von 1970 ausbilden, anstatt in einer modernen Sprache. Programmiersprachen werden aber heute hauptsächlich von Firmen definiert. Oder denken Sie an die agilen Methoden  ̶  hier muss ich leider feststellen, dass inzwischen zahlreiche wissenschaftliche Untersuchungen belegen, dass die viel gepriesenen Methoden Paarprogrammierung und testgetriebene Entwicklung nicht besser sind als traditionelle Methoden. Diese Erkenntnis ist natürlich unangenehm für Leute, die diese Methoden propagieren, aber ganz wichtig für die Praktiker.

BD: Die Softwaretechnik an den Hochschulen (das, was wir mit dem englischen Ausdruck ‚Software Engineering‘ meinen) scheint immer noch um ihr Selbstverständnis zu ringen. Dabei dauert die Diskussion schon über 40 Jahre, nämlich seit der Garmischer Tagung von 1968. Liegt das Problem darin, dass unsere Studenten die Mathematik nicht mögen (die Durchfallquoten sollen sehr hoch sein) oder fehlt es an der pädagogisch richtigen Darbietung von praktischem Wissen?

WT: Ich weiß nicht, wie Sie darauf kommen, dass Softwaretechnik um Selbstverständnis ringt. Sicher nicht bei den Firmen, die unsere Absolventen einstellen, und das ist was bei unseren Studierenden zählt. Hier einige Beispiele zum Bedarf an Softwareentwicklern: Am heutigen Montag bekam ich eine neue Stellenanzeige eines großen Rekrutierungsunternehmens. Das hatte mich schon in der letzten beiden Wochen angeschrieben, aber mit anderen Angeboten. Letzten Donnerstag und Freitag fand vor meinem Büro eine Veranstaltung einer bekannten Beratungsfirma statt. Alle Angebote richten sich an Softwaretechniker. Sogar Leiter für Software-Entwicklung in Indien wurden gesucht.

In der gleichen Woche kam auch noch ein Angebot einer weiteren Vermittlungsfirma, die Interviews in mehreren Großstädten anbot. Außerdem erhielt ich einen Brief der Bonding-Messe mit der Bitte, ich solle die Veranstaltung in meinen Vorlesungen ankündigen. Die Woche davor bekam ich ein Schreiben einer Firma, die in meiner Vorlesung eine Firmenpräsentation geben möchten, und, wenn ich wollte, auch gleich die ganze Vorlesung halten würde. Tatsächlich könnte ich in jeder Vorlesung einen ganzen Firmenwerbeblock einbauen! In der gleichen Woche erhielt ich auch noch das Angebot eines ehemaligen Habilitanden, der eine komplette Lehrveranstaltung für mich halten möchte (das ganze Wintersemester), nur um Kontakte zu knüpfen. Das Angebot war durchaus ernst gemeint, da er diese Vorlesung während seiner Zeit am KIT schon gehalten hatte. Mindestens zwei Anfragen pro Woche bzgl. Absolventen  ̶  so geht das nun schon seit Jahresanfang.

Der Mangel an Softwareentwicklern ist wieder fast so groß wie zu Zeiten der Dot-Com-Blase. Die Angebote, Studierende nach Mallorca zu Firmenpräsentationen zu locken, werden wohl bald wieder auftauchen. Von mangelnder Akzeptanz kann keine Rede sein. Auch am KIT selber nicht. Diejenigen, die der aufstrebenden Informatik eventuell kritisch gegenüber standen, sind inzwischen pensioniert. (Die Informatik am KIT wird dieses Jahr 40, und das ist länger als die übliche Professorenlaufbahn). Für die Kollegen von heute war die Informatik bereits vor ihnen da. Der Mangel an Software-Kompetenz ist diesen Kollegen durchaus bewusst und eher peinlich. Wenn man aber das jüngste Ergebnis der Exzellenzinitiative betrachtet, von der nur an einem einzigen Standort ein Informatik-Cluster gefördert wird, könnte man durchaus zu dem Schluss kommen, das die Informatik insgesamt als nicht so wichtig angesehen wird wie die traditionellen Wissenschaften.

Hier ein kleines Erlebnis: Vor meiner Softwaretechnik-Vorlesung fand eine Experimentalphysik-Veranstaltung statt. Da saß ein Häuflein von etwa zehn Studenten in einem Hörsaal, der 400 Menschen fasst. Ein junger Professor leitete Formeln her und zwei festangestellte Techniker waren ausschließlich dafür da, die Versuche aufzubauen. Als die Vorlesung endete, strömten etwa 340 Informatikstudenten in den Hörsaal. Zehn gegen 340  ̶  das war ein ziemlicher Kontrast, sowohl in der Menge als auch in schierer Energie (was sich in Lautstärke äußerte). Wer tut wohl mehr für die Zukunft Deutschlands: Die Physik oder die Informatik? Dennoch wird die Physik ungleich besser gefördert. Und die Ironie der Geschichte ist die: Physiker, die nicht eine wissenschaftliche Laufbahn aufnehmen, finden ja keine Physikindustrie vor, die sie einstellen würde. Daher verdingen sich viele von ihnen als Programmierer.

BD: [Hier muss ich eingestehen, dass meine vorhergehenden Fragen falsch zu verstehen waren. Niemand bestreitet, dass der Bedarf an Software-Entwicklern enorm ist. Mich beschäftigt die Frage, warum das seit 1968 andernorts eingeführte Software-Engineering-Studium in Deutschland kaum Beachtung gefunden hat. Ich hatte das Thema vor kurzem schon einmal aufgegriffen und werde es vermutlich nochmals tun]. Sie selbst haben vor über zehn Jahren unsere Fachkollegen aufgerüttelt, als Sie darauf hinwiesen, dass in der Forschung empirische Methoden zu kurz kommen. Hat sich dieses Problem gelöst? Wieweit können Hochschulen überhaupt empirische Forschung machen, deren Ergebnisse auch Praktiker überzeugen?

WT: Da hat sich inzwischen sehr viel verbessert. Ich war gerade auf der International Conference on Software Engineering (ICSE2012), der größten Veranstaltung für Softwaretechnik-Forschung. Sie fand dieses Jahr in Zürich statt. Fast alle wissenschaftlichen Beiträge, die ich mir anhörte, hatten einen beeindruckenden empirischen Evaluierungsanteil. Die meisten Arbeiten benutzen dazu Daten aus Projekten, insbesondere aus Datenbanken, die ganze Projekthistorien speichern, z.B. mit CVS und RCS :).

Hierzu ein Beispiel. Westley Weimer von der Universität von Virginia und seine Studenten hatten ein Verfahren entwickelt, das einige Fehlertypen in Software automatisch korrigieren kann. Die Idee alleine ist revolutionär — man stelle sich das vor: Defekte in der Software werden automatisch korrigiert! Man braucht nicht etwa formale Spezifikationen dazu, sondern lediglich automatisch ablaufende Testfälle, die die Defekte anzeigen. Das Verfahren kopiert Code von ähnlichen, aber korrekten Stellen im Programm, passt sie an den fehlerhaften Stellen an und probiert sie anhand der Testfälle einfach durch. Hier wird offenbar die Redundanz in Programmen ausgenutzt [Übrigens eine weitere Form von Redundanz, die mein letzter Beitrag übersah]. Aber funktioniert das überhaupt in der Praxis? Weimer und seine Studenten gingen so vor: Sie nahmen sich eine Anzahl quelloffener Projekte vor, wählten 105 Defekte aus, die tatsächlich korrigiert worden waren, und gingen dann auf die Versionen zurück, die diese Defekte noch enthielten. Dann ließen sie ihren Automatismus darauf los. Dieser korrigierte 55 der 105 Defekte! Die zugehörigen Testfälle wiesen danach keine Fehler mehr auf und die übrigen Testfälle liefen ebenfalls korrekt. Da sie die automatische Korrektur auf einem gemieteten Cloudrechner laufen ließen, konnten sie auch die Kosten angeben: $8 pro korrigierten Fehler. Derart günstig arbeitet kein Softwaretechniker!

Untersuchungen, die menschliche Subjekte einsetzen, sind dagegen seltener. Das beeindruckendste Experiment ist von Dag Sjoberg, der 300 professionelle Programmierer aus drei Ländern heuerte, um die Eigenschaften von Paarprogrammierung zu untersuchen. Es handelt sich hier um das größte kontrollierte Experiment in der Softwaretechnik, das mir bekannt ist. Wegen der Verwendung von Profis dürfte es auch Praktiker überzeugen. [In einem früheren Eintrag dieses Blogs wurde das Sjobergsche Projekt bereits kommentiert,] Solche Experimente sind teuer (aber nicht teuer im Vergleich zu Experimenten in der Pharmazie). Wir können sie wohl nur bei wirklich wichtigen Fragen einsetzen. Aber Benchmarks, wie sie Weimer verwandte, sind eine kosteneffektive Alternative, um automatische Werkzeuge zu testen und zu verbessern. Inzwischen erwarten die Gutachter der besten Konferenzen derartige Validierungen. Ohne sie kann man dort nicht publizieren.

BD: Seit etwa fünf Jahren haben Sie Ihr Interesse auf das Thema ‚Mehrkernrechner‘ (engl. multicore processors) gerichtet. Hier drängt sich mir eine Reihe von Fragen auf. Fangen wir bei der Hardware an. Gilt das Mooresche Gesetz jetzt nur noch zur Hälfte, d.h. die Packungsdichte wächst weiter, aber nicht mehr die Leistung?

WT: Die Mooresche Regel gilt weiterhin. Sie besagt, dass sich die Anzahl der Transistoren mit jeder Chip-Generation verdoppelt. Heute benutzt man oft die Abwandlung, dass sich die Anzahl Prozessoren verdoppelt. Wie lange noch ist unklar. Die Erhöhung der Taktfrequenz  hat etwa 2004 ein Ende gefunden, schlicht weil die Chips zu heiß wurden. Die Mooresche Regel sagt übrigens nichts über die Taktfrequenz aus. Wichtig ist folgende Schlussfolgerung: Zukünftige Leistungssteigerungen werden nur noch über Parallelverarbeitung erreicht. Das so genannte „free lunch“, d.h. die automatische Steigerung der Rechenleistung, ist vorbei. Bei leistungshungrigen Anwendungen ist das Ende der sequentiellen Verarbeitung schon heute gekommen.

BD: Parallelität hat Software-Entwickler schon immer fasziniert. Nur stand der Aufwand in keinem Verhältnis zum Ertrag. Wir werden gezwungen, über Probleme nachzudenken, die sehr schwierig sind, zum Beispiel Wettläufe.  Wir müssen Programme testen in Konfigurationen, die sich nur schwer simulieren lassen. Wie sehen diese Probleme heute aus? Gibt es neue Ansätze, etwa zum Testen?

WT: In der Tat gibt es sehr ermutigende Ansätze. Gerade für das Aufdecken von Wettläufen gibt es inzwischen brauchbare Methoden. Eine dieser Methoden beruht auf den so genannten Vektoruhren von Fidge und Mattern von 1988. Vektoruhren erzeugen eine partielle Ordnung von Ereignissen in parallelen Programmen, wodurch ungeordnete Zugriffe auf gemeinsame Variable detektiert werden können. Ergänzende Methoden erzeugen alle möglichen Verschränkungen von konkurrenten Prozessen, wodurch zur Testzeit alle Wettlauffehler auftreten. Noch überraschender ist, dass man Wettläufe durch das Einführen von Sperren automatisch korrigieren kann, und das auch noch zur Laufzeit! Der Grund für diese erfreuliche Entwicklung liegt darin, dass Wettläufe eine sehr enge, klar definierte Defektart darstellen, nach der man viel gezielter suchen kann als nach generellen Fehler in der Programmlogik. Auch Blockaden kann man detektieren. Damit wird man wichtige Fehlerquellen bei der Parallelprogrammierung beherrschen können.

BD: Jetzt – so sagen Sie – haben wir gar keine Wahl mehr. Sollte man nicht lieber die Parallelität soweit verbergen wie es geht? Warum kann nicht alles im Betriebssystem abgefangen werden und der Anwender denkt weiter in sequentiellen Prozessen?

WT: Ich fürchte, das Verbergen der Parallelität wird nur in ganz eingeschränkten Fällen funktionieren. In allen Anwendungen, die wir inzwischen parallelisiert haben (und dabei waren einige sehr große) hätte eine Bibliothek wenig genutzt. Natürlich brauchen wir eine Bibliothek zur Prozessverwaltung und Synchronisation, aber wo und wie parallelisiert wird, mussten wir uns immer genau überlegen und mehrere Varianten durchprobieren. Aber das ist nicht verwunderlich: auch sequentielle Anwendungen benutzen zwar Bibliotheken, aber nur aus Bibliotheksaufrufen bestehen die wenigsten Anwendungen. Die Verarbeitungslogik muss immer noch von den Programmierern eingebracht werden. Auf der positiven Seite kennen wir nun eine Reihe von Abstraktionen, wie z.B. Fließbandverarbeitung oder Arbeitgeber/Arbeiter (engl. Master/Slave, oder politisch korrekter, Master/Worker), die sich gut für Parallelisierung eignen.

BD: Für die Forschung ist Parallelität weiterhin ein herrliches Thema. Da kann man sich die Zähne dran ausbeißen. Da wir in Deutschland längst keine Rechnerindustrie mehr haben, leisten wir evtl. nur Amerikanern und Chinesen Hilfe. Ist die systemnahe Programmierung nicht Sache der Hardware-Hersteller? Warum kümmern sich Anwender um die Leistungssteigerung von Systemen, die in 20 Jahren bereits einen Faktor 1000 erreichten? Sehen Sie es anders? Wenn ja, treiben wir da Forschung der Forschung wegen?

WT: Keinesfalls. Aber erst Mal: Man kann nicht Deutschland mit ganz China und ganz Nordamerika vergleichen. Da muss man schon Europa nehmen, und da gibt es durchaus Firmen die Prozessoren entwickeln, z.B. ARM, Infineon, oder Dialog Semiconductor. Richtig ist, dass in der Vergangenheit Parallelrechner die Domäne des wissenschaftlichen Rechnens waren. Das hat sich aber seit etwa 2002 drastisch geändert. Parallelrechner sind inzwischen überall. Im vierten Quartal 2011 verkaufte Apple etwa 35 Millionen Mobilfone, die mit Doppelprozessoren ausgestattet sind. Anfang dieses Jahres führte HTC ein neues Telefon mit fünf(!) ARM-Prozessoren ein. Ernst zu nehmende Parallelrechner sind also schon in der Hosentasche angekommen. Dienstrechner sind bei acht, 16 oder mehr Kernen angelangt. Grafik-Prozessoren bieten Hunderte von Rechenwerken. Wegen der stagnierenden Taktraten müssen nun anspruchsvolle Anwendungen aller Arten parallelisiert werden  ̶  Warten auf die nächste Prozessorgeneration hilft nicht mehr!

Hier zwei Beispiele aus meiner eigenen Erfahrung. Für Agilent in Waldbronn haben wir die Software eines medizinischen Analysegerätes parallelisiert. Bei vier Prozessoren erzielten wir eine etwa 3-fache Beschleunigung. Für den Hersteller kostet ein Vierkerner so viel wie ehemals ein Einzelprozessor. Damit kann Agilent seinen Kunden zum gleichen Preis ein Gerät liefern, das wesentlich schneller arbeitet.

Für SAP haben wir das Laster-Planungsproblem parallelisiert. In diesem Problem hat man eine Reihe von Fabriken und eine Lasterflotte von Hunderten von Fahrzeugen. Die Aufgabe ist nun, die Produkte der Fabriken an Tausende Kunden möglichst schnell und kostengünstig zu liefern. Der Kenner merkt, dass sich da gleich zwei NP-vollständige Probleme verstecken: das Packungsproblem für die Laster (die auch noch unterschiedliche Kapazitäten haben) und des Problem des Handlungsreisenden (vervielfacht). Eine hochoptimierte, sequenzielle Version lässt ein Anwender etwa acht Stunden laufen und begnügt sich mit der bis dahin gefundenen (suboptimalen) Lösung. Wir konnten diese Laufzeit mit 24 Kernen auf 20 Minuten drücken. Zwanzig Minuten Wartezeit gegenüber einem ganzen Arbeitstag  ̶  das ist ein beachtlicher Fortschritt. Damit kann man bei Stornierungen oder Ausfällen sogar jederzeit nachplanen; vorher war das undenkbar.

Im Automobil konnten wir zeigen, dass man aus Stereobildfolgen eine Tiefenschätzung und Fahrbahnverfolgung in Echtzeit ausrechnen kann, ohne spezielle FPGAs einsetzten zu müssen, was einen entscheidenden Kostenvorteil bedeutet. Man sieht, dass Parallelverarbeitung schon heute einen konkreten Nutzen in der Praxis erzielt. In Anspielung auf Ihre Frage denke ich, dass wir durchaus China und Amerika Hilfe bieten können, und zwar in dem wir Parallelsoftware exportieren.

Viele Praktiker beginnen sich für die Parallelwelt zu interessieren. Eine Veranstaltung, die Konferenz Parallel2012 in Karlsruhe, war überfüllt und musste Interessenten abweisen. Auch eine Veranstaltung am FZI zum Thema Multicore war gut besucht. Wenn man die bekannte Technologie-Aufnahme-Kurve zugrunde legt, dann schätze ich, dass wir uns derzeit in der Pionierphase befinden. Bis spätestens 2020 denke ich, dass die frühe Mehrheit die Technik aufgegriffen haben wird. Danach kommen die späte Mehrheit und schließlich die Nachzügler. Heute schon bilden wir am KIT alle Softwaretechnik-Studenten in Parallelität aus, beginnend im zweiten Semester. Unsere Absolventen werden gefragter sein als je zuvor!

BD: Haben Sie vielen Dank, Herr Tichy, für dieses interessante Interview. Besonders gefreut hat es mich, sogar neueste Forschungsergebnisse kennen zu lernen, über die in diesem Monat auf der ICSE berichtet wurde.