Montag, 5. September 2016

Episoden aus dem Leben eines Programmierers und Managers

Über meine Erfahrungen aus über 40 Berufsjahren habe ich schon mehrfach berichtet, im Besonderen in [1..3]. Dabei ließen sich die fachlichen Erfahrungen nicht immer sauber von den allgemeinen Erfahrungen in einer Führungsaufgabe trennen. Die fachliche Seite umfasste in meinem Falle alle Themen, die mit Informatik und Software zu tun haben. Die Management-Seite umfasste Aspekte der Menschenführung, der Marktbeobachtung und der Projektabwicklung. Manches war amüsant und lehrreich, anderes mühsam, ja leidvoll. Ich will im Folgenden Dinge hervorheben, die man nicht in Lehrbüchern findet. Nach dem großen zeitlichen Abstand drängen sich Skurriles und Überraschendes besonders auf. Diese Anekdoten hakten sich in meinem biografischen Gewölle fest.

Aus dem Programmiererleben

(1) Aus der Lochkartenzeit

Eines meiner ersten Programme, an das ich mich erinnere, schrieb ich 1957 oder Anfang 1958. Der Ausdruck ‚Schreiben‘ passt nicht ganz. Es war mehr ein Ausknobeln. Die Maschine war die IBM 650 des Rechenzentrums Sindelfingen. Jedes benutzte Programm wurde vor seiner Ausführung von Lochkarten in den Trommelspeicher geladen. Das dafür erforderliche Hilfsprogramm hieß Lader. Es musste vor dem Laden des eigentlichen Programms in die oberen Speicherzellen gespeichert werden. Eigentlich hatte das Programm drei Funktionen, die nacheinander ausgeführt wurden. Es löschte die Trommel sowie Akkumulator und Quotientenregister auf null, lud das auszuführende Programm von Lochkarten auf die Trommel und verzweigte zum Anfang des geladenen Programms. Irgendwann wurde die Maschine auf den neuesten Stand hochgezogen und erhielt dabei auch vier Indexregister. Das waren schnelle Halbleiterspeicher, mit deren Hilfe der Zugriff auf den 2000 Worte umfassenden Trommelspeicher für bestimmte Arten von Rechnungen (z. B. Bearbeitung von Tabellen und Matrizen) vereinfacht werden konnte. Die bisherige Version des Laders hatte auf eine Lochkarte gepasst. Eine 80-spaltige IBM-Lochkarte hatte Platz für genau acht Instruktionen. Diese waren je 10 Zeichen lang (zwei Stellen für Op-Code und zweimal je vier Stellen für Adressen). Jetzt mussten auch noch die vier Indexregister auf null gesetzt werden. Dafür gab es eine zweite Lochkarte, die mit dem Lader vor das zu ladende Programm gelegt werden musste. Plötzlich war die Reihenfolge dieser beiden Karten wichtig. Da ich dies als einen Rückschritt in der Benutzbarkeit des Laders ansah, ließ es mir keine Ruhe, bis ich einen Lader für Maschinen mit Indexregister wieder auf einer Karte hatte. Ich benutzte dafür Tricks, von denen ich andern Programmieren dringend abriet. Sie sollen auch hier nicht verraten werden. Noch eine kleine Ergänzung: Ich flog hin und wieder mit Kunden nach Paris, die auf der IBM 704 am Place Vendôme rechnen wollten. Wir lernten, dass der Zoll für leere Lochkarten Gebühren verlangte. Lochkarten mit Löchern waren für den Zoll jedoch Güter ohne Wert. Für mich und meine Kunden war das Gegenteil der Fall. Unsere Programme sowie die Eingabe- wie die Ausgabedaten waren stets auf Lochkarten mit Löchern.

(2) Der Baulohn.

Diese Geschichte habe ich vor Jahren [3] schon erzählt. Ich gebe sie daher unverändert wieder.

