Informatik-Folklore, die man hinterfragen darf

Das am 15.4.2014 vom Springer-Verlag an die GI-Mitglieder verteilte Online-Bulletin ‚GI-Radar‘ gibt Veranlassung, gleich über zwei Scheingewissheiten in der Informatik nachzudenken. Ob man sie als Fehleinschätzungen oder gar als Mythen ansieht, ist Geschmackssache. Warum sie sich so lange halten, ist mir ein Rätsel. Es ist mein fachliches Interesse und mein Verantwortungsgefühl unseren jungen Kollegen gegenüber, die mich bewegen, diese Themen anzuschneiden.

Quelloffener Code sei sicherer als proprietärer Code

Der Fall Heartbleed für OpenSSL geht gerade durch die Presse als eine der peinlichsten Pannen unserer Branche seit Jahrzehnten. SSL-GAU nennt es ein Branchendienst (Heise am 10.4.2014). OpenSSL ist eine sicherheitsrelevante Komponente, die von vielen stark benutzten Produkten verwandt wird. Ich selbst könnte betroffen sein, da ich seit einigen Jahren die ELSTER-Software der deutschen Finanzämter verwende, die von der Firma Akamai aus Zürich stammt. Auch das Bundeskanzleramt gehört zu ihren Kunden. Die in diesem Falle relevante Komponente namens Heartbleed wurde von einem deutschen Programmierer während seiner Promotion vor mehreren Jahren entwickelt. Der von den Herstellern von Schad-Software (und natürlich auch von Geheimdiensten) ausgenutzte Fehler ist eine nicht abgeprüfte Bereichsüberschreitung. Das ist ein Allerweltfehler, den jede einigermaßen sorgfältige Code-Inspektion gefunden hätte.

Der von Anhängern von Open-Source-Software (OSS) gern verbreitete Mythos, OSS sei (von Hause aus) besser und sicherer als proprietärer Code, ist wieder einmal eklatant widerlegt. Schon vor 14 Jahren (Artikel im Informatik-Spektrum Heft 23,5) habe ich auf diese Propaganda-Lüge aufmerksam gemacht. Es gehört zur OSS-Folklore, wenn behauptet wird, dass alle Fehler schnell gefunden und gefundene Fehler immer und schnell korrigiert würden. In besagtem Artikel hieß es:

Anzunehmen, dass die Qualität von Software oder generell die von technischen Produkten sich ohne eigene Anstrengungen der Entwickler einstellt, also allein durch die Aufmerksamkeit der Nutzer oder gar aufgrund von Wachstums- und Selektionsprozessen, ist eine merkwürdige Utopie.

Mir sind in meiner über 40-jährigen Karriere nur sehr wenige Programmierer begegnet, die Freude daran fanden, anderer Leute Code zu analysieren und zu korrigieren. Manche Fehler in sicherheitskritischer Software werden überhaupt nie korrigiert, sondern landen stattdessen auf dem Markt für Virenbauer. Man bekommt ordentliches Geld, wenn man sein Wissen über einen Fehler in der Hacker-Szene meistbietend verscherbelt. Geschlossene Systeme (engl. object code only), wie die von Apple für Smartphones und Tablet-Rechner angeboten werden, sind für die Szene unergiebig. Das Viren-Problem ist inzwischen ganz in Richtung Android-Systeme abgewandert. Diese Feststellung stammt übrigens von niemandem anders als der Firma Kapersky Lab, einem auf Virenschutz-Software spezialisierten Unternehmen. Das gravierendste Argument gegen OSS ist jedoch folgendes: Einmal angenommen, OSS und proprietärer Code hätten die gleiche Anzahl und Schwierigkeitsgrade von Fehlern, dann stehen im Falle von OSS-Code der Hacker-Szene alle Fehler frei zur Verfügung. Bei geschlossenem Code habe ich wenigstens die Gewissheit, dass die Scheunentore nicht für Diebe und Brandstifter sperrangelweit offen stehen.

Wenn Firmen wie Apple, Google und Microsoft von der amerikanischen Regierung gezwungen werden, der NSA Hintertüren in ihrer Software zur Verfügung zu stellen, ist zweifellos eine Grenze überschritten. Unsere Branche muss sich dagegen energisch wehren, im Interesse ihrer Kunden auf der ganzen Welt. Wenn aber immer wieder Offenlegung von Quellcode als Lösung aller Übel empfohlen wird, so beweist das nicht nur fehlende Sachkenntnis, sondern grenzt an mangelndes Verantwortungsbewusstsein. Es kann nur entschuldigt werden mit der herrschenden Gepflogenheit, die nach jedem politischen oder kaufmännischen Skandal oder Versagen mehr Transparenz verlangt. Transparenz gilt als ein Wundermittel. Dabei schafft sie nur Voraussetzungen dafür, dass etwas geschehen kann, getan wird jedoch nichts. Zwischen beidem liegt bekanntlich ein erheblicher Unterschied.

Hardware-Ingenieure seien gewissenhafter als Software-Ingenieure

