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.

Modellieren, spezifizieren oder lieber gleich programmieren?

Ein Kommentar meines Kollegen Manfred Broy zu dem Beitrag über Spezifizieren und Abstrahieren in diesem Blog überraschte mich etwas. Er lautete:

Ich denke, was Sie in dem Artikel vielleicht wirklich interessieren muss, ist weniger das Thema Spezifikation als das Thema Modellierung. Viele Anstrengungen der Wissenschaft bestehen darin Modelle aufzustellen, die natürlich immer mit den Fragen verbunden sind, wie stark sie den Gegenstand, den sie modellieren und damit die Wirklichkeit korrekt wiedergeben.

In besagtem Beitrag ging es um die Spezifizierung von dynamischem Verhalten und Interaktionen, also von Algorithmen, Programmen, Prozessen oder dynamischen (biologischen oder physikalischen) Systemen. Modellieren wird in der Tat mitunter als Alternative zum Spezifizieren gesehen. Dies halte ich nicht für richtig. Das ganze Gebiet der Datenmodellierung wird hier von der Betrachtung ausgeschlossen. Es unterliegt völlig andern Gesetzen. Wie so oft, ist selbst unsere Fachsprache zu undifferenziert und suggeriert Gemeinsamkeiten auch da, wo kaum welche gegeben sind. Vollkommen verwirrend wird die Situation, wenn auch noch gleichklingende Begriffe aus der Mathematik ins Spiel gebracht werden.

Ausgewählte Begriffe

Ehe ich die Vor- und Nachteile verschiedener Ansätze diskutiere, will ich kurz mein Verständnis der relevanten Begriffe erläutern. Dabei beschränke ich mich strikt auf die Bedeutung der Begriffe in der praktischen Informatik.

Ein Modell ist ein beschränkte Abbildung des Verhaltens und Handelns, wobei bestimmte Aspekte außer Acht gelassen sind. Gegenstand eines Modells kann ein physikalisches, biologisches oder technisches Objekt, Gebilde oder System sein. Weggelassen werden solche Details, die für die aktuelle Fragestellung nicht relevant sind. Ein anderer Grund für das Weglassen kann Zeitnot, Aufwand, Nichtwissen oder freiwillige Beschränkung wegen Informationsüberflutung (engl. Information overload) sein. Gerade der letztere Grund ist bei großen technischen Systemen, z.B. Software-Systemen, der überwiegende. Nur so besteht eine Chance, die Systeme gedanklich zu durchdringen und (einigermaßen) in den Griff zu bekommen. Da Informatiker den Computer sehr oft auch in Bezug auf sein soziales Umfeld betrachten, versuchen sie manchmal auch das aktive Handeln von Menschen zu modellieren. Es kommt dann zu betrieblicher, wirtschaftlicher oder soziologischer Modellierung.

Ein Programm ist eine teilweise oder vollständige Implementierung eines dynamischen Systems. Es ist ein Text oder eine Grafik, die von einem programmgesteuerten Rechner direkt (d.h. im Maschinencode) oder indirekt (d.h. durch ein anderes Programm) interpretiert wird und, als Konsequenz davon, eine (Rechen-) Maschine steuert. Bei der teilweisen Implementierung ist bekannt, für welche Werte der Eingabeparameter oder Parameterkombinationen das System noch nicht reaktionsfähig ist. Programme sind zwar reale technische Objekte, stellen aber ihrerseits Modelle dar (was leicht zu Verwirrung führt).

Ein Prototyp ist ein Programm, das weder einen Anspruch auf Vollständigkeit noch auf Korrektheit erhebt. Es kann aus einer Vielzahl von Gründen nützlich sein, ihn zu erzeugen. Er macht den Entwickler vertraut mit einer neuen Programmiersprache oder einem neuen Algorithmus. Er verschafft dem Entwickler ein Gefühl für den Aufwand, die Performanz oder die Ergonomie eines Entwurfs. Schließlich vermag er den Auftraggeber davon zu überzeugen, dass etwas Brauchbares im Entstehen ist. Es ist Fakt, dass die meisten Prototypen als Produkt ausgeliefert werden. Er wird zur ersten Version (engl. release) eines Mehr-Versionen-Produkts.

Eine Spezifikation legt normalerweise fest, was ein Programm, wenn es einmal vollständig und fertig ist, tun soll (Soll-Spezifikation). Dabei kann nur die Beziehung zwischen Parametern und Ergebnis (Ein-/Ausgabe-Relation) gegeben sein, nicht jedoch der Lösungsweg oder gar Eigenschaften der Lösung (z.B. Performanz). Eine zweite Form von Spezifikation beschreibt in zuverlässiger Weise, was ein vorliegendes Programm tut (Ist-Spezifikation). Beide unterscheiden sich vor allem bezüglich der für die Spezifikation möglichen Korrektheitsaussage. Eine Soll-Spezifikation muss ihre Korrektheit aus der Aufgabenstellung und den verfügbaren Lösungsverfahren ableiten, also aus nicht formalisierten und formalisierbaren Vorgaben. Die Ist-Spezifikation muss die Semantik des vorliegenden Programms richtig wiedergeben. Eine Spezifikation besteht wie das Programm aus Text oder Grafiken. Sie sollte – muss aber nicht – maschinell verarbeitet werden können. Dabei handelt es sich lediglich um eine syntaktische und semantische Überprüfung. Ist die Spezifikation ausführbar, d.h. produziert sie Ergebnisse wie ein Programm, kann ihre Notation als Programmiersprache angesehen werden. In beiden Fällen von Spezifikation kann der Abstraktionsgrad variieren. Geht dies auf Kosten der Vollständigkeit haben wir es eher mit Modellen als mit Spezifikationen zu tun.