Es war Anfang 1960, als wir für das IBM-Rechenzentrum in Düsseldorf den Auftrag gewonnen hatten, für eine Baufirma aus der näheren Umgebung die Lohnabrechnung durchzuführen. Ein Kollege und ich übernahmen es, die Umstellung des Baulohns von der Lochkartenabrechnung auf die pro­grammierte Form der Abrechnung durchzuführen. Der Lohn wurde regelmäßig am Freitag jeder Woche an einige hundert Mitarbeiter ausgezahlt. Etwa am Dienstag oder Mittwoch merkten wir, dass wir das Programm nicht bis Freitag fertig bekommen würden, und dass es aller Voraussicht nach nicht in den Speicher passen würde. Ich marschierte zum IBM-Niederlassungsleiter, einem respekt-einflößenden, etwas älteren Herrn, mit dem Ansinnen, doch den Kunden zu überzeugen, diese Woche noch einmal mittels Loch­karten abzurechnen. Seine Antwort habe ich nicht vergessen. „Eure Probleme sind zwar inter­essant, sie gehen mich aber nichts an. Ich denke nicht daran zum Kunden zu gehen. Ihr habt das Projekt übernommen und den Termin zugesagt. Entweder läuft Euer Programm am Freitag oder wir schicken die Bauarbeiter zu Euch und Ihr zahlt von Hand aus“. Natürlich lief unser Programm am Freitagmorgen und es passte auch in den Speicher. Dass wir in dieser Woche wenig Zeit zum Schlafen bekamen, brauche ich nicht eigens zu erwähnen. Ich kann mich nicht erinnern, dass sich Lohnempfänger über Fehler beschwert haben oder dass wir Nacharbeiten machen mussten. Anders war es bei der Erstellung einer Lohnsteuertabelle. Als der Verlag damit beginnen wollte, die etwa 60-seitige Broschüre zu drucken, wurde festgestellt, dass sich auf einigen Seiten Rundungsfehler eingeschlichen hatten. Da der Computer-Ausdruck direkt als Druckvorlage diente, durften wir den ganzen mehrstündigen Rechnerlauf noch einmal machen.

Übrigens fiel mir wieder ein, wie wir beim Baulohn das Problem des nicht ausreichenden Speichers lösten. Wir sortierten die Abrechnungsdaten derjenigen Bauarbeiter heraus, die mehr als eine Zuschlagsart hatten. Es waren nur ein halbes Dutzend. Wir berechneten jeden Zuschlag getrennt, und addierten dann von Hand.

(3) Die Kruse-Methode.

Als Programmierer früher Maschinen hatte man stets eine besondere Beziehung zu den Wartungstechnikern des Herstellers IBM. Taten Hardware oder Software nicht das, was sie sollten, hatten wir sehr oft den Lieferanten als den Schuldigen im Verdacht. Erst wenn der Techniker sagte, das Problem kann nicht auf seiner Seite liegen, waren wir bereit, weiter im eigenen Programm nach einem Fehler zu suchen. Unsere Düsseldorfer 650 wurde von zwei Technikern gewartet. Zwei Menschen können kaum unterschiedlicher sein. Der ältere von beiden muss damals Ende der 50er gewesen sein. Er ist heute längst tot. Er hieß bei uns Herr Kruse. Seine Spezialität waren die als Ein- bzw. Ausgabegeräte dienenden Lochkarten-Maschinen. Waren irgendwelche Daten falsch eingelesen, prüfte er zunächst die genaue Zeitfolge der von den Abfühlstationen der Lochkarten übertragenen Impulse. Er erhielt dafür auch den Beinamen ‚Nockenkruse‘. Noch überraschender war sein zweiter Diagnoseschritt. Er schaltete die Stromzufuhr ab, wartete drei Sekunden und schaltete das Gerät wieder ein. Sehr oft war damit der Fehler am Gerät behoben. Es stellte sich später heraus, dass diese Methode in andern technischen Umgebungen sehr gut anwendbar war. Wollte z. B. der Fernseher kein richtiges Bild erzeugen, riet ich meiner Frau zur Kruse-Methode. Sie wusste, was zu tun war, und meistens half es auch. Ein Wort noch zum zweiten Techniker. Trat ein Fehler auf, zog er die Schaltpläne der Maschine hervor. Manchmal fragte er auch, ob er mein Programm ansehen dürfte. Er wurde später Leiter des Technischen Außendienstes der IBM Deutschland.

(4) Nutzerperspektive

