50 Jahre Software Engineering – Erinnerungen an Garmisch 1968

Es gibt nur wenige Ereignisse, die für die Informatik als ähnlich prägend angesehen werden wie die akademische Anerkennung des Fachgebiets Software-Ingenieurwesens vor 50 Jahren. Für Historiker geschah dies in einem Hotel am Stadtrand von Garmisch im Oktober 1968. Hier wurde ein neues Fachgebiet regelrecht aus der Taufe gehoben. Zumindest erhielt es seine Weihe dadurch, dass eine Gruppe von Akademikern sich mit ihm befasste. Da an der berühmten Tagung nur etwa 60 Kollegen teilnahmen, ist die Wirkung des Ereignisses vor allem dem von Peter Naur und Brian Randell verfassten Bericht zu verdanken. Randell wurde sich der entstehenden Sagenbildung alsbald bewusst und dokumentierte seinerseits die Entstehungsgeschichte der beiden Berichte, nämlich den von Garmisch 1968 und den von Rom 1970. (Auch PDF-Kopien der beiden Berichte erhält man über diesen Link)

Kurze Vorgeschichte

Fast alle Systemprogramme und Anwendungen, mit denen ich seit 1956 zu tun hatte, kann ich nur als solide technische Produkte bezeichnen. Sie waren unter sehr starken Beschränkungen durch die Hardware entstanden, erfüllten jedoch fast immer einen ökonomischen Zweck. Im Laufe der Zeit entstanden immer bessere Hilfsmittel zu ihrer Erstellung, vor allem die so genannten höheren Programmiersprachen. Der Wunsch des Kunden, die Vielfalt der Geräte oder die Komplexität der Anwendung verlangten immer öfter, dass Programme entstanden, die nur mittels ausgefeilter Überlagerungstechnik eine akzeptable Lösung ergaben. Erst die Einführung der virtuellen Speichertechnik brachte eine Erleichterung.

Da der Bedarf an System- und Anwendungs-Software schneller wuchs als alle noch so großen Teams abdecken konnten, entstand das Schlagwort von der Software-Krise. Man lenkte damit die Aufmerksamkeit zu allererst auf ein Mengenproblem. Es könnten noch mehr Rechner eingesetzt werden, wenn es die dafür nötige Software gäbe. Dass es auch ein Qualitätsproblem gab, war nicht vordergründig und für jedermann offensichtlich. Es lag jedoch im Interesse, vor allem von akademischen Autoren, das Qualitätsproblem stärker ins Bewusstsein zu rufen als dies Praktiker taten. Eine Beratergruppe der NATO, zu der unter anderen Friedrich L. Bauer von der TU München gehörte, verstand es, Militärs für dieses Problem zu sensibilisieren. Durch unzuverlässige Software könnte die Schlagkraft des Bündnisses in Mitleidenschaft gezogen werden. Man war daher bereit ein Expertengremien damit zu beauftragen, einen Weg aus dem Software-Dilemma aufzuzeigen.

Teilnehmer und Tagungsstruktur

Die für fünf Tage angesetzte Tagung wurde von einem Triumvirat geleitet. Neben Bauer waren dies H.J. Helms von der TU in Lyngby, Dänemark, und Louis Bolliet von der Universität Grenoble in Frankreich. Drei Gruppenführer sollten die Diskussionen leiten. Sie waren nach Entwickler-Schwerpunkten aufgeteilt: Entwurf unter Alan Perlis, Carnegie-Mellon-Universität Pittsburgh, Produktion unter Peter Naur, Universität Kopenhagen und Service unter Klaus Samelson von der TU München. Nur der Begriff Produktion bedarf hier einer Erklärung. Heute würde man stattdessen Implementierung sagen, also die Überführung eines Entwurfs in ein lauffähiges Produkt. Service umfasst Verteilung, Installation und Wartung.

Die Teilnehmer verteilten sich fast mit gleichem Anteil auf Hochschulen und Industrie in Europa und Nordamerika. Viele damals in Europa ansässigen DV-Hersteller (wie IBM, ICL, CII, Philips, Siemens und Telefunken) und einige amerikanische Software-Häuser waren vertreten. Einige Beobachter des NATO-Stabes oder anderer Behörden ergänzten das Publikum.

