Software Engineering – nur unerfüllte Erwartungen? (mit mehreren angefügten Kommentaren)

Beim Software Engineering ist es nicht anders als sonst im Leben. Ob Erwartungen oder Wunschträume erfüllt oder nicht erfüllt werden, hängt davon ab, was man erwartet oder erträumt hatte. Maßgebliche Autoren sind nur mit mehr oder weniger qualitativen Aussagen belegt. So sprach F. L. Bauer immer von der ‚Entdeckung und Anwendung solider Ingenieurprinzipien‘. Ernst Denert forderte die ‚Anwendung wissenschaftlicher Erkenntnisse‘. Jochen Ludewig forderte eine Umorientierung vom analytischen zum konstruktiven Denken. Wie er mir sagte, hätte er nichts dagegen, wenn sich die ganze Informatik stärker zur Ingenieurwissenschaft  – also zur Kultur 1 im Sinne meiner in diesem Blog beschriebenen drei Kulturen – bekennen würde. Dies sei leider nicht zu erwarten, deshalb sei es sinnvoll, mit Software Engineering ein Kontrastprogramm zu schaffen.

Es gab in den letzten 54 Jahren – solange ist es schon her seit Garmisch – wahrlich keinen Mangel an Interesse und Bemühungen. Viele Konferenzen wurden dem Thema Software Engineering gewidmet, mit Tausenden von Teilnehmern. An Büchern und Veröffentlichungen besteht kein Mangel. Auch die Ausbildung an Hochschulen und außerhalb kam in die Gänge. Dennoch hält die Diskussion um Sinn und Zweck des Fachgebiets Software-Engineering an. Es sind sogar ganz unterschiedliche Gründe, die ins Feld geführt werden. Manche Kollegen wollen kein gutes Haar an dem Erreichten lassen, obwohl sie selbst Teil der Gemeinde zu sein scheinen.

Während manche Leute glaubten, dass durch bessere mathematische Ausbildung alles ins Lot kommt, forderten David Parnas [2] und andere eine behördliche Zulassung, für deren Erreichen relevantes Fachwissen (engl. body of knowledge) nachgewiesen werden muss. Ein wirklicher Erfolg würde von vielen erst dann gesehen, wenn die Anerkennung von Software-Entwicklern als Ingenieure außer Frage stünde. Dass dies noch nicht der Fall ist, drückt Parnas immer wieder wortreich aus, etwa im Vergleich mit einer nicht-vollzogenen Ehe (engl. unconsummated marriage) zwischen Ingenieuren und Programmierern, zwischen Wissenschaft und Technik. Als Heilmittel empfiehlt er einerseits eine noch stärkere Mathematisierung, andererseits die ernsthafte Konzentration auf Methoden, die sich in der Praxis bewährt haben. Letzeres klingt nach noch stärkerer Betonung von Kultur 1, also der Ingenieurseite.

Manfred Broy [1] scheint eher die Probleme auf der naturwissenschaftlichen Seite, also Kultur 2, betonen zu wollen. Er sieht es als Manko an, dass immer noch die Theorien fehlen, die erklären, warum gewisse Methoden in der Praxis funktionieren oder nicht funktionieren. Trotzdem werden diese Methoden gelehrt und benutzt. Manchmal sind sie durch empirische Daten abgesichert – aber leider oft nicht einmal das. Da sind viele ältere Ingenieur-Disziplinen nicht immer besser dran, und haben dennoch keine Anerkennungsprobleme. Sehr erfreulich ist, dass er Theorie nicht mit mathematischen Formalismen gleichsetzt, wie das manche Kollegen tun. Er fordert von Software-Ingenieuren ‚wissenschaftliches Wissen‘ in Mathematik, Ökonomie und Soziologie (!) sowie ‚praktisches Wissen‘. Er lässt allerdings offen, was er darunter versteht. Von Können spricht er nicht.

Ohne diesen Fragekomplex zu vertiefen, möchte ich auch – wie es so schön heißt – meinen Senf dazu geben und auf einige Defizite hinweisen, die in der bisherigen Diskussion wenig beachtet wurden. Oder anders gesagt, vielleicht hätte man das Ziel durchaus noch etwas höher setzen können. Ich wiederhole dabei einige Dinge, die schon früher gesagt wurden.

(1) Wenn man Software-Entwicklung mit dem Schreiben von Romanen oder Theaterstücken vergleicht, sehen sich viele Software-Ingenieure (sowohl an Hochschulen wie in der Industrie) nicht primär als Autoren. Statt durch Tun zu überzeugen, reden sie nur. Sie sehen sich quasi als Literaturkritiker, und auch das sehr eingeschränkt. Sie kritisieren nicht die Produkte einzelner Autoren (oder Autorenkollektive), sondern nur deren Schreibstil und ihre Arbeitsmethoden. Ihnen missfallen die Vorbilder, Metapher und Hilfsmittel, deren sich Autoren (also Programmierer) zurzeit bedienen. Wer ein Orthografie-Programm benutzt oder ein Online-Phrasen-Lexikon, kann seinen Ruf als Kreativer verlieren. Die sprachliche Notation eines Quellprogramms wird oft als entscheidend betont. Dabei verbessert sich dadurch eventuell seine Lesbarkeit. Das hilft sowohl dem Autor als auch andern Entwicklern, sagt aber nichts aus bezüglich seiner Qualität, Originalität und Relevanz für die Nutzer. Der Semikolon-Krieg, wie dies ein Physiker einmal nannte, lenkt Informatiker leider (immer noch) von wirklich wichtigen Fragen ab. 

(2) Ingenieure lieben es, zu erfinden. Ihr Ruf basiert auf Kreativität. Studenten der Informatik sollten lernen, was erfinden heißt. Sie sollten angehalten werden, neue nützliche Ideen zu suchen. Man muss echte Probleme finden und lösen, statt sie zu umgehen. Nur wer etwas Neues wagt, gewinnt. Imitieren ist nicht ausreichend. Bereits vor über 10 Jahren schrieb Endres [3] hierzu:

Bei Berufungen in der Informatik sollten Art und Anzahl der Patente mindestens so hoch angerechnet werden wie andere Publikationen. „Erfinden lernen“ könnte durchaus ein weiteres Ausbildungsziel für die Studierenden sein. … Junge Erfinder sollten lernen, wie man sich gegenüber dem Stand der Kunst abgrenzt und wie man seine eigenen Ansprüche verständlich macht. … Will [Informatik] sich als Ingenieurwissenschaft profilieren, kann sie nicht vorwiegend Entdeckungen anstreben wie Astronomie, Mathematik oder Physik. Erfindungen von Informatikern jedoch alle als trivial anzusehen, dagegen sollten wir uns energisch wehren.

Wie in diesem Blog gezeigt, hat die Software-Industrie ihre Lektion in Bezug auf Software-Patente längst gelernt. Bei den Hochschulen scheint weiterhin himmlische Ruhe und Desinteresse zu herrschen. Die beiden bisher genannten Punkte reichen schon aus, um zu erklären, warum es kaum gute Software aus Europa gibt.

(3) Endres/Gunzenhäuser haben sich 2010 mit einem kleinem Büchlein bemüht, Informatikerinnen und Informatiker für die Wirkung ihrer Tätigkeit auf die Mitmenschen zu sensibilisieren. Auch Broy/Endres betonten erst kürzlich, dass der Wert unserer Arbeit für Menschen mehr als nur eine Nebensache sei. Ein Kollege meinte dazu, Lebensqualität sei doch das Thema von Willy Brand in seinem Wahlkampf gewesen. Ob wir jetzt Politikern Konkurrenz machen wollten. Die Professionalität und der Berufsethos sind keine Themen, die von Politikern oder selbsternannten Gutmenschen an uns herangetragen werden müssen. Wir müssen sie selbst mit Inhalt erfüllen, wollen wir das Image des Fachidioten oder Nerds loswerden. Diese Grund­sätze betreffen auch nicht nur eine Elite, sondern gelten für Alle. Entsprechende Bekenntnisse gehören nicht nur in Sonntagsreden, sondern müssen den Alltag bestimmen. Vor allem geht hier Handeln vor Reden.