Modellieren statt Spezifizieren

Manchmal ist Spezifizieren ganz einfach, vor allem dann, wenn nur das Problem, aber nicht der Lösungsweg vorgegeben ist. Ein Beispiel ist Peter Naurs berühmtes Textverarbeitungsproblem, mit dem sich Münchner Kollegen bereits 1977 befassten:

Gegeben ein fortlaufender Text, der in Zeilen der Länge n aufgeteilt werden soll, wobei die Zeilen optimal ausgenutzt sind.

Bekanntlich gibt es seither verschiedene Implementierungen, die sich vor allem in der Anzahl der Fehler unterscheiden, aber keine bessere Spezifikation (oder etwa ein Modell). Aber selbst diese Spezifikation sollte ausreichen, um die Korrektheit einer gegebenen Implementierung zu beweisen, eine Aufgabe, die seit 35 Jahren immer noch auf ihre Lösung wartet.

Auf einem ähnlichen Niveau liegt das Beispiel, auf das Herbert Klaeren [1] verweist Es ist eine Form des Parkplatzproblems:

Gegeben eine Fläche für n Räder; wie viele Autos oder Krafträder passen darauf?

Die Spezifikation sieht einfach aus, hat es aber in sich. Hier liegt die besondere Schwierigkeit darin, dass eine wesentliche Annahme, selbst wenn sie angegeben wäre, nur sehr schwer zu formalisieren ist. Alle Restriktionen, die sich aus der zwei-dimensionalen euklidischen Geometrie ergeben, müssen bei der Implementierung nämlich berücksichtigt werden, obwohl sie nicht angesprochen sind. Für ein etwas größeres Programm eine einigermaßen vollständige Spezifikation zu erstellen – gleichgültig ob Soll- oder Ist-Spezifikation – ist Knochenarbeit. Wenn irgendwie möglich, versucht man sich dem zu entziehen. Die Alternative heißt dann, lasst uns doch modellieren.

Bei beiden Beispielen könnte man erwarten, dass es ein Leichtes ist, Modelle zu entwickeln. Umso überraschender ist es, dass die Fachliteratur in dieser Hinsicht nicht sehr ergiebig ist. Ein Modell sollte die Lösung der entsprechenden Aufgaben unterstützen, ja erleichtern. Selbst ein Datenmodell, also eine Formalisierung der für die Lösung verwendbaren Datenstrukturen, könnte helfen.

Besonders unter Akademikern scheint sich Modellieren zum Hobby entwickelt zu haben. Leider habe ich nicht den Eindruck, dass es darum geht, bisher nicht bearbeitete Problemdomänen besser zu verstehen. Natürlich wäre die Mathematisierung weiterer Anwendungsgebiete eine dankbare Aufgabe. Auch scheint es akademisch nicht als besonders verdienstvoll angesehen zu werden, vorhandene Systeme in der Natur, in Technik oder Wirtschaft, oder gar in der Software-Industrie zu modellieren. Im letzteren Fall schimpft man und nutzt sie. 

Mein Eindruck ist, dass es sehr oft nur darum geht, für unterschiedliche Notationen zu werben. Es ist dies der alte Programmiersprachenstreit, verschoben auf ein neues Terrain. Beim Modellieren kann man – im Gegensatz zum Programmieren – immer etwas weglassen. Wenn einem freigestellt ist, was man weglassen darf, ist das Spiel besonders einfach. Jemanden, der sich nur an Aufgaben misst, die er sich selbst stellt, – und dazu noch so, dass sie leicht lösbar sind – , darf man auch als Dünnbrettbohrer bezeichnen.

Programmieren statt Spezifizieren

Die Arbeit des Spezifizierens ist nicht nur lästig, sondern fehleranfällig und wenig nützlich. Da der Nutzen in keinem Verhältnis zum Aufwand steht, verliert Spezifizieren zunehmend an Bedeutung. Niemand kann auf Dauer, also über 20 Jahre hinweg, zwei formale Dokumente auf demselben Niveau halten.

Wird versucht, die Korrektheit eines Programms anhand einer Spezifikation zu beweisen, ist dies bestenfalls eine Pseudo-Korrektheit. Alles hängt dann von der Spezifikation ab und diese ist noch eine Stufe künstlicher als ein Programm. Es ist leichter, Konsistenz und Relevanz zwischen Programm und Realität zu überprüfen, als die zwischen Spezifikation und Realität. Das Programm ist Teil derselben, die Spezifikation nicht.

Es werden immer mehr Programme geschrieben, deren Problemstellungen und Lösungswege nicht in Lehrbüchern zu finden sind. In einem solchen Fall besteht der erste Schritt darin, das Problem als (mittels Computer lösbares) Problem zu erkennen. Danach kommt es darauf an, zu verstehen, was akzeptable Lösungen sind und diese in Angriff zu nehmen. Die Aufgabe und die Lösung adäquat zu dokumentieren, ist zwar löblich, aber sekundär. Es gibt kein einziges Programm, das ich verwende, für das ich im Detail wissen will, wie es funktioniert. Den Lizenzvertrag (Eula genannt) sehe ich sehr selten an, geschweige denn die Spezifikation (sofern ich sie überhaupt auftreiben könnte).

