Erinnerungen an Harlan Mills (1919-1996) und Watts Humphrey (1927-2010)

Im Folgenden werde ich an zwei, inzwischen verstorbene IBM-Kollegen erinnern, die auch durch ihre Arbeiten außerhalb der Firma bzw. nach ihrer IBM-Karriere der fachlichen Öffentlichkeit bekannt geworden sind. Sie haben auch innerhalb der IBM deutliche Spuren hinterlassen. Ich hatte über Jahre hinweg Gelegenheit, mit ihnen zusammenzuarbeiten. Beide nahmen relativ wenig Einfluss auf die Produktpolitik der Firma, umso größer war ihre Wirkung auf die internen Methoden und Prozesse.

Harlan Mills gehörte zur Federal Systems Division (FSD) der IBM. Dieser Unternehmens­bereich, der 1993 verkauft wurde, war damals zuständig für Projekte und Dienstleistungen für die amerikanische Regierung. Das Verteidigungs­ministerium und die NASA waren die größten Auftragsgeber. Die dortigen Kollegen mussten jeden ihrer Aufträge im strengen Wettbewerb gewinnen. Einige der Projekte standen während der Durchführung im Rampenlicht der Öffentlichkeit, wie z.B. die Hardware und Software für das Mondlandeprojekt Apollo. Dass es bei allen Raumfahrtunternehmungen der USA so gut wie keine Software-Probleme gab, ist anerkanntermaßen der Verdienst von FSD. Im Endres/Gunzenhäuser-Buch (S. 22) ist das Warum kurz erläutert. Viele der Kollegen von FSD waren in der Fachwelt bekannt (Joel Aron, Terry Baker, Bernie Witt) und genossen hohes Ansehen bei uns ‚Zivilisten‘ in den normalen Entwicklungslabors der IBM.

 

Mills war von 1964 bis 1987 bei IBM. Er wurde 1981 zum IBM Fellow ernannt. Wie kein anderer hat er dafür gesorgt, dass die Ideen von Dijkstra, Wirth und Hoare innerhalb der IBM bekannt wurden. Als Mathematiker war er von Dijkstras Diktum überzeugt, dass die mathematische Methode der wirksamste Weg sei, um mit Komplexität fertig zu werden. Entsprechend vertrat er die Auffassung, dass man korrekte Programme am ehesten dadurch erreicht, dass man sie als mathematische Objekte betrachtet und ihre Struktur möglichst einfach und übersichtlich hält. Der Autor eines Programms verschafft sich ein Gefühl der Korrektheit primär durch gedankliche Analyse des Programmtextes, evtl. unterstützt durch Beweise. Testen ist verpönt. 

Um diese Denkweise in der Praxis durchzusetzen, schlug Mills ein enormes Schulungsprogramm vor, was Anfang der 1980er Jahre weltweit durchgezogen wurde. Die Basis bildeten zweiwöchige Lehrgänge, die für alle Entwickler zur Pflicht wurden. Behandelt wurden Syntax und Semantik von Programmiersprachen, Datentypen, Logik und Mengenlehre, sowie Beweistechnik. Eine an PL/I erinnernde Entwurfssprache (CDL) sollte die schrittweise Verfeinerung des Entwurfs ermöglichen. Über alle Labors hinweg haben schätzungsweise 20.000 Programmierer und 2.000 technische Autoren an der Ausbildung teilgenommen. Ich selbst besuchte nur die abgekürzte 3-Tageversion für Manager. Es gab Instruktoren in jedem Labor. In Böblingen übernahm Klaus Darga [1] diese Funktion. Zwei von Mills Büchern, die das Lehrmaterial wiederspiegeln, möchte ich erwähnen:

  1979 Structured Programming, mit den Ko-Autoren Linger und Witt.
  1987 Principles of Computer Programming: A Mathematical Approach, mit den Ko-Autoren Basili, Gannon, and Hamlet

Die Einrichtung der IBM in New York City, die das von Mills entwickelte Kurspro­gramm in den USA anbot, nannte sich Software Engineering Institute (SEI). Dieselbe Idee und der gleiche Namen wurden vom amerikanischen Verteidigungsministerium übernommen, als es später an der Carnegie-Mellon Universität in Pittsburgh ein Forschungsinstitut gründete. Dass Watts Humphrey, der andere Kollege, über den ich hier berichten werde, später diesem Institut zu Weltruhm verhalf, ist eine nette Koinzidenz. Im Hinblick auf seine nachhaltige Wirkung hatte das Ganze eine fatale Schwäche: Es gab damals – und auch später – so gut wie keine Werkzeuge, welche die Anwendung dieser Methoden in der Praxis unterstützten. Vor allem gab es keine Brücke zwischen Entwurf und Implementierung, was zur Folge hatte, dass beide im Laufe der Weiterentwicklung auseinanderdrifteten. Nur selten wurde dann der Entwurf nachgezogen.