In der Zeitschrift ‚Wirtschaftsinformatik und Management‘ (Heft 2/2014) stellte Kollege Peter Mertens die Frage ‚Warum ist Software (made in Germany) nicht wie Hardware?‘ Immer wieder höre er, dass Unternehmensleiter und andere nicht-technische Experten abfällig über ihre Software-Entwickler reden. Würden sie doch so arbeiten wie Maschinenbauer und Elektroingenieure, dann hätten wir weniger Probleme, hieße es. Auch dieses Fehlurteil kenne und bekämpfe ich seit etwa 40 Jahren. Damals schockierte ich noch meine Hardware-Kollegen, indem ich sagte, würden meine Software-Entwickler so arbeiten wie Hardware-Entwickler würde ich mich schämen. Die Hardware-Entwickler hielten damals Entwurfsfehler (und Entwickler-Produktivität) für uninteressant. Ihr Augenmerk lag auf Fertigungsfehlern (und Fertigungskosten). In der Software spielten Fertigungsfehler (und Fertigungskosten) eine untergeordnete Rolle gegenüber Entwurfsfehlern (und Entwurfskosten). Nicht selten kam es vor, dass wir Software-Leute Fehler und Unzulänglichkeiten der Hardware ausbügeln mussten. Einige der Hardware-Kollegen wurden nachdenklich und begannen damit, über Qualitätsmaßnahmen im Hardware-Entwurf nachzudenken.

Da Hardware meist mühselig gegossen, zersägt, verschraubt und geschliffen werden muss, ist jeder Hardware-Entwurfsfehler sehr teuer. Auch mit der Verbreitung der Höchstintegration von Schaltkreisen sahen Elektroingenieure alt aus, wenn Schaltungen, die in Chips gegossen waren, sich als fehlerhaft erwiesen. Von dem Moment an, als Mikrocode im Hauptspeicher residierte, erhielten dessen Entwickler eine zweite Chance. Bei den Anwendungsentwicklern herrschte lange Zeit die Meinung vor, Software sei ‚soft‘, d.h. weich. Man könne alles ändern, auch noch nach der Auslieferung. Hätte unsere Industrie den an sich naheliegenden Weg beschritten, auch Software mittels Nur-Lese-Speichern zu verteilen, wären der Branche viele Probleme erspart geblieben. Die Erosion des kommerziellen Marktes durch Open Source, Raubkopien und das Virenproblem (siehe oben) sind nur einige. Nicht zuletzt das amerikanische Justiz-Ministerium hat dafür gesorgt, dass Hardware und Software getrennte Wege gingen. ‚Unbundling‘ nannte man das. Dass dies auch den Ruf der Software-Entwickler auf lange Sicht beschädigte, war ein Kollateralschaden, den man in Kauf nahm.

Auf der positiven Seite muss anerkannt werden, dass der Software-Markt eine unglaubliche Dynamik erreichte. Es gab eine unvorhersehbare Expansion der Anwendungen und eine Flexibilität der Angebote, die nur erreicht wurde, weil Software relativ frei wiederverwandt werden konnte, und zwar über Firmengrenzen hinweg. Was oft der Hardware gegenüber als Nachteil empfunden wird, ist der große inhärente Vorteil von Software. Software-Entwickler können in einem Maße auf Wünsche der Nutzer reagieren, der für Hardware undenkbar ist. Würde Software in Silizium gegossen, dann wäre Software nicht besser als Hardware.

Natürlich könnte die Situation in der Software noch besser sein, als sie ist. Ein Ansatzpunkt könnte in der Ausbildung liegen. Ich kann mich des Eindrucks nicht erwehren, dass an vielen Hochschulen immer noch Amateurgeist und Naivität gelehrt werden. Drückt man es drastischer aus, so kann auch von Leichtsinn und Halbwissen gesprochen werden. So ergab eine erst kürzlich veröffentlichte Umfrage (GI Seminar S-13, 2014, S. 159), dass die Entwickler-Motivation dann am größten ist, wenn den Entwicklern keinerlei Auflagen bezüglich der Gestaltung des Entwicklungsprozesses gemacht werden. Das erinnerte mich an Diskussionen der 1960er Jahre, als einige von uns damit begannen, persönliche Arbeitsstile durch einen systematischeren Prozess zu ersetzen. Ich kann nur hoffen, dass aus diesen Umfrage-Ergebnissen nicht die Konsequenz gezogen wird, alles was seit 1960 gelernt wurde, wieder über Bord zu werfen.

Leider ist systematisches Arbeiten, das der Qualität (und der Kreativität) einen hohen Stellenwert einräumt, nicht von sich aus unterhaltend und motivierend. Die Befriedigung kann nicht in der Tätigkeit allein gesucht werden, sondern sollte das Ergebnis der Tätigkeit mit berücksichtigen. Wenn man gute Ergebnisse für wichtiger hält als den Spaß an der Arbeit, dann muss man ein klein wenig nachdenken. Die Maßnahmen, die auf eine hohe Qualität der Ergebnisse in der Software-Entwicklung zielen, habe ich schon des Öfteren angesprochen. Ein Beitrag über die Software-Entwicklungsmethoden der NASA, die ich in dieser Hinsicht als mustergültig ansehe, liegt erst zwei Monate zurück. Zusammengefasst lautet mein Ratschlag: Man muss zuerst alle möglichen Fehlerursuchen gedanklich erfasst haben, um dann die technischen und organisatorischen Gegenmaßnahmen ergreifen zu können, um die spezifischen Fehler zu verhüten oder zu eliminieren. Das ist leider geistige Knochenarbeit. Sie ist für oberflächliche Typen nicht besonders geeignet.

NB: Unsere Branche ist  ̶  um  Evgenij Morozovs Terminologie zu verwenden  ̶  wie keine andere dem Epochalismus verfallen. Morozov nennt es auch technologische Amnesie. Immer wieder erscheinen Heilslehrer, die verkünden alles Alte zu vergessen, denn gerade habe ein neues Zeitalter begonnen. Nicht die Heilslehrer sind unser Problem, sondern die vielen (so genannten) Fachexperten, die ihnen glauben und folgen, statt sich eigene Gedanken zu machen. ‚Sapere aude!‘ sagte schon Horaz.