Die beigefügte Tabelle gibt an, wie viel Speicherplatz einige bekannte Programme auf meinem privaten PC belegen. Dividiert man diese Zahlen durch 4, so erhält man einen Anhaltspunkt für ihre Größe, ausgedrückt in MLOC. Bei Windows 7 ergibt dies etwa 600 MLOC. Natürlich ist nur ein Bruchteil davon ausführbarer Code. Aber ohne Nachrichten und Erklärungen ist Code nicht benutzbar. Papier-Manuale sind von Vorgestern [2].

Es ist für mich wie für die meisten Nutzer nicht sinnvoll, eine exakte Spezifikation von einem dieser Programme zu studieren. Wie in Broy/Endres [3] beschrieben, gibt es immer mehr ‚Übergroße Systeme‘ (engl. Ultra-large-scale systems). Sie werden mehr und mehr Teil der Infrastruktur, vergleichbar den Verkehrs- und Versorgungssystemen. Diese Systeme wachsen ungeplant in eine Größenordnung von mehreren GLOC. Es gibt nicht Informatiker genug auf der Welt, um sie zu analysieren.

Unterschied zwischen Modellieren und Simulieren

Ich möchte noch zwei Begriffe voneinander abzugrenzen versuchen, die oft gleich gesetzt werden. Ich mache es kurz. Haben die Modelle von Programmen, die man baut, eine Zeitdimension, dann sollten sie auch ausführbar sein. Dann sind sie gleichzeitig Simulationsprogramme. Dabei muss das Simulationsprogramm nicht dieselbe Art von Ergebnissen liefern oder dieselben externen Effekte haben, wie das simulierte Programm. Ist man z.B. nur an dem Zeitbedarf interessiert, wird nur der Kontrollfluss nachgeahmt. Anstatt die echten Werte zu berechnen, werden beim Erreichen eines Knotens nur die für einzelne Routinen und Operationen geschätzten Millisekunden aufaddiert.

Zusätzliche Referenzen und Hinweise

1. Klaeren, H.: Viren, Würmer und Trojaner. Streifzüge durch die Computerwelt. Tübingen: Klöpfer & Meyer 2006
2. Warum Dragon 11.5 zuerst 15,5 GB herunterläd, um anschließend 2,5 GB zu installieren, ist mir ein Rätsel. Vielleicht hatte man mir die englische und französische Version gleich mitverkauft.
3. Broy, M., Endres. A.: Informatik überall, jederzeit und für alle. Informatik-Spektrum 32,2 (2009), 153-162

Informatik und die drei Kulturen

Laut C.P Snow gab es 1959 in England zwei Kulturen. Entweder hatte er nicht genau hingesehen, oder aber die Dinge haben sich weiterentwickelt. Heute haben wir es eindeutig mit drei Kulturen zu tun, und das nicht nur in Europa. Ob das Fortschritt ist, darüber kann man streiten. Ich halte es für nützlich, diese Differenzierung zu betonen. Das widerstrebt denjenigen, die sich mehr davon versprechen, wenn die Einheit der Wissenschaften zum Ideal erklärt wird. Wer näher hinschaut, weiß, dass sie sehr brüchig ist und oft nur mit Mühe zusammengehalten wird. So wie Kinder ihre Dissonanzen verbergen, wenn sie gemeinsam etwas von den Eltern wollen, so betonen die Wissenschaften gerne, dass alle gleich sind, wenn immer sie gemeinsam um die Futtertröge buhlen, die der Souverän aufstellt. Ich will zunächst nur die Situation beschreiben. Ich darf dabei – entgegen der üblichen Gepflogenheit – hinten anfangen.

Ingenieurwissenschaften (Kultur 1)

Es gibt ihre Art von Aufgaben und die Tätigkeiten schon einige Tausend Jahre. Es begann etwa zu der Zeit, als Menschen anfingen neben dem Jagen und Fischen sich durch Ackerbau zu ernähren. Es entstanden Berufe wie Klempner, Schmied, Steinmetz und Architekt. Später baute man außer Palästen und Tempeln auch Maschinen. Zuerst waren sie vom Wasser, dann vom Dampf getrieben. Danach kamen Generatoren und Batterien. Man verlegte Kabel von Haus zu Haus, ja sogar auf den Meeresgrund. Man pumpte Wasser aus Bergwerken und ersetzte die Karbidlampen. Schließlich konnte man Morse-Signale um die Welt schicken.

Man sah ein Problem und tüftelte, bis dass man eine Lösung hatte. Manchmal war es sportlicher Ehrgeiz, der einen antrieb, einen Turm zu bauen, der höher war als alle Türme vorher. Man probierte, bis man wusste, dass es hielt oder dass es funktionierte. Es war dabei völlig sekundär, warum etwas hielt oder warum etwas funktionierte. Mathematische Formeln brauchte man nicht.

Aus Handwerk wurde Technik. Heute betreiben wir das Ingenieurwesen auch wissenschaftlich. Wenn man etwas gebaut hat, kann man nachher der Baupolizei erklären, warum es nicht zusammenfällt. Dem Auftraggeber war es vor allem wichtig, dass jemand sich traute, den Turm oder die Maschine zu bauen. Das Prüfen und Rechnen überließ er gern seinen Beamten. 

Im Gegensatz zu den ‚freien‘ Wissenschaften sind Ingenieurwissenschaften die ‚Notwissenschaft‘ par excellence. Ingenieure betreiben Wissenschaft nur, wenn sie es müssen. Paul Lorenzen, der diesen Begriff prägte, meinte etwas anderes damit. Er meinte damit die Wissenschaften, deren Aufgabe und Anliegen es ist, Not zu lindern.