Einer meiner angenehmsten Kunden während meiner Düsseldorfer Zeit war ein Ingenieurbüro aus Essen. Drei oder vier Leute kamen etwa einmal pro Monat. Sie hatten alles bestens vorbereitet. Sie hatten alle Programme selbst erstellt und hatten alle Eingabedaten bereits abgelocht. Sie benötigten nur mehrere über den Tag verteilte Rechenperioden und ein Büro für dazwischen. Sie zahlten prompt für die benutzte Rechnerkapazität. Als der Kunde plötzlich nicht mehr wiederkam, rief ich an, um zu erfahren, was los war und ob wir zu teuer oder zu unhöflich wären. ‚Nein‘, war die Antwort. ‚Wir waren mit Ihrer Betreuung und Ihren Konditionen voll zufrieden. Das Problem lag bei uns. Da Sie am Wochenende nicht arbeiten und uns auch nicht allein in Ihr Gebäude lassen könnt, haben wir uns eine eigene Maschine zugelegt. Sie ist auch von IBM (eine 1620). Jetzt haben wir immer zwei Tage mehr Zeit, um unser Angebot zu erstellen. Da es meist an einem Montag abgegeben werden muss, können wir noch am Samstag oder sogar am Sonntag letzte Änderungen vornehmen.‘

(5) Deutsches COBOL

Über diese Episode aus den frühen 1960er Jahren habe ich in diesem Blog bereits berichtet. Die Geschichte ist in dem Nachruf auf Heinz Schappert enthalten, dem langjährigen DV-Leiter von Bayer Leverkusen. Ich zitiere:

In den Jahren 1962-63 befasste sich ECMA (European Computer Manufacturers Association) auf Betreiben der französischen Firma Bull damit, die Sprache COBOL in andere Sprachen als Englisch zu übersetzen. Von der IBM Europa bekam ich den Auftrag, mich um die deutsche Version zu kümmern. Es gelang mir, mit Herrn Schapperts Hilfe den Deutschen Normenausschuss (DIN) zu involvieren. Nach mehreren Sitzungen konnten sich die beteiligten Experten sogar auf einen Norm-Vorschlag einigen. Ich selbst schrieb ein Programm (in Fortran), mit dem man deutsche, französische oder spanische COBOL-Programme in englisches COBOL übersetzen konnte. Das Projekt fand ein jähes Ende, als Herr Schappert seine Programmierer in Leverkusen fragte, ob sie in Zukunft lieber deutsches statt englisches COBOL verwenden würden. Die Antwort war eindeutig „Wir bleiben bei englischem COBOL. Das hat den großen Vorteil, dass man sofort sieht, was Schlüsselworte der Sprache (engl. keywords) und was Variablennamen des Programmierers sind.“ Meine Arbeit eines halben Jahres landete im Papierkorb. Was blieb war, dass ich später in der eigenen Firma als COBOL-Experte galt und sogar über Grundkenntnisse im Compilerbau verfügte. Außerdem blieb die Erinnerung an ein schönes Jahr an der Côte d’Azur. Ich gehörte während dieser Projektzeit nämlich zum französischen IBM-Labor bei Nizza.

Einige andere regional benötigte Produkte erwiesen sich ebenfalls als wirtschaftlicher Flop. Ein Beispiel ist die Sprache Algol. Obwohl als dringende Lücke für den ganzen europäischen Markt identifiziert, hielt sich die tatsächliche Zahl der Nutzer auf IBM Rechnern in Grenzen.

(6) Kollision von Ingenieur- und Mathematikerdenken

Auf dieses Erlebnis ging ich in einem Blog-Beitrag vom März 2013 ein. Dort hatte ich beschrieben, welche Erweiterungen zu Programmiersprachen ich einst für sinnvoll hielt. Ich habe einen Vorschlag dieser Art in meiner Dissertation [4] (S. 348-368) dokumentiert. Ich würde dieses Konzept heute als problem-orientierte oder konkrete Typen bezeichnen. Ich zitiere:

Es gab um diese Zeit [Anfang 1960er Jahre] bereits Intervall-Arithmetik, aber auch Sprachen, die Vektoren und Matrizen als das behandeln, was sie für Ingenieure sind, nämlich Datentypen, die man geschlossen manipulieren kann, d.h. ohne ihre interne Struktur und ihre Speicherung zu kennen. Der Kern des Vorschlags bestand darin, Programmen mehr als nur die elementaren Trägertypen (integer, float, char) mitzuteilen. In der Technik sowohl wie im Kaufmännischen gibt es nur wenige Fälle so genannter dimensionsloser Zahlen. Fast immer haben Zahlen eine Dimension (hier im ingenieurmäßigen Sinne). Sie stellen dann nicht nur abstrakte Werte dar, sondern Größen. Im Kaufmännischen sind es Währungsbeträge (€, US$, £, ¥), im Technischen sind es Längen, Gewichte, Zeiten, Spannungen, Widerstände oder Leistungen. Diesen Dimensionen einer Größe sind Maßeinheiten zugeordnet. Alle Zahlen erhalten einen Sinn erst durch die Einheit, in der sie ausgedrückt sind.

Als ich 1963 einem entsprechenden Vorschlag für die Sprache PL/I machte, wurde dieser von einem Mathematiker niedergeschmettert. Seine Worte haben sich als unauslösliches Glanzstück mathematischer Arroganz bei mir eingeprägt. ‚Wir Mathematiker haben die abstrakten Zahlen nicht erfunden, damit sie wieder von Ingenieuren versaut werden (engl. spoiled).‘

Aus dem Managerleben

(1) Freuden der Mitarbeiterführung

Ein Assembler ist ein zwar einfaches, aber zentrales Systemprogramm für jedwede Maschine. Er ersetzt alphabetische Op-Codes durch numerische Op-Codes und symbolische Adressen durch echte. Ein Makro-Assembler entdeckt zusätzliche Op-Codes und fügt an ihrer Stelle eine Folge von Instruktionen ein. Diese werden einer Makro-Definition entnommen. Eine Gruppe, geleitet von dem erfahrenen Michael, sollte 1967 einen Assembler für das Model 20 DPS bauen. Mehrere Berufsanfänger standen ihm zur Seite. Einer von ihnen  ̶   er soll hier Rolf heißen  ̶  sollte die Definitionstabelle für Makros anlegen und mit Beispielen füllen. Nach einigen Wochen war der Kern-Assembler fertig. Vom Makro-Teil war noch nichts zu sehen. Auch die Definitionstabelle war noch leer. Es bestand wenig Aussicht, dass sie sich alsbald füllen würde. Michael bot mir an, dass er diesen Teil des Projekts selbst übernehmen und den Zeitverlust schnellstens aufholen würde, vorausgesetzt, ich würde ihm Rolf vom Halse halten. Das tat ich, indem ich Rolf einen Schreibtisch in einem entfernten Zimmer zuwies. Damit verband ich die Bemerkung, dass er nicht damit rechnen sollte, je von mir einen neuen Auftrag zu bekommen. Nach 2-3 Monaten hatte Rolf eine Stelle in einem anderen Bereich des Unternehmens gefunden.

(2) Nur Ärger mit Preisverleihungen

Als Führungskraft sieht man sich manchmal veranlasst, Kritik an Mitarbeitern zu üben. Das ist sehr lästig (siehe oben). Sie wird deshalb oft vermieden. Wer glaubt, mit Lob sei es immer leichter, kann sich täuschen, vor allen dann wenn es selektiv ausgeteilt wird. Mit zwei Projekten verknüpfe ich diesbezügliche unangenehme Erinnerungen. Am Ende eines rein lokalen Projekts erhielten zwei von etwa 20 Mitarbeitern eine Geldprämie. Sie wurden vom Laborleiter in dessen Büro verliehen. Als wir zurückkamen, fanden wir eine Mitarbeiterin in Tränen aufgelöst. ‚Da sieht man es wieder‘ ließ sie sich verlauten. ‚Schon Otto Hahn erhielt den Nobelpreis, den eigentlich Lise Meitner verdient hatte‘. Schließlich habe sie mehr Programmzeilen (LOC) zu dem Projekt beigetragen, als einer der zwei Geehrten. Ich stammelte etwas von der Wichtigkeit von Entwurfs- und Koordinierungsarbeiten, fand aber kaum Gehör.