Herkunft der Teilnehmer

Zu jedem der drei Schwerpunkte gab es schriftlich eingereichte Stellungnahmen und/oder Impulsvorträge, gefolgt von Plenumsdiskussionen. Alle Veranstaltungen fanden im selben Saal statt. Nur für die Mahlzeiten wechselte man die Räume.

Meine Teilnahme und IBMs Reaktion

Teilnehmen konnte man nur auf Einladung der Tagungsleitung. Meine Einladung verdankte ich Louis Bolliet, den ich aus unserer gemeinsamen Zeit aus New York kannte. Leider war es mir nicht möglich, mir eine ganze Woche freizunehmen. Für Mittwoch hatte sich der IBM-Direktor für Software-Planung angemeldet, der leider früh verstorbene Ted Climis. Ich fuhr also Dienstags Abend nach Hause und am Mittwoch wieder zurück. Als ich Climis sagte, wo ich den Rest der Woche verbrachte, gab es die folgende Belehrung; ‚Sie verschwenden Ihre Zeit. Bilden Sie sich ja nicht ein, dass Hochschulleute Ihnen etwas Brauchbares zum Thema Software-Entwicklung sagen können. Das ist ein industrieller Prozess so wie die Chip-Entwicklung. Da können Hochschulen uns auch nichts sagen.‘ Climis war ein Hüne. Sein Wort hatte Gewicht in der ganzen Firma. Ich fuhr dennoch zurück.

Verlauf und Ergebnisse

Wie eingangs erwähnt, ist diese Tagung ungewöhnlich gut dokumentiert. Ich will daher nicht wiederholen, was anderswo leicht zu erfahren ist. Es waren nicht die normalen Vorträge über akademische Projekte, die mich beeindruckten, noch die spontanen, teils sarkastischen Einwürfe einiger besonders lautstarker Typen.

Einen sehr positiven Eindruck hinterließ bei mir Doug McIlroy. Er war damals Leiter eines Entwicklungsprojekts bei den Bell Laboratories in New Jersey. Er plädierte für die systematische Wiederverwendung von Software durch Baustein-Bibliotheken. Sein Vortrag hieß ‚Mass Produced Software Components‘. McIlroy schlug vor, denselben Weg zu gehen, mit dem die Hardware-Kollegen Erfolg hatten. Zuerst sollte man die Standardfunktionen definieren, die benötigt würden, um daraus große Systeme zusammenzufügen. Dann sollte man von jedem Baustein endlich viele Varianten anfertigen, mal zeit-, mal platzoptimiert, so dass sie unterschiedliche Anforderungen abdecken. Genau diese Idee wandten wir anschließend in Böblingen an, um eine Bibliothek von Bausteinen zu entwickeln, mit denen wir einige Jahre lang großen Erfolg innerhalb der Firma hatten. In den 1990er Jahren gab es einige Alternativ-Vorschläge, die die komponenten-basierte Entwicklung an den Rand drängten. Gemeint sind Muster (engl. pattern) und Plattformen.

Großen Eindruck bei den anwesenden Zuhörern hinterließ der Kollege John Nash aus dem IBM Labor in Hursley, England. Er stellte de facto das Material zur Verfügung, das damals firmenweit zur Schulung von Mitarbeitern in der Software-Entwicklung verwandt wurde. Zum ersten Mal sahen viele der Teilnehmer, vor allem die Hochschulvertreter, welche Faustregeln, Grafiken und Modelle IBM-intern eingesetzt werden. Auch die Kollegen des Forschungslabors in Yorktown Heights, NY, (Andy Kinslow, Ascher Opler, Brian Randell) gewannen Aufmerksamkeit, da sie ausführlich über die Software-Untersuchungen und Modellierungen berichteten, die dort vorgenommen wurden.