Zwei mit Mills Namen verbundene Ideen betrafen die Organisation von Software-Projekten. Sein erster Vorschlag, den er zusammen mit Terry Baker propagierte, hieß Chef-Programmierer-Team. Er basierte auf der Analogie zur Medizin. Ein Chirurg bekommt seine Kompetenz dadurch, dass er selbst operiert. Er sah die Ursache für schlechte Software darin, dass Informatiker, sobald sie Erfahrung gewonnen haben, nicht mehr praktizieren, d.h. selbst Programme schreiben und testen. Er glaubte, man könnte dem entgegenwirken, indem man ein hierarchisches Team bildet, so dass dem Chef nur die interessanten und wichtigen Aufgaben bleiben. Die weniger interessanten, rein klerikalen Arbeiten sollten weniger qualifizierte Mitarbeiter übernehmen. Er definierte also den Chef-Programmierer, einen Backup-Programmierer und einen Software-Bibliothekar. Der Ansatz fand in der Praxis wenig Zustimmung. Chefs zu finden war leicht, Backups schon etwas schwieriger, aber niemand wollte Bibliothekar sein. Außerdem wurde von der eigenen Branche argumentiert, dass man klerikale Aufgaben eh bald durch Werkzeuge eliminieren würde.

Beim Cleanroom-Ansatz ließen sich Mills und sein Ko-Autor Richard Linger von der Halbleiterfertigung anregen. Will man Fehler vermeiden, muss man dafür sorgen, dass keine Störungen auftreten. So wie Physiker bei der Chip-Produktion Staubteilchen eliminieren, versuchte sein Vorschlag, Unsicherheit stiftende Arbeitsweisen aus dem Prozess auszumerzen. Dazu gehörte, dass der Entwickler selbst testet, und − was das schlimmste ist − selbst Fehler korrigiert. Er darf daher nur nach formalen Methoden Code schreiben, der gut durchdacht (also sauber) ist. Getestet werden alle Module erst in der Systemumgebung, und zwar nach statistischen Methoden. Auch dieser Ansatz hat den Test der Praxis nicht bestanden.

Mills war mehrmals in Böblingen. Bei seinem letzten Besuch etwa 1983 kam er per Bahn von München. Er stieg eine Station vor dem Böblinger Hauptbahnhof aus und verpasste den angesetzten Termin für seinen Vortrag. Nach seinem Ausscheiden bei IBM und bis zu seinem Tode war er Informatik-Professor in Vero Beach, FL.

Watts Humphrey war bei IBM von 1959 bis1986. Er war von Hause aus Physiker und hatte eine Reihe von Positionen sowohl in der Hardware- wie in der Software-Entwicklung inne gehabt. Er war sehr stolz auf die fünf US-Patente, die er aus einer Hardware-Zeit besaß. Er vertrat Mitte der 1960er Jahre die Entwicklerseite in der internen Studiengruppe, die das ‚Unbundling‘ der Software vorbereitete. Seine letzte Position bei IBM hieß ‚Director of Software Process and Quality‘. In dieser Funktion war er einer meiner fachlichen Vorgesetzten. Humphrey war immer sehr taktvoll gegen andere, aber gleichzeitig enorm zielstrebig und hart gegen sich selbst.

Während Mills das Heil in mathematischen Ansätzen suchte, verfolgte Humphrey einen arbeitswissenschaftlich-empirischen Ansatz. Er fragte danach, was funktioniert überhaupt und wo? Wenn eine Methode positive Ergebnisse zeitigt, sollte man sie übertragen. Er nannte dies ‚Best-of-Breed-Studien‘. Auch regte er an, dass wir unsere Prozesse mit denen von Mitbewerbern vergleichen sollten (Benchmarking genannt). So kam es zu mehreren Treffen mit den Kollegen von Siemens in München. Aus all dem entstand ein Modell der Prozessreife. Die entsprechenden Bewertungsbögen für Böblingen muss ich um 1984 herum ausgefüllt haben.

Nach seiner Pensionierung im Jahre 1986 setzte er zehn Jahre lang seine bei IBM zuletzt durchgeführte Arbeit fort, und zwar am Software Engineering Institute (SEI) der Carnegie Mellon University, Pittsburgh, PA. Er initiierte ein Software-Prozess-Programm und zeichnete unter anderem verantwortlich für die Entwicklung des Capability Maturity Model (kurz CMM) sowie des Personal Software Process (SM) und Team Software Process (SM).