Ein späteres Projekt hatten wir mit einem anderen europäischen Labor zusammen durchgeführt. Nach Ende des Projekts wurden von jedem Labor 4-5 Mitarbeiter (mit Partnern) nach Rom eingeladen. Am Tag, als alle wieder zuhause waren, hing ein Plakat über dem Laboreingang. ‚Willkommen zurück den glücklichen Romfahrern - Die traurigen Hinterbliebenen‘ stand darauf. Die Stimmung verbesserte sich erst, nachdem wir alle fast 100 Mitarbeiter des Bereichs (mit Frauen und Kindern) für einen Nachmittag auf die Burg Teck einluden.

(3) Das gefährliche zweite Projekt

Es gilt als ungeschriebenes Gesetz, dass man sich  ̶  sowohl als Einzelner wie als Organisation  ̶  vor seinem zweiten Projekt besonders in Acht nehmen soll. Ging nämlich das erste Projekt glatt über die Bühne, glaubt man alles zu beherrschen, was kommt. Das DOS/VS-Projekt (1972-1975) fiel für mich in die Kategorie eines zweiten Projekts. Es gab ein Maß an Spezialisierung, eine internationale Projektaufteilung und damit gegenseitige Abhängigkeiten, die wir vorher nicht kannten. Es kamen daraus resultierende Konflikte zum Vorschein, die den Projektablauf bestimmten. In [2] habe ich die Management-Erfahrungen dieses Projekts so zusammengefasst:

Es traten alle die Dinge in Erscheinung, die eine Rolle spielen, sobald man nicht mehr auf sich allein gestellt ist. Je mehr andere Entwickler-Organisationen mit involviert sind, umso mehr Aufwand und Energie kostet die Kommunikation und Koordination. Es müssen alle relevanten Entscheidungen gründlich motiviert, nach allen Seiten abgestimmt und schließlich dokumentiert werden. Noch kritischer sind Entscheidungen, die man nicht selbst trifft, sondern die von außen auf das eigene Team hereinbrechen. In diesen Situationen den Eindruck der eigenen Projekt-Führerschaft aufrecht zu erhalten, ist nicht leicht. In der Erinnerung fast aller Beteiligten ist dieses Projekt haften geblieben als eine große Herausforderung sowohl in fachlicher wie auch in organisatorischer Hinsicht. Viele der durchaus interessanten technischen Fragestellungen wurden an den Rand gedrückt durch die bis an die Grenze des Erträglichen gehende Arbeitsbelastung und die immensen Kommunikationsprobleme.

(4) In der UNIX-Welt

Drei Jahre meines beruflichen Lebens (1982-1985) widmete ich dem Thema UNIX. Für eine ausführliche Darstellung verweise ich auf [2]. Hier gebe ich nur einen Auszug wieder, in dem spezielle Management-Erfahrungen festgehalten sind. Ich zitiere:

Es gab eine größere Ausschreibung für UNIX-Systeme im [amerikanischen] Verteidigungsbereich. Wir entschieden uns mitzubieten. Beim ersten Vergleich schnitten wir schlecht ab, lagen unter "ferner liefen", bekamen aber eine zweite Chance. Dafür erhielten wir die Anwendung (Benchmarks) des Kunden, um uns für einen "Best and Final"-Vergleich vorzubereiten. Wir setzten die besten Analytiker der Firma und die umfassendsten Messwerkzeuge ein, um alle Pfadlängen der Anwendung zu vermessen und anschließend zu verbessern. Das Ergebnis war, dass wir bei dem endgültigen Vergleich zwar bezüglich Funktion und Durchsatz die beste Lösung besaßen, insgesamt aber nur zweitbester Anbieter wurden. Die Preise für die IBM Lösung lagen wesentlich über denen eines Anbieters mit verteilten Mikroprozessoren, die er aus Standard-Komponenten zusammenbaute. Unsere Hardware kostete das Vielfache. Um den akademischen Markt besser kennen zu lernen, überredeten wir eine amerikanische Universität, ihr bisheriges UNIX-System durch unser System zu ersetzen. Die Installation lief glatt und wir waren relativ schnell in Produktion. Plötzlich wurden wir von Hunderten von Fehlerberichten überschüttet. Selbst Mitarbeiter aus der [Böblinger] Entwicklung vor Ort erreichten nicht, dass der Berg kleiner wurde. Die Mitarbeiter des Rechenzentrums und die Studenten der Universität berichteten weiter über Probleme. Auf die Frage, ob das alles Probleme seien, die nur bei unserem System aufträten, erhielten wir die Antwort: „Es sind auch die Probleme in UNIX dabei, die wir seit Jahren kennen. Nur machte es bei den früheren Herstellern wenig Sinn sie zu melden. Bei IBM stellen wir jedoch andere Anforderungen“. Kein Wunder, dass unser lokaler technischer Außendienst mit diesem System nicht viel zu tun haben wollte. Bei dem erwähnten „Best and Final“ Test für IX/370 wurde mehrere Tage lang rund um die Uhr gearbeitet, um die Ansprüche des potentiellen Kunden zu erfüllen. Mehrere Mitarbeiter aus Böblingen waren vor Ort, die von zuhause aus Unterstützung bekamen. … Obwohl der Auftrag nicht gewonnen wurde, erntete das Böblinger Team sehr viel Lob für seine technische Kompetenz. „Das hatten wir den Böblingern nicht zugetraut“ meinte Jerry Ebker, der Vizepräsident der [für das Regierungsgeschäft der IBM zuständigen] Federal Systems Division (FSD), bei der Abschlussbesprechung.

(5) Das Ringen um Methodik und Qualität

Vom ersten Tag meiner industriellen Laufbahn (im November 1957) bis zum letzten (im Dezember 1992) stand stets die Frage im Mittelpunkt, wie arbeitet man effizient und erzielt gleichzeitig ein qualitativ hochwertiges Ergebnis. Die Arbeitsweise änderte sich laufend. Das Qualitätsziel erhielt eine immer sich steigende Bedeutung. Anstatt eine für ein Lehrbuch geeignete Vollständigkeit anzustreben, will ich nur einige der Thesen zitieren, die den Kern der Veröffentlichung [1] ausmachen.
  • Die Wiederverwendung von Code und dem dazu gehörigen Material (Entwurfsdokumentation, Testfälle) ist erstrebenswert und möglich, aber nicht trivial. Gemeint ist die Wiederverwendung durch Entwickler. Jeder Code dient der Verwendung durch Anwender. Das ist der Normalfall und ist hier nicht gemeint.
  • Formale, also mathematisch fundierte Methoden sind dann praktisch relevant, wenn sie die Basis für Automatisierung bilden. Anders gesagt, sind Methoden gut, kann man sie in Werkzeuge umwandeln und einem Nutzer in die Hand geben, der die Methode  verwendet, auch ohne sie zu verstehen. Methoden, für die es überhaupt keine Werkzeuge gibt, können nicht als Technik gelten.
  • Ein Vorgehensmodell ist die Voraussetzung für die Gewinnung von Prozessdaten. Das gilt auch für die Software-Entwicklung. Ohne Daten lässt sich kein Prozess verbessern.
  • Prozessziele (z. B. % Nacharbeit) müssen in der Gruppe kommuniziert und vereinbart werden. Heimliche oder private Ziele kann man vergessen.

 (6) Erfahrungen mit Fachvorträgen

Als Letztes mache ich noch ein paar Bemerkungen zu einer Nebenbeschäftigung. Diese bestand  ̶  vor allem in den späten Berufsjahren  ̶  im Halten von Vorträgen und dem Schreiben von externen Veröffentlichungen.

An zwei Vorträge erinnere ich mich besonders gut. Der eine war 1975 auf der ACM/IEEE-Tagung ‚Reliable Software‘ in Los Angeles. Dave Parnas hatte mich vorgeschlagen. Barry Boehm leitete die Sitzung. Vic Basili und Capers Jones nahmen den Vortrag in ihre Sammelbände auf. Es wurde meine am häufigsten zitierte Publikation [5]. Deutsche Kollegen erinnern mich oft an meinen Vortrag auf der GI-Jahrestagung 1978 in Berlin. Ich hatte den Unterschied zwischen akademischer und praktischer Informatik leicht überspitzt dargestellt. Damit verfestigte ich meinen Ruf ein Querdenker zu sein. Für mich selbst am eindrucksvollsten war mein Vortrag 1987 beim Schweizer Bankverein in Wolfsberg (auf der schweizerischen Seite des Bodensees). Hier mein Bericht aus [2]:

Besonders oft wurde ich in die Schweiz eingeladen. Mit dem Thema „Software-Qualitätssicherung“ fand ich dort viele interessierte Zuhörer. Den ersten Vortrag zu diesem Thema hielt ich auf Einladung von Prof. Lutz Richter von der Universität Zürich. Der Vortrag selbst fand im zentralen Kuppelbau der ETH statt. Unter den Zuhörern war auch der Informatik-Direktor des Schweizer Bankvereins (SBV/UBS), heute eine der größten Banken der Welt. Er lud mich daraufhin als Referent zu einer Fortbildungsveranstaltung seiner Bank ein. Diese war im Herbst 1987 im Schulungszentrum Wolfsberg des SBV, herrlich gelegen am Westufer des Bodensees mit Blick auf die Insel Reichenau. Teilnehmer der Veranstaltung waren etwa 100 Führungskräfte des Informatik-Bereichs der Bank, die über 1000 Programmierer umfasste. Ich hielt etwa denselben Vortrag wie in Zürich. Danach wurde das Auditorium in vier Gruppen aufgeteilt, um die „Endres-Methode“ zu diskutieren im Hinblick auf ihre Anwendbarkeit bei der Bank. Dieser Begriff war mir bis dahin nicht bekannt. Ich hatte dafür plädiert, zuerst die akut auftretenden Probleme und Fehlerarten zu analysieren, dann darauf abgestimmte Fehlerverhütungs- und Aufdeckungsprozesse anzuwenden, und das möglichst früh in der Entwicklung. Während der etwa einstündigen Gruppendiskussion ging ich von der einen zur anderen Gruppe. Ich konnte aber nichts verstehen, da die Unterhaltungen im Schweizerdeutsch stattfanden. Ich setzte meine Hoffnung auf die Abschlussdiskussion im Plenum. Hier wurde zwar Hochdeutsch gesprochen, konnte aber trotzdem nur die Hälfte verstehen, weil so viele schweizerische Spezialbegriffe aus dem Bankwesen benutzt wurden, die ich nicht kannte. Wieweit die Bank die „Endres-Methode“ einsetzte und ob sie damit Erfolg hatte, habe ich leider nicht erfahren. 

Anstatt eines Nachworts

Geschichten zu erzählen ist das Hobby vieler älterer Menschen  ̶  so auch meines. Homer gilt als der Urvater unserer europäischen Literatur. Er schrieb vor 3000 Jahren langatmige Geschichten auf  ̶  so heißt es  ̶  nicht um sie vor dem Vergessen zu bewahren, sondern um Zeitgenossen eine Botschaft zu vermitteln. Was Stil und historische Bedeutung anbetrifft, bleibt Homer unübertroffen. Soweit jedoch meine Anekdoten eine Botschaft enthalten, überlasse ich es der Leserin und dem Leser sie zu erkennen und ggf. auf ihre/seine Situation zu übertragen.

Nur auf Papier vorhandene Referenzen
  1. Endres, A.: Lessons Learned in an Industrial Software Lab. IEEE Software, Sept. 1993, S. 58-61
  2. Endres, A.: Die IBM Laboratorien Böblingen: System-Software-Entwicklung. Band 2 der Reihe Forschung und Entwicklung in der IBM Deutschland. Eigenverlag: Sindelfingen 2001; 144 Seiten. ISBN 3-920799-22-3
  3. Endres, A.: Professionalität und Verantwortung in der Informatik. Informatik Spektrum 26,4 (2003), 261-266
  4. Endres, A.: Analyse und Verifikation von Programmen, München: Oldenbourg 1977; 405 Seiten; ISBN 3-486-21361-X
  5. Endres, A.: An Analysis of Errors and their Causes in System Programs. IEEE Trans. Softw. Eng. 1,2 (1975)

Keine Kommentare:

Kommentar veröffentlichen