Naturwissenschaften (Kultur 2)

Der Mensch sieht nachts die Sterne und fragt sich, warum leuchten diese. Er stellt fest, dass einige, wie z. B. der Mond, gar nicht selbst leuchten, sondern nur das Licht anderer Sterne reflektieren. Die Frage ist damit nur verschoben auf den Rest der Sterne. Da diese sich nicht zu bewegen scheinen, nennt man sie Fixsterne. Warum diese als Leuchten wirken, dafür hat man heute Theorien. Eine davon besagt, dass es die Atomkerne sind, die zerfallen und Wärme erzeugen. Wir sehen das Feuer, weil es Licht aussendet, wissen aber zunächst nicht, was Licht ist. Kluge Leute sagen, es sei sowohl Welle wie Partikel. Bei einer Sonnenfinsternis konnte die Wellennatur bewiesen werden. Beim Doppelspalt geht es wieder durcheinander.

Die Naturwissenschaftler bemühen sich, Dinge wie diese zu erklären. Manchmal kommt dabei etwas heraus, was Ingenieure anregt oder gebrauchen können. Manchmal produzieren sie nichts als Theorien. Bei den Physikern scheint dies seit 40 Jahren der Fall zu sein. Die Biologen sind besser dran. Sie haben Werkzeuge von Ingenieuren bekommen, z. B. Rastermikroskope und Kernspintomographen, mit denen sie eine Menge von Fragen klären können. Sie benötigen weniger oder keine Theorien. Da alles, was Biologen herausfinden, einen Bezug zur Medizin und damit zum Menschen hat, ist ihnen das Interesse der Öffentlichkeit sicher.

Geisteswissenschaften (Kultur 3)

Ihre Grundannahme ist, dass Naturwissenschaftler nie alles erklären können. Es wird zwar immer weniger, aber noch bleibt einiges offen. Dafür entwickelt man Theorien, die postulieren (jedoch nicht beweisen), dass die erreichte Grenze eine endgültige ist. Es kann sein, dass in Zukunft einige der Fragen doch noch geklärt werden. Dann erübrigen sich diese Theorien.

Heute noch (teilweise) ungeklärt ist, wie und warum Leben entstand, wie und warum das Weltall entstand, ob der Mensch Dinge erfährt, für die er kein Organ hat, usw. Da vielleicht nie alles als deterministischer Ablauf gedeutet werden kann, muss der Mensch das Leben organisieren. Dafür Regeln zu ersinnen, ist hilfreich. Das machen Religionsstifter, Staatsgründer oder Vereinsmitglieder. Auch kann man den Menschen beobachten, wie er auf Situationen reagiert, wenn ihm keine oder bestimmte Vorgaben gemacht wurden. Das nennt man Psychologie. Beobachtet man nicht einzelne Individuen, sondern Gruppen in ihrem Verhalten, sprechen wir von Soziologie.

Manche Geisteswissenschaftler tragen auch zur Bildung, Erbauung und Unterhaltung ihrer Mitmenschen bei. Das tun z. B. Pädagogen, Schauspieler, Dichter und Musiker. Dabei ist es hilfreich, Material zu haben, sowohl Lehrmaterial wie Spielstoffe. Das liefert die Geschichte oder die Kreativen. Wer nichts von der Vergangenheit hält, wird Revolutionär. Eine etwas mildere Form sind die Reformatoren. Wenn Kreative versuchen mit ihren Kreationen Geld zu verdienen, ist dies anrüchig. ‚Freie‘ Künste leben quasi vom Sonnenlicht, genau wie Blumen. Geld führt zur Knechtschaft.

Eine früher von den Geisteswissenschaften wahrgenommene Aufgabe, Wissen zu archivieren und wieder auszubuddeln, übernimmt heute (teilweise) das Internet. Es bleibt die Aufgabe, Wissen zu bewerten und zu strukturieren. Auch die undankbare Aufgabe des Dolmetschens wird die Technik lösen.

Da Kultur 1 und Kultur 2 in der Vergangenheit die herrschende Schicht (Adel, Theologen, Juristen) relativ wenig interessierte, hat dies zur Folge, dass sich die Vertreter von Kultur 3 (immer noch) als die Träger von Kultur schlechthin ansehen.

Position der Informatik

Die Frage steht im Raum, zu welcher der drei Kulturen die Informatik gehört bzw. gehören sollte. Ich persönlich bin überzeugt, dass alle drei eine Rolle spielen. Ausgehen muss auch Informatik von der Ingenieur-Kultur (Kultur 1), nämlich der Frage, was sie beitragen kann zum körperlichen und geistigen Wohlbefinden des Menschen, d.h. seinem Unterhalt und seiner Unterhaltung. In einem anderen Zusammenhang nannten Broy und Endres dies Lebensqualität. Wenn auch noch gesagt werden kann, warum gewisse Rezepte und Verfahren so wirken wie sie das tun, kann dies helfen. Es ist aber nicht die Voraussetzung dafür, überhaupt etwas zu tun. Da es (vielleicht) eine Illusion ist, alles logisch zu erklären, sollten wir psychologische und soziologische Kriterien nicht außer Acht lassen.