Er hat nach seiner IBM-Zeit mindestens doppelt so viele Bücher geschrieben wie ich. Einige davon findet man heute in den Institutsbibliotheken führender deutscher Informatik-Institute. Ihre Titel sind am Schluss angegeben. Ihre gesamte Auflage erreicht vermutlich nicht ganz die des Bestseller eines anderen Ex-IBMers, nämlich Fred Brooks‘ ‚Mythical Manmonth‘ (geschätzte 300.000). Humphreys Bücher enthalten äußerst wertvolle Ratschläge, sowohl für die technische Seite wie für die organisatorische Seite der Software-Entwicklung. Man kann ihn am ehesten mit Barry Boehm vergleichen. Vieles was er schrieb, probierte er vorher an sich selbst aus. Seine Devise lautete: Ich kann nicht andern Leuten raten, pedantisch und rigoros zu sein, wenn ich es nicht selbst bin. In Selbstversuchen testete er so zu sagen die Medizin, die er empfahl.

Humphreys Einfluss zeigt sich heute primär bei der Vergabe und Durchführung von Software-Projekten im öffentlichen Bereich der USA. Seine Wirkung ist jedoch weltweit zu erkennen. Als ich im Jahre 1995 anlässlich einer Urlaubsreise in Neu Delhi landete, wurde ich von Werbeplakaten einer indischen Software-Firma begrüßt, die sich gerade für CMM Stufe 5 qualifiziert hatte. CMM ist Humphrey. Humphrey lebte zuletzt in Sarasota, FL, wo er starb.

Es folgt die Liste von Humphreys Büchern, und zwar ihre englische Titel, nach Erscheinungsjahr geordnet (sie sind alle bei Addison-Wesley, Reading, MA, erschienen):

 2011 Leadership, Teamwork, and Trust: Building a Competitive Software Capability.

 2010 Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself.

 2006 TSP, Coaching Development Teams.

 2006 TSP, Leading a Development Team.
 2005 PSP, A Self-Improvement Process for Software Engineers.
 2001 Winning with Software: An Executive Strategy.
 1999 Introduction to the Team Software Process.
 1997 Managing Technical People - Innovation, Teamwork and Software Process.
 1995 A Discipline for Software Engineering.

Noch eine Nachbetrachtung: Diese beiden Kollegen vertraten für mich zwei Grundrichtungen der Informatik. Mills vertrat die deduktive oder geisteswissen­schaftliche Richtung. So wie ein Philosoph sucht und findet man die Antworten zu aktuellen Fragen bei den Altmeistern. Was Aristoteles und Kant für Philosophen sind Dijkstra, Hoare und Wirth, aber auch Turing, Church, Kleene und Frege für viele Informatiker. Nur das, was die Altmeister als Problem ansahen, etwa die Struktur von Programmen, interessiert einen. Oder anders herum, man hat eine Methode und versucht Probleme zu finden, die mit dieser Methode lösbar sind. Einige prominente Vertreter dieser Denkrichtung vermitteln den Eindruck, als ob fast alle Probleme der Informatik – zumindest die mathematisch interessanten − bereits seit den 1930er Jahren gelöst seien. Was danach noch zu tun war, ist alles handwerkliche Anwen­dung von längst Bekanntem, oder schonender formuliert, Ingenieursarbeit, evtl. begleitet von aufwendiger Schulung (siehe oben!), deren Nutzeffekt allerdings hinterfragt werden darf.

Humphrey dagegen steht für den induktiven oder empirischen Ansatz. Vertreter dieser Richtung bemühen sich zunächst darum, wichtige Probleme in der Praxis zu identifizieren, also bei Entwicklern und Nutzern. Danach überlegt man, welche Methoden und Ansätze zur Lösung der Probleme beitragen können. Genauer gesagt, man analysiert, wer mit welchen Methoden die besten Ergebnisse erzielte, und prüft, welche Bedingungen geschaffen werden müssen, um dieselben Methoden anderswohin zu übertragen. Sehr bald anerkennt man, dass es kein Allheilmittel gibt, sondern dass unterschiedliche Probleme oft unterschiedliche Methoden und Hilfsmittel erfordern. Diese können aus mehreren Fachgebieten stammen. Das kann die Mathematik einschließen – muss es aber nicht. Mal hilft die Organisationslehre, mal die Psychologie, mal ist es eine Frage der Dokumentation oder der Kommuni­kation. Die Probleme hören nie auf. Es gibt immer wieder neue. Man ist bescheiden und offen für Überraschungen. Ich brauche hier nicht hinzufügen, welcher Ansatz mir mehr zusagt.

Zusätzliche Referenz

1.     Darga, K. (1985): Methodischer Programmentwurf bei IBM. In: Proebster, W.E., Remshardt, R., Schmid, H.A. (Eds): Methoden und Werkzeuge zur Entwicklung von Programmsystemen. Oldenbourg, München. 61-81