Ü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
programmierte 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 Lochkarten abzurechnen. Seine
Antwort habe ich nicht vergessen. „Eure Probleme sind zwar interessant, 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
- Endres, A.: Lessons Learned in an Industrial Software Lab. IEEE Software, Sept. 1993, S. 58-61
- 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
- Endres, A.: Professionalität und Verantwortung in der Informatik. Informatik Spektrum 26,4 (2003), 261-266
- Endres, A.: Analyse und Verifikation von Programmen, München: Oldenbourg 1977; 405 Seiten; ISBN 3-486-21361-X
- Endres, A.: An Analysis of Errors and their Causes in System Programs. IEEE Trans. Softw. Eng. 1,2 (1975)
Keine Kommentare:
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.