Welches Gewicht die jeweilige Kultur für einen Informatiker hat, hängt von der Tätigkeit ab, die er/sie ausübt. Bei einem Vertriebsmitarbeiter spielt Kultur 3 eine große Rolle, bei einem Entwickler Kultur 1 und bei einem Forscher Kultur 2. Wer sich für einen Informatik-Lehrstuhl in Deutschland bewirbt, muss berücksichtigen, dass zwischen den Hochschulen die Gewichtung sehr unterschiedlich ist. Fachhochschulen und einige jüngere Universitäten betonen primär Kultur 1. Für einige alt-ehrwürdige Universitäten zählt nur die Kultur 2. In Bremen und Hamburg gehört Informatik angeblich zur Kultur 3.

Rolle der Mathematik

Die Mathematik, die zu keiner der drei Kulturen gehört, spielt in der Informatik die Rolle einer Hilfswissenschaft. Sie hat schöne Namen und Behälter für Dinge, die Informatiker manchmal brauchen. Sehr oft sind die Namen irreführend (z.B. reelle Zahlen) oder die Behälter unpassend (z. B. Mengen). Manchmal sagt sie auch, dass gewisse Fragen durch (noch so langes) Rechnen nicht beantwortet werden können.

Die Mathematik kann ˗ entgegen langjähriger Beteuerung ˗  es nicht schaffen, für die Informatik eine Theorie zu liefern. Die Mathematik erklärt die Welt nicht, sie gestattet nur, sie auf eine bestimmte Art zu beschreiben. Diese Beschreibungen passen am besten im mittleren Größenbereich (von 10^-6 bis 10⁶ Meter). Der Anstrich, den Mathematiker Produkten aus der Informatik geben können, ist oberflächig. Meist blättert er nach kurzer Benutzung ab.

NB. Soviel für heute. Wer sich angegriffen oder herausgefordert fühlt, möge sich melden.

Wirkt die Evolution auch außerhalb der Biologie?

Seit Jahren führe ich eine lebhafte Diskussion mit meinen Freunden über diese Frage. Sie bejahen sie teilweise aus der Überlegung heraus, dass es Phänomene gibt, die man anders kaum erklären kann.

In der Biologie hat Charles Darwin Gesetze erkannt, die sehr universell zu sein scheinen. Fast sind es Tautologien. Modern und etwas flapsig ausgedrückt, lehrt heute die Biologie Folgendes: In der Natur kommt es beim Kopieren der Gene, also der Erbinformation, hin und wieder zu Fehlern (Variation genannt). Wo gibt es das nicht? Auch wir Informatiker kennen Kopierfehler und haben Gegenmittel erfunden. Der Phänotyp, also der vom Fehler betroffene Nachkomme, macht das Beste daraus. Er versucht zu überleben. Manchmal hat er keine Chance, manchmal hilft ihm der Fehler sogar dabei. Dann hat er längere Ohren, bessere Augen oder stärkere Muskeln. Er verdrängt die lahmen Geschwister vom Euter oder von der Dorfwiese (Selektion genannt). Diese verhungern oder bleiben ohne Nachkommen. Werden die ‚falsch kopierten‘ Gene weitervererbt, haben wir es mit einem neuen Genotyp, also einer neuen Art, zu tun (Stabilisierung genannt).

Darwin folgerte einst: Wer die besten Voraussetzungen fürs Überleben hat, der überlebt. Das klingt nach etwas ganz Selbstverständlichem, war aber eine tiefe Einsicht. Ebenso fundamental war die daraus folgende Einsicht, dass die Entwicklung in der Biologie kein Ziel hat (nicht teleologisch ist). Sie ist jedoch auf den sehr mächtigen Überlebenstrieb abgestützt. Der sorgt für genügend Motivation, gibt genug Antrieb. Dass immer ‚intelligentere‘ Arten entstanden, war ein netter Nebeneffekt der biologischen Entwicklung, nicht jedoch das Ziel.

Das Substantiv ‚Evolution‘ ist im Deutschen schon fast belegt durch Darwin, aber noch nicht ganz. Nur das Verb ‚evolvieren‘ ist noch frei. Nur da, wo Variation, Selektion und Stabilisierung stattfinden, sollte man daher von darwinscher Evolution oder einem darwinschen Prozess (DP) sprechen. Formal ausgedrückt: Ein darwinscher Prozess ist eine Konkatination von einem Variationsprozess (VP), einem Selektionsprozess (SP) und einem Stabilisationsprozess bzw. Replikationsprozess (RP). 

DP = VP.SP.RP

Laufen nicht alle drei Teilprozesse ab oder nicht in genau der angegebenen Reihenfolge, so können dennoch teilweise dieselben Ergebnisse entstehen. Auch das kennen Informatiker, die Programme nur mit wenigen Testfällen verifizieren möchten.

Nicht alle Fachgebiete, die von Evolution reden, halten sich an diese strenge Definition. Beginnen möchte ich mit den Wissenschaften, die den Menschen zum Thema haben, nämlich Psychologie, Soziologie und Ökonomie. Die Medizin ist hier als Teil der Biologie zu verstehen.

Die Psychologie hat es schwer, Gesetzmäßigkeiten zu definieren. Soweit der Mensch als biologisches Wesen zu begreifen ist, findet die Evolutionstheorie Anwendung. Das ist selbst für die Medizin nicht ausreichend, um Erfolg zu haben. Das Individuum kann lernen, d. h. Dinge verstehen und bewerten und sich Fähigkeiten aneignen. Das Erlernte durch Kopieren an die Nachkommen weitergeben zu können, wäre schön. Es funktioniert aber nicht. Da aber beim Lernen Unterschiede bestehen, sagt man, dass hier Selektion im Spiel sei, also Darwin. Selektion ist aber nur einer der drei obigen Schritte.