Von den akademischen Teilnehmern beeindruckten mich vor allem Alan Perlis und Edsger Dijkstra. Sie trugen weniger Fakten und Daten bei, als wohlüberlegte, teils pointierte Bemerkungen zu den Problemen, die sie erlebt hatten. Einige Dinge, die behandelt wurden, hatten nur einen sehr temporären Charakter. So befasste man sich einen halben Tag lang mit der Frage, ob es sinnvoll sei, Software als kostenpflichtiges Produkt unabhängig von der sie ausführenden Hardware zu verkaufen. Anwesende Vertreter von Software-Häusern konnten sich nicht für die Schöngeister erwärmen, die dafür warben, Software als ‚geistiges Gut‘ anzusehen und nur zu verschenken. Wenige Monate später verkündigte die Firma IBM ihr ‚Unbundling‘. Sie berechnete fortan Software-Produkte separat, reduzierte aber die Hardware-Preise nur geringfügig.

Nachwirkungen und Bewertung

Die Garmischer Tagung hatte ein ganzes Bündel von Nachwirkungen. Sie wirkten auf den verschiedensten Ebenen. Besonders ins Auge fallen mehrere wissenschaftliche Tagungsreihen, die entsprangen. Am bekanntesten ist die International Conference on Software Engineering (abgekürzt ICSE) der IEEE, die seither im 2-jährigen Zyklus stattfindet. Daneben gibt es das European Symposium on Software Engineering (ESEC), ebenfalls alle zwei Jahre, sowie die jährliche Tagung über Software Engineering der Gesellschaft für Informatik (GI). Zusätzlich zu den in den Tagungsbänden veröffentlichten Beiträgen gibt es mehrere neugegründete Zeitschriften, die sich dem Thema Software Engineering widmen, so die IEEE Transactions on Software Engineering.

Die vielleicht größte Nachwirkung bestand darin, dass das Fachgebiet Computerwissenschaften (engl. computer science) entweder umdefiniert oder aufgeteilt wurde. Überspitzt gesagt, die einer Naturwissenschaft nachempfundene Computerwissenschaft wurde um eine Ingenieur-Auffassung ergänzt oder von dieser abgelöst. Es wurde an vielen Hochschulorten der Welt, vor allem aber in den USA, ein zweiter Studiengang eingerichtet. Da in Deutschland mit der Informatik ein anderes Verständnis vorherrscht als im angelsächsischen Raum – darauf einzugehen würde hier zu weit führen – bestand die Notwendigkeit einer Umorientierung nicht. Lediglich die Universität Stuttgart ging diesen Weg. Hier gibt es heute neben der Informatik den Studiengang Softwaretechnik. In ihm findet – anders als der Name suggeriert – keine Beschränkung auf Software statt, sondern nur eine stärkere Betonung der ‚konstruktiven Aspekte‘.

Nach meiner Meinung ist diese Aufteilung, die die Informatik erfuhr, zu bedauern. So wichtig es auch ist, die Bedeutung und die Eigenart von Software zu erklären und zu betonen, so kann dies auch erfolgen unter Beibehaltung des Namens Informatik. Anders ausgedrückt, es tut der Informatik als Ganzer gut, sich stärker mit Software zu befassen. Software ist das Neue, die Technik, die den Fortschrift bestimmt. Software ohne Hardware zu lehren oder zu betrachten, führt dazu, dass suboptimale Lösungen entstehen, oder aber dass der Boden der Realität verlassen wird.

Fachliche Weiterentwicklung des Feldes

In den letzten 50 Jahren hat sich das, was man unter Software Engineering versteht, signifikant weiterentwickelt. Ich kann längst nicht alle Facetten beleuchten. Ich gebe nur einige Schwerpunkte an. Das Ziel, Software mit systematischen Verfahren zu entwickeln und zu bewerten, fand überall großen Anklang. Unter anderem sah sich das amerikanische Militär veranlasst, seine Aktivitäten stärker zu bündeln. Da die Raumfahrt ohnehin in Fragen der Softwaretechnik einsame Spitze darstellte, zogen Heer, Marine und Luftwaffe nach und gründeten ein Software Engineering Institute (SEI) an der Carnegie-Mellon-Universität in Pittsburgh. Für die technische Leitung gewannen sie meinen früheren IBM-Kollegen Watts Humphrey (1927-2010). Er setzte die bei IBM begonnene Arbeit fort und initiierte ein Software-Prozess-Programm. Zwischen 1986 und 1996 zeichnete er unter anderem verantwortlich für die Entwicklung des Capability Maturity Model (kurz CMM) sowie den Personal Software Process und den Team Software Process.

Humphrey schrieb fast ein Dutzend Bücher, die seine Verfahren begründeten und illustrierten. Einige davon findet man heute in den Institutsbibliotheken führender deutscher Informatik-Institute. 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. Vieles was er schrieb, probierte er vorher an sich selbst aus. Ein weiterer IBM-Kollege, der sich für die gesamte Branche verdient machte, ist Capers Jones (*1933). Er sammelte Produktivitätsdaten von über 12.000 Projekten von 600 Firmen auf der ganzen Welt, bereitete die Daten auf und bot sie für Vergleichszwecke an. Auch er führte im Ruhestand Arbeiten fort, die er während seiner aktiven IBM-Zeit begonnen hatte.

Finanzielle Geschichte eines SW-Projekts

Zwei Kollegen, die von Praktikern wegen ihrer Beiträge hoch geschätzt werden, sind Barry Boehm (*1935) und Dave Parnas (*1941). Boehm erfand die Methode COCOMO zur Softwarekostenberechnung, das risiko- und kostensenkende Spiral-Vorgehensmodell und eine erweiterte Delphi-Methode (wideband delphi). Parnas verdanken wir das Geheimnisprinzip (Datenkapselung), das eine wesentliche Grundlage der heutigen objektorientierten Programmiersprachen ist. Er engagierte sich gegen das SDI-Programm der USA, ein Raketenabwehr-Projekt, dessen technische Grundlagen sehr unsicher waren.

Dass die Kosten der Software-Entwicklung sowie die Qualität des Produkts erhöhte Aufmerksamkeit erfuhren − auch in akademischen Kreisen − war damals  allgemein zu begrüßen (und ist es auch heute noch). Software-Projekte brauchen kein Abenteuer mehr zu werden. Sie sind planbar, vorhersehbar und kontrollierbar. Nicht ganz denselben Grad an Interesse erreichte bisher das Bemühen, den Wert von Software zu ermitteln. Der Wert ergibt sich aus den Geschäftsmodellen, die verfolgt werden. Davon gibt es viele. Den Wert mit dem Umsatz gleichzusetzen, den man durch Verkauf des Produkts erzielen kann, ist nur eines von vielen. (In einem Blog-Beitrag des Jahres 2016 wurde dieses Thema behandelt)

Ausblick und Fragen

Fast scheint es, als ob die Ziele und Ambitionen, die man mit dem Software Engineering verbindet, beim alten Eisen gelandet sind. Die moderne Zeit hat sie scheinbar überrollt. Das gilt zumindest in zweierlei Hinsicht. Die strenge und systematische Vorgehensweise wird vielfach als Ballast empfunden, den man gern abwirft. Anstatt umfassender Planung bevorzugt man heute wieder das iterative Vorgehen. Man sticht quasi an einer Stelle durch, liefert einen Prototypen aus und verbessert diesen. An die Stelle von ‚clean development‘ tritt ‚lean development‘ oder ‚smart development‘. Die Entwicklungsdauer (engl. time to market) hat in der Regel Vorrang vor Qualität, Kosten, Benutzbarkeit, usw.

Ein anderes Phänomen stellt das Geschäftsmodell und die Marktmacht von Firmen wie Google dar. Ihr Suchdienst wirft derart hohe Gewinne ab, dass sie den eigentlichen Software-Markt total unterlaufen können. Sie ruinieren alle Preise, die man für Software als Produkt erzielen kann, indem sie damit drohen, jedes beliebige Software-Produkt der Welt kostenlos anzubieten. Das ist kein Grund, den Untergang der Software-Industrie vorherzusagen. Jeder muss schließlich das Geschäftsmodell finden und verfolgen, dass ihn trägt.

PS: Sehr lesenswert sind die vor kurzem erschienenen Berichte von zwei Nicht-Teilnehmern der Garmischer Tagung, von Barry Boehm und Manfred Broy.