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 Grundsä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
- Broy, M.: Can Practitioners Neglect Theory and Theoreticians Neglect Practice? IEEE Computer 44,10 (October 2011), 19-24
- Parnas, D. L.: Software Engineering – Missing in Action: A Personal Perspective, ibid. 54-58
- 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.
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.
Keine Kommentare:
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.