In der Soziologie nimmt man zur Kenntnis, dass nicht nur Individuen lernen können sondern sogar ganze Gruppen. Man nennt das Paradigmenwechsel, Meinungsbildung, Moden oder Volksbewegungen. Es funktioniert dies nicht dank paralleler Vererbung, sondern mittels Kommunikation. Hier kommt Niklas Luhmann ins Spiel. Er erklärt Gesellschaften als selbstreproduzierende Systeme (Autopoiesie). Da nur solche Systeme kommunizieren können, die eine gewisse Zeit lang stabil sind, müssen sie Überlebenskraft haben. Die kann nur ein darwinscher Prozess geben, so glaubt man. Es stimmt aber nicht.

In der Ökonomie kennt man Wettbewerb, also Selektion. Das sei Darwinismus, schreien die Gegner von Wettbewerb. Sie möchten lieber planen, d.h. Gott spielen.

In der Physik gibt es viele Formen der Entwicklung. Eine Staubwolke wird zum leuchtenden Stern, dieser zur Supernova, dann zum roten Riesen, ehe daraus ein Schwarzes Loch wird. Dieses verändert sich weiter. Zu den Kräften, die dies bewirken, gehört die Gravitation. Sie treibt leichte Teile nach oben, schwere nach unten. Es gibt aber auch die Wärmeausdehnung, die für die Erosion verantwortlich ist. Schließlich erzeugt Reibung Wärme oder bewirkt, dass die Rotation der Erde sich verlangsamt. Hier an Darwin zu appellieren, scheint schon recht gewagt.

Für die Chemie gilt wohl dasselbe. Eine Säure frisst alles, was ihr nicht widersteht. Die Mathematik schließlich ist ganz frei von biologischen Gesetzen. Theorien heißen Vermutungen, wenn sie etwas zu erklären versuchen, was widerlegt werden kann. Es gibt zwar evolutionäre Algorithmen, mit denen versucht wird, die Prozesse zu beschreiben, die bei der Evolution eine Rolle spielen.

Die Biologie hat sich schon lange genug mit Darwin (und Mendel) beschäftigt, um zu verstehen, was passiert und um Grenzen zu erkennen. So weiß man inzwischen, dass die Gene nicht alles bestimmen. Es beginnt mit der Gen-Expression, die abhängig ist von der Umwelt. Gemeint ist, dass nicht alle Gene überall wirksam sind. Sie können an- oder abgeschaltet werden. Vor allem aber spielt die Umwelt während der embryonalen Entwicklung eine große Rolle. Ob Erlerntes zur Erbmasse wird, ist noch in der Diskussion. Das berührt die Frage, was Lernen ist. Eric Kandels Meeresschnecke speicherte Gelerntes durch Wachsen von Nervenzellen. Damit sind noch keine neuen Gene erzeugt oder Änderungen vollzogen, die richtig oder falsch kopiert werden. Die Vererbung zeigt sich am deutlichsten bei Populationen, die vom Rest der Welt abgeschlossen sind, wie bei den Galapagos-Finken und – mit  etwas  Phantasie  ̶  den Amish in Pennsylvania. Entschließt sich eine Gruppe von Lebewesen auf Nachkommen zu verzichten, ist damit die Evolution beendet.

Zu diesen Gedanken schrieb mein Freund Peter Hiemann aus Grasse:

Jeder wissenschaftlich Interessierte wird einen Ansatz wählen, den er für sein Gebiet für Erfolg versprechend hält. Für viele wissenschaftliche und technische Sachgebiete ist es unerheblich, ob ein erkenntnistheoretischer Ansatz gewählt wurde. Nur der pragmatische Erfolg einer Arbeitshypothese zählt. Ich erachte Luhmanns evolutionäre Systemtheorie als am besten geeignet, mir Erkenntnisse zu erarbeiten, die den biologischen, geistigen und gesellschaftlichen Aspekten menschlichen Lebens am ehesten gerecht werden.

Übrigens ist Luhmanns Systemtheorie auch deshalb attraktiv, weil sie einen Informationsbegriff verwendet, der dynamischen Prozessen am besten gerecht wird: „Information setzt immer voraus, dass man eine Möglichkeit gegen andere Möglichkeiten abgrenzt und innerhalb eines Bereichs von Möglichkeiten die eine oder andere als Information vorgelegt bekommt. Information ist eine Selektion aus einem Bereich von Möglichkeiten; wird die Selektion wiederholt, enthält sie keine Information mehr.“ (Einführung in die Systemtheorie, S 128).    

Luhmann definiert evolutionäre Entwicklungen als fortlaufende Kommunikationsprozesse und unterscheidet zwischen Programmsystemen, Interaktionssystemen und Funktionssystemen. Deshalb betrachtet Luhmann evolutionäre Prozesse unter dem Aspekt des iterativen Austauschs von immer neuer Information, die zu Veränderungen der Komponenten (Einzelsysteme) eines Kommunikationssystems führen, die durch Variationen und Selektionen bedingt sind. Deshalb benutzt Luhmann der Begriff "Information" ausschließlich im Sinne einer Veränderung. Luhmanns Definition erlaubt die Anwendung auf eine breite Palette von Objekten. Für mich war besonders wertvoll, dass Luhmann dem Begriff Evolution eine konkrete prozessorientierte Definition gegeben hat.

Mein Kommentar dazu: Ob man Luhmann so missbrauchen wird, wie man Darwin missbraucht hat, ist eine offene Frage. Sie ist deshalb offen, weil Luhmann bisher weniger bekannt ist als Darwin. Hiemann fährt fort:

Vielleicht ist in diesem Zusammenhang auch erwähnenswert, dass die Thesen des populären Autor des Buches "Das egoistische Gen" (Richard Dawkins) meines Erachtens überholt sind. Dawkins hat sogar versucht, das Prinzip der "egoistischen Evolution" auf die Veränderungen geistiger Objekte, die er Meme nennt, anzuwenden. Das Sachgebiet bekam den Namen "Memetik" und hat auch heute seine Anhänger (z.B. Susan Blackmore).

Richtig studieren, um sich später erfolgreich bewerben zu können

Am Schluss des vorhergehenden Beitrags stand der Hinweis, möglichst die Dinge vom Ende her zu denken. Das soll im Folgenden an einem Beispiel illustriert werden. 

Hat man sich für ein Studium entschieden und einen Studienplatz erobert, neigt man dazu, zuerst einmal tief Luft zu holen und die neue Phase des Lebens zu genießen. Fast erscheint es einem übertrieben – wenn nicht überheblich, schon gleich an das Ende des Studiums zu denken. Das liegt ja noch vier oder fünf Jahre weg, also in ferner Zukunft. Aus der Sicht eines Erwachsenen sind fünf Jahre eher eine kurze Zeit. Rückblickend erscheinen sie sogar noch verkürzt. Jedenfalls ist es eine endliche Zeit und der Berufseintritt  steht für fast alle unverrückbar im Raum. Natürlich gibt es die ‚ewigen‘ Studenten. Das ist jedoch die Ausnahme.

In der hier gewählten Betrachtungsweise dient ein Studium dazu, beruflich relevante Fähigkeiten zu erwerben sowie Fakten und Stoff zu liefern für den Lebenslauf. Gemeint ist der Lebenslauf, der als wichtigste Information über einen selbst der Bewerbung beigefügt wird. Dass für ein gutes Studium und einen spannenden Lebensabschnitt  Zeit und Mühen erforderlich sind, ist klar. Allerdings – und hier kommt gleich der erste Fall von Wunschdenken vor – sollte der von einem jungen Menschen dafür zu erbringende Aufwand möglichst gering sein. Man soll möglichst keine Umwege oder Pausen einlegen. Man sollte gleich auf Anhieb klug sein und das Richtige tun. Alles, was ein Studium sonst noch bietet, – das Weg von zuhause, das Studentenleben, usw.  – ist irrelevant. Es ist so zu sagen Privatsache. Mit gewissen Einschränkungen gilt dies auch für den Zugewinn an Allgemeinbildung, den ein Studium über das Abitur hinaus mit sich bringt. Dies ist – wie gesagt – das Ideal. Jeder vernünftige Mensch weiß aber, dass Ideale nicht von dieser Welt sind.

Fragt man sich, wer für die Bewertung von Lebensleistungen die Maßstäbe definiert, so lautet die Antwort: Es kommt darauf an, bei wem man sich bewerben will. Es ist nämlich ein himmelweiter Unterschied, ob man die Maßstäbe und Erwartungen eines Mittelständlers, einer Behörde oder einer Großforschungseinrichtung erfüllen will. Die Universitäten sind am besten, wenn es darum geht, ihre eigenen Anforderungen an den potentiellen Nachwuchs zu artikulieren. Will man nicht von der Schule wieder zur Schule zurück oder gar den Rest des Lebens an der Universität bleiben, dann muss man nach außen schauen. Man muss sich klar werden, welche potentiellen Tätigkeiten es für mich noch gibt. Anders ausgedrückt, man muss sich für seine Branche interessieren. Je früher man damit beginnt, umso besser.

Man kann sich dieses Wissen auf verschiedene Weisen besorgen. Der einfachste Weg: Man liest die Wirtschaftsteile von Zeitungen oder hört Nachrichten aus der Wirtschaft. Neben den traditionellen Medien (Papier und Fernsehen) spielt hier das Internet eine immer wichtigere Rolle. Man kann sehr selektiv die für einen selbst interessante Information abonnieren. Der nächste Schritt sind Firmen- und Messebesuche. Viele Lehrstühle organisieren Firmenbesuche. Die Informatik-Branche hat in Hannover in jedem Frühjahr einen festen Messetermin, die CeBit. Als Student gibt es ermäßigte Eintrittsgebühren. Die dritte Art, die Branche kennen zu lernen, erfolgt über Praktika. Man kommt für Wochen und Monate in eine Firma hinein und bekommt dafür noch Geld. Schließlich gibt es die Fachgesellschaften. Hier kann man sich von Fachmann zu Fachmann, oder von Fachfrau zu Fachfrau austauschen. Man ist nicht auf die offiziellen Kontakte und das besonders aufpolierte äußere Erscheinungsbild angewiesen.

Der Begriff einer Branche ist in jedem Falle genau definiert. Dafür gibt es Codes und Listen. Das gleiche gilt für Berufe. Wichtig ist es, genügend Unternehmen zu kennen, die Leute beschäftigen, die über die Qualifikation verfügen, die man selbst einst haben wird. Es können auch Behörden dazu gehören. Auch wenn man sich nicht einem Unternehmen anschließen will, – also als Selbständiger agieren will  ̶   muss man dies wissen. Wenn man dies beherzigt hat, ist es unwahrscheinlich, dass man erst am Ende des Studiums damit beginnt sich klarzumachen, welche Firmen für einen in Frage kommen. Klären muss man nur, welche Firmen an einem selbst Interesse haben. Dazu muss man sich bewerben. Das gilt auch, wenn die Firma einen bereits kennt. Man hat dann lediglich einen Vorsprung.

Auf die Form der Bewerbung will ich hier nicht im Einzelnen eingehen. Dafür gibt es viele Anleitungen und Hilfen, unter anderem von der Bundesagentur für Arbeit oder vom Thieme-Verlag. Auffallend ist nur, dass sehr oft noch empfohlen wird, ein dickes Papierdokument zu erstellen. Wer das tut, hat sich in gewissen Branchen bereits disqualifiziert. Wenn eine Firma eine Bewerbung per Internet oder über ihre Homepage wünscht, ist jede andere Form ein Beweis dafür, dass man sich mit dieser Firma überhaupt nicht beschäftigt hat.

Um zu beschreiben, was eine Bewerbung enthalten muss, muss man sich in die Rolle dessen versetzen, der Bewerbungen liest. Das tun zunächst Sachbearbeiter einer Personalabteilung. Bei Firmen, die von Bewerbungen überschüttet werden, sortieren sie alle aus, die offensichtlich nicht näher geprüft werden müssen. Kommt eine Bewerbung in die engere Wahl, wird sie von einem Fachmann des betreffenden Arbeitsgebiets beurteilt. Der entscheidet dann, ob der Bewerber zum mündlichen Gespräch eingeladen wird. Diese Gespräche werden meist von mehreren Mitarbeitern geführt, entweder gleichzeitig oder getrennt. Bei manchen Neugründungen entscheidet der Firmengründer persönlich über alle Einstellungen.

Aus Sicht der Einstellenden soll ein Gespräch mit dem Bewerber bzw. der Bewerberin vor allem drei Fragen beantworten: (a) Kann er/sie die anstehende Aufgabe bewältigen? (b) Will er/sie das? (c) Passt er/sie zu uns?

Zu (a): Der Bewerber hat in den seltensten Fällen genau die anstehende Aufgabe schon einmal gelöst, höchstens eine ähnliche. Will man ihn nicht nur für eine Aufgabe sondern für länger einstellen, muss sein Können eine gewisse Breite verraten. Können setzt Wissen voraus, ist aber nicht dasselbe. Für einen Klavier- oder Tennisspieler ist klar, was damit gemeint ist. Eine Theorie für etwas zu kennen, heißt nicht, dass man die Sache auch beherrscht. Umgekehrt müssen wir viele Dinge können, für die wir keine Theorie besitzen, d.h. wir wissen nicht – oder brauchen nicht zu wissen  ̶  warum es funktioniert. Das ist hart für manche Theorie-Fans und reine Akademiker, ist aber die Realität. Wissen kann nie allumfassend sein. Es veraltet oder wird ergänzt. Der Bewerber muss also bereit sein zu lernen. Lernen heißt Relevantes von Nicht-Relevantem (engl. nice-to-know) zu unterscheiden. Er muss analytisch denken können, d.h. er muss abhängige von unabhängigen Variablen unterscheiden können.

Zu (b): Man möchte niemanden zu einer Tätigkeit zwingen, die er nicht mag. Hat jemand eine natürliche Sympathie für die gewählte Tätigkeit, hat er einen großen Vorteil andern Menschen gegenüber. Diese Kollegen – so hieß es früher bei uns – sollten ihr Gehalt der Firma überweisen. Wessen Beruf auch sein Hobby ist, für den ist das Gehalt sekundär. NB: Bewerbern, die nicht nach dem Gehalt fragen, sollte man jedoch mit Skepsis begegnen. Entweder sind sie leicht so aufgeregt, dass ihnen derartige fundamentale Fehler passieren, oder sie werden von einem Geheimdienst oder Mitbewerber geschickt.

Zu (c): Jede Firma, die stolz auf sich ist, möchte ihren Stil beibehalten. Das drückt sich teilweise in Äußerlichkeiten aus. Mal ist es die Kleiderordnung, mal ist es der Sprachstil. Einem unbekannten Gegenüber das Du anzubieten, ist für einen Bewerber mehr als mutig. Hinter dem Stil verbergen sich sehr oft wichtige Überzeugungen, manchmal auch als Werte bezeichnet. Auch sie können sich ändern. Firmen möchten sich dafür aber die nötige Zeit nehmen und nicht Moden vom Markt einkaufen, d.h. durch Einstellung von Revolutionären.

Zum Schluss noch ein paar Ideen, was man gerne in seinen Lebenslauf schreiben möchte. Die Angaben sollten so konkret wie möglich sein, damit sie geglaubt werden. Hier soll nur die Art der Lebensleistungen angegeben werden. Neben den technischen Fachkenntnissen hat man auch einige betriebswirtschaftliche Grundkenntnisse erworben. Man hat an einigen Projekten teilgenommen, bei denen Teamarbeit gefordert war. Die studentische Selbstverwaltung erforderte echte Interessenausgleiche. Politischen Themen gegenüber war man offen und nahm an Diskussionen teil. Demonstrationen und Straßenkämpfe waren damit nicht verbunden. Der Auslandsaufenthalt kostete zwar eine Verlängerung des Studiums, brachte aber wichtige Erkenntnisse. Vor allem die Sprachkenntnisse haben einen enormen Schub erfahren. Bei Leistungen in Sport und Kunst (inkl. Musik und Theater) sollte zu erkennen sein, dass das eigentliche Fachgebiet nicht unter dem Hobby zu leiden hat. Ansonsten sind Hobbies willkommen.