(4) In Deutschland hat sich die Mathematik zweifelsohne große Verdienste um den Aufbau der Informatik-Studiengänge erworben. Wenn wir uns auf Ingenieure verlassen hätten, wären wir heute längst nicht soweit. Man kann sagen, dass die Ingenieure uns nicht als eigenes Fachgebiet brauchten, die Mathematiker schon eher. Jetzt ist es an der Zeit sich von der Bevormundung durch die Mathematik zu emanzipieren. Es ist ihre Terminologie und ihre Denkweise, die oft Schaden anrichten. Immer wieder wird – selbst von erfahrenen Kollegen – der verhängnisvolle Fehler gemacht, von der Mathematik Theorien, also Erklärungen von Beobachtungen, zu erwarten, wo sie allenfalls Techniken oder Methoden liefert. Das bekannteste Beispiel sind die so genannten Formalen Methoden, die eher die Dinge verdecken als erklären.

(5) In einem früheren Beitrag dieses Blogs wurde auf die Tendenz zur Zersplitterung des Fachgebiets Informatik hingewiesen. Ich nannte es dort in Anlehnung an einen politischen Begriff die Balkanisierung der Informatik. Dort hieß es:

Dennoch gibt es bei uns auch ein gewisses Maß an Zersplitterung. Zum Glück verwenden alle Zweige das Wort Informatik als Stamm. Das gilt für Wirtschafts-, Bio-, und Medieninformatiker, aber auch für medizinische, technische und praktische Informatiker. Nur das bisher erst an einer einzigen Hochschule eingeführte Fach Softwaretechnik benutzt das Wort Informatik nicht…

Man muss sich fragen, für wen die Sektiererei und das Zerbröseln eines Fachgebiets von Nutzen sein kann. Die Praktiker sind es nicht. Akademiker möchten oft die Ersten sein, wenn es darum gilt, neue Spezialgebiete aus der Taufe zu heben. Das ist auch dann sinnvoll, wenn nur fünf Leute auf der Welt es betreiben.

Zum Schluss möchte ich noch einen etwas abenteuerlichen Gedanken loswerden. Um bezüglich der Anerkennung der Ingenieurseite der Informatik einen neuen Anlauf zu nehmen, könnte es sinnvoll sein, über einen neuen Namen nachzudenken. Dabei müsste das Wort Ingenieur natürlich im Namen vorkommen, da dies ja fast fetischhafte Bedeutung zu haben scheint. Mein Vorschlag lautet daher: Informatik-Ingenieur. Der wäre zuständig für Entwicklung und Pflege von Informatiksystemen und nicht nur für deren Software. Es wäre dies sprachlich gesehen eine Parallele zum Mathematik-Ingenieur, einer Fachrichtung, die schon Edsger Dijkstra als interessanten Ansatz lobte. Für das zugehörige Fachgebiet kann der Name (praktische) Informatik bleiben, da damit die unselige Abgrenzung, die das Software Engineering nach sich zieht, vermieden werden kann.

Zusätzliche Referenzen

1. Broy, M.: Can Practitioners Neglect Theory and Theoreticians Neglect Practice? IEEE Computer 44,10 (October 2011), 19-24
2. Parnas, D. L.: Software Engineering – Missing in Action: A Personal Perspective, ibid. 54-58
3. Endres, A.: Wem nützen und wem schaden Software-Patente? Informatik Spektrum 24,1 (2001), 19-24

Am 27.4. um 17:24 Uhr schickte Hartmut Wedekind aus Darmstadt folgenden Kommentar, den er 'fröhlich auf der Terrasse sitzend verfasst' hatte.

Engineering?

Im Gegensatz etwa zur Tätigkeit eines Arztes ist das „Engineering“, die Ingenieurtätigkeit, auffallend terminologisch unbestimmt. Einfach wie früher von  Anwendungen der Physik und Chemie zu sprechen,  zielt heute gewaltig  daneben. Also was ist das, das „Engineering“? Gibt es überhaupt eine begriffliche Festlegung und eine Gemeinsamkeit, die alle, noch so vielfältigen Ingenieurtätigkeiten  miteinander verbindet?

Aus meiner Sicht ist die herausragende Gemeinsamkeit aller Ingenieurtätigkeiten eine Konstruktivität. Das will sagen, dass der Begriff  „Konstruktion“ im Mittelpunkt steht. Ob es sich dabei um eine Neukonstruktion, Rekonstruktion oder Nachkonstruktion handelt, soll für uns unerheblich sein.

In seinem Aufsatz „Rekonstruktion und Rationalität“ (in: O. Schwemmer: „Vernunft, Handlung, Erfahrung“, München 1981) schlägt  Friedrich Kambartel vor, das Wort Konstruktion als einen Terminus der Handlungstheorie  zu verstehen. „Handlungstheorie“ als Begriff stammt aus der „Kultur 3“ und ist  dem Ingenieur  in „Kultur1“nicht geläufig.  Gemeint ist, so Kambartel, dass wir durch eine Konstruktion, definitionsgemäß, systematisch zusammenhängende Handlungen schrittweise aufbauen. Das Wort Handlung wird dabei schema- oder typ-bezogen verwendet und steht im Sinne Chomsky’s für Handlungskompetenzen, also nicht für deren Aktualisierung  im konkreten Einzelfall. In einem zweiten Gebrauch des Wortes „Konstruktion“ , so Kambartel, wollen wir  sagen, wie wir bestimmte Handlungsschemata  in einer systematischer Ordnung  aufbauen.

Hervorzuheben ist bei Kambartel das Wort (1) „schrittweise“. Für eine  Konstruktivität  gibt es aber noch zwei weitere  Merkmale, und das sind (2) „ Alles-explizit-machen“ und  (3) „keine Zirkularität“. Wenden wir uns zunächst dem zweiten Kriterium zu, dem Explizit-machen.

Wenn  wir  die miserablen Dokumentationen und Gebrauchsweisungen sehen, können wir unmittelbar grobe Verstöße gegen das Gebot der Explizitheit  konstatieren. Ein Benutzer ist z.B. im Allgemeinen bei nur implizit definierten Schnittstellen „bedient“, weil er durch Probieren herausfinden muss (just do it), welchen Zustand „die Herrn da auf der anderen Seite“ still voraussetzen. „It is tacitly assumed“ heißt es manchmal verräterisch, hinten angehängt, in einem Glossar.

Systematisch ist aber das „Nicht-explizit-machen“ in der Software-Informatik vorhanden, wenn z.B. abstrakte Datentypen in mathematisch-algebraischer Methode auf axiomatische Weise eingeführt werden. Moderne  Axiome definieren bekanntlich nach dem großen Mathematiker David  Hilbert  gewollt nur implizit einen Begriff. So entsteht das Pur-Formale. Und in Hilbertscher Manier übernimmt man nun im Software Engíneering seit John Guttag (1977) den Hilbertschen Ansatz und ignoriert völlig die bekannte Auseinandersetzung mit Gottlob Frege, der den großen David Hilbert, den Mathematiker-Papst, wegen seiner Impliziertheiten ziemlich unsanft vorführte.

http://uci.academia.edu/KaiWehmeier/Papers/433876/Aspekte_der_Frege-Hilbert-Korrespondenz.

Implizitheit ist also nicht nur  eine  häufig kritisierte Schlamperei der Praktiker. Sie ist somit auch immanent im Software Engineering angelegt. Der schlechte Ruf des Teilfaches „Software Engineering“, den Endres hervorhebt und beklagt, ist vielleicht auch so zu erklären.  Explizites  „Engineering“ und  axiomatische Methoden stehen sich gegenüber wie Katz und Maus  und fauchen  bzw. bellen sich gegenseitig aus verständlichen Gründen an. Implizite Axiomatik ist für Ingenieure per se artfremd. Axiomatik der Hilbertschen Art versteht man nicht, weil es gegen konstruktives Denken verstößt. Verstöße werden als abartig empfunden.

Kommen wir zur Zirkularität. Zirkulär sein heißt, man setzt etwas voraus, was noch nicht   definiert oder beschrieben wurde. In anderer Formulierung spricht man auch von einem Verstoß gegen das Prinzip der pragmatischen Ordnung. Wolkenkuckucksheime  und bloße Euphorie sind dem Engineering ein Gräuel. Ein „wishful thinking“ oder „nice to have it“ überlässt man gerne defizitär denkenden Politikern der Neuzeit

Was ist nun Software Engineering? Ganz einfach: Wenn Engineering eine begriffliche Gattung ist, dann ist Software Engineering eine begriffliche Art dieser Gattung. Und  der artbestimmende Begriff „Software“  ist leicht einzuführen, wenn man weiß, was Hardware ist.

Nachtrag am 28.4.2012, 12 Uhr:

Herrn Wedekinds ‚fröhlich verfasster‘ Kommentar zeigt mal wieder, wie leicht man missverstanden werden kann. Ich wollte nicht den Stand des Software Engineering beklagen, sondern zum Ausdruck bringen, wie schwer wir Software-Ingenieure (aber auch andere Ingenieure) es manchmal haben, es allen Recht zu machen.

Folgt man Parnas, dürfte kein Donald Page, Jeff Bezos, Mark Zuckerberg oder Steve Jobs je ein Programm in die Welt setzen, bevor nicht der Gouverneur von Texas (und die aller anderen Bundesstaaten) ihnen dies erlaubt hätten. Laut Broy hätten weder James Watt eine Dampfmaschine noch Werner von Siemens einen Dynamo bauen dürfen, da sie beide keine Theorie hatten, warum das Gerät funktioniert.

Um ‚Not zu lindern‘, müssen Ingenieure handeln können. Dabei können auch kleine Schritte sinnvoll sein. Sie müssen sich allerdings fragen lassen, ob der Nutzen des Handelns die Nebeneffekte auch deutlich überschreitet. Nebeneffekte gibt es fast immer. Sie sind unvermeidbar, selbst bei Nichtstun. Sie heißen dann nur anders.

Die Äußerungen von Herrn Wedekind zeigen auch, dass man sich Gedanken machen muss darüber, was Benutzbarkeit bei komplexen technischen Geräten (oder Programmen) heißt. Das A und O ist es, möglichst wenig ‚explizit‘ zu machen. Mein letzter Mercedes hatte keine Gangschaltung und keine Drehzahlanzeigen. Er traf  Entscheidungen, die in 90% der Fälle besser waren, als wenn ich sie getroffen hätte. Natürlich kostet es viel Ingenieurschweiß, die richtige Auswahl der Parameter zu treffen, die frei bleiben müssen. Bei den andern müssen die richtigen Werte gefunden werden, die man voreinstellen darf. In den von Wedekind beklagten Fällen werden die System-Entwickler entweder lernen oder untergehen.

Am 2.5.2012 schrieb Rul Gunzenhäuser aus Stuttgart:

Ihrem letzten Blog Post entnehme ich, dass Sie für viele unserer Informatikabsolventen den Titel "Informatikingenieur" passend fänden. Dieser Begriff ist allerdings nicht ganz neu. 

Die ETH Zürich ist für Ihre Pionierleistungen im Bereich der Computerwissenschaften sehr bekannt, erinnert sei an Entwicklungen wie ERMETH und LILITH. Eine Informatikausbildung begann dort aber relativ spät. Erst im Herbst 1981 wurden mehr als 110 Studierende in den neuen Studiengang Informatik aufgenommen, der von der Abteilung Informatik (dem heutigen Department Informatik/Computer Science) durchgeführt wurde. Ich erinnere mich gut an die Eröffnungsveranstaltung, wo ich auf Einladung von Prof. Dr. Carl August Zehnder über Erfahrungen in den deutschen Informatikstudiengängen, auch am Beispiel Stuttgart, berichten durfte. 

Herrn Zehnder und seinen Kollegen war es sehr wichtig, dass die Absolventen den Titel "Informatikingenieur", also Dipl.-Ing. der Fachrichtung Informatik, tragen werden. Sie haben das damals sehr gut begründet. Allerdings war die ETH Zürich eine der ersten europäischen Universitäten, die die Bologna-Reform umgesetzt hatte. Seit ungefähr zehn Jahren tragen die Absolventen die Titel BSc ETH CS und MSc ETH CS, wobei CS für Computer Science steht. Die an der ETH ausgebildeten Lehrer werden weiterhin im "Lehramt Informatik" geprüft.

 

Am 16.5.2012 schrieb Walter Tichy aus Karlsruhe:

Sie hatten sich [bei diesem Blog Post] wegen angeblich mangelnder Anerkennung für Softwaretechniker gesorgt. Ich glaube, diese Sorge ist völlig unbegründet. Schauen Sie sich die folgende Botschaft von ACM Technews an, wonach Softwaretechniker der beste Job ist.

„A recent  CareerCast.com study ranked software engineer as the top job for 2012 based on five criteria, including salary, stress levels, hiring outlook, physical demands, and work environment. Software engineer ranked higher than doctor, Web developer, computer programmer, and financial planner due to tremendous demand and outstanding salary...”

Das gilt streng genommen nur für die USA. Aber Sie können auch die Stellenanzeigen der beliebtesten Arbeitgeber Deutschlands anschauen (Audi, BMW, Siemens, Porsche, Daimler, Volkswagen, Lufthansa Technik) und da werden überall Softwareentwickler gesucht. Von Akzeptanzproblemen für Softwareentwickler keine Spur! Sie wissen: als Empiriker sind mir Daten und Fakten wichtiger als Vermutungen.

Am 18.5.2012 antwortete ich:

Vielen Dank für den Kommentar. Sie haben vollkommen Recht, dass in Deutschland wieder ein Mangel an Software-Entwicklern besteht. Das ist aber ein anderes Thema als das, was Parnas und Broy im Oktober-Heft von ‚Computer‘ anschnitten. 

In den USA scheint durch die Berufsbezeichnung ‚Software Engineer‘ die Bezeichnung ‚Programmer‘ abgewertet und verdrängt worden zu sein. Dennoch macht sich Parnas große Sorgen über die Anerkennung durch andere Ingenieure. Da ich selbst Ingenieur bin, muss ich gestehen, dass Parnas ein stark idealisiertes Bild von ‚dem Ingenieur‘ zu haben scheint.

Bei uns in Deutschland gab es einen ‚Verdrängungs-wettbewerb‘ zwischen den Bezeichnungen ‚EDV/IT-Spezialist‘ und ‚Informatiker‘. Den scheint der ‚Informatiker‘ gewonnen zu haben. Der ‚Software-Ingenieur‘ kommt als Berufsbezeichnung bei uns kaum vor. Die Übersetzung ‚Software-Techniker‘ halte ich für einen glatten Fehlgriff. Ein Bautechniker ist etwas anderes als ein Bauingenieur. Ein Elektrotechniker ist kein Elektroingenieur, usw. Die Bezeichnung ‚Software-Entwickler‘ ist genau wie SAP-Spezialist eher eine Tätigkeitsbeschreibung als eine Berufskategorie.

Um Ihren berechtigten Wunsch nach Fakten zu befriedigen, habe ich heute die Stellenangebote einer im Internet vertretenen Jobbörse (StellenMarkt.de) analysiert. Es sind die Angebote für die letzten 21 Tage für Deutschland, Österreich und die Schweiz. Hier das Ergebnis:

Fachgebiet ist hier als Arbeitsgebiet aufzufassen. Auffallend ist, dass dabei der Begriff Informatik überhaupt vorkommt. Er ist als Sammelbegriff für unterschiedliche Tätigkeiten zu sehen. Interessant ist, dass in 7037 Angeboten (95%) Kenntnisse in Informatik gewünscht sind. Ganze 43 Angebote (0,6 %) erwarten Software-Ingenieure.