Wissenschaftliche Untersuchungen (z.B. eine der Carnegie Mellon University aus 2003) belegen, dass moderne Software, wenn sie in Betrieb genommen wird, i.A. immer noch bis zu fünf Fehler pro 1000 Lines of Code enthält; sprich: etwa 1 Fehler auf je 3 DIN A4 Seiten manuell erstellten Source Codes.
Selbst in den besten aller je untersuchten (größeren) Programme fand sich immer noch 1 Fehler in je 7500 Zeilen Code.
Wären mathematische Publikationen auch nur annähernd so fehlerhaft, wäre die Mathematik als Wissenschaft sicher längst in sich zusammen gebrochen (denn dort bauen neue Ergebnisse ja stets auf älteren auf).
Wir sehen: Die Informatik — wenigstens aber ihre Technik zur Qualitätssicherung — steckt heute wohl noch in Kinderschuhen, die vergleichbar sind mit denen, die die Mathematik zu Zeiten von Aristoteles, Pythagoras und Euklid trug.
Und wird man sich leisten können, damit noch lange zu leben?
ggreiter 
Comments
Das sind wirklich heftig große Zahlen.
Aber die Sache mit dem Aufeinanderaufbauen habe wir doch auch in der Informatik. Wer kennt es nicht: Man nehme ein beliebiges Framework, welches 1000 Funktionen bietet, von denen man 10 braucht. Mit einer Wahrscheinlichkeit von p=1 wird mindestens eine dieser 10 Funktionen nicht korrekt funktionieren. Zumindest ist das meine Erfahrung.
Hi Stefan,
auf den ersten Blick könnte man meinen, Du hast recht – dennoch ist dem nicht so, denn:
Mathematik besteht aus mathematischen Gesetzen einerseits und mathematischer Methodik andererseits.
Mathematische Gesetze existieren unabhängig davon, ob der Mensch sie kennt oder nicht – er kann sie lediglich entdecken (nicht aber erzeugen).
Mathematische Methodik aber ist des Menschen Weg, über mathematische Gesetze nachzudenken (d.h. sie zu entdecken und zu lernen, wie sie auf einander aufbauen).
Die Methodik der Mathematik verallgemeinert sich – in der Informatik – zum Software Engineering. Die den Programmen innewohnende Logik aber (ein Algorithmus) ist methodischer Spezialfall davon.
Neu entdeckte mathematische Gesetze sind in vollem Umfang Folge schon vorher bekannter mathematischer Gesetze (oder Axiome) – eben deswegen kann man sie als Wahrheiten nur entdecken aber nicht (wie Algorithmen) erfinden.
Neue Programme aber sind (als Algorithmen, als Methodik also) keineswegs in vollem Umfang logische Folge schon vorhandener Algorithmen:
Die Tatsache, dass neuer Programmcode nur zum kleinen Teil logische Konsequenz der Basissoftware (z.B. der Middleware) ist, auf der er aufbaut, ist der Hauptgrund dafür, dass er in großen Teilen auch dann noch Sinn machen wird, wenn die Basissoftware Fehler enthält. Nur: Je mehr Fehler sie enthält, desto mehr wird auch auf ihr aufbauender Applikationscode unsinniges Verhalten aufweisen.
Die Mathematik kennt keine derart halben Sachen: Wo ein Mathematiker von einer nicht wirklich zutreffenden Voraussetzung oder von auch nur einer falschen Formel ausgeht, entwertet das i.A. sein gesamtes Arbeitsergebnis.
Daher also kommt es, dass Programmcode selbst dann noch nützlich sein kann (und es i.A. in hohem Maße auch wirklich ist), wenn er – wie etwa MS Windows oder die Middleware, von der Du sprichst – eine große Zahl kleiner oder größerer Fehler enthält.
Mathematische Aussagen aber, wenn nicht absolut fehlerfrei, sind wertlos.
[Das ist auch verständlich, denn mathematische Ergebnisse sind größtenteils Existenzaussagen oder Formeln. Nur numerische Ergebnisse, zu denen man eine obere Grenze für ihre Ungenauigkeit kennt, sind nützlich auch ohne ganz genau zu sein.]
Fehlerhafte Mathematik führt sich selbst ad absurdum – Software aber kann (bis zu einer gewissen Schmerzgrenze hin) mit Fehlern leben.
Dieser fundamentale Unterschied also war gemeint, wo ich schrieb "denn dort [in der Mathematik] bauen neue Ergebnisse ja stets auf älteren auf".
Man könnte es auch anders sagen: In der Mathematik zählen nur Aussagen, die nachweislich in vollem Umfang wohldefiniert und wahr sind. Hauptgegenstand der Informatik (sowie der Ingenieurwissenschaften ganz allgemein) aber sind Aussagen und Ergebnisse, die man als hinreichend brauchbar einstuft.
Die spannende Frage, die sich mir stellt ist:
Kann es auf Dauer akzeptabel bleiben, dass Programme nur hinreichend brauchbar sind (und damit auch gefährlich werden können)? Es gibt ja schon mindestens einen Fall, in dem mehrere Menschen eines Softwarefehlers wegen zu Tode kamen. Siehe Therac-25 medical Accelerator.
Wer erkennt, wie schwierig es ist, die typische Fehlerdichte in Software signifikant zu reduzieren, wird – als Ingenieur wenigstens – fragen:
Gibt es Wege, mit den Fehlern zu leben?.
Mir sind nur zwei präsent (doch sie haben Grenzen):
Weg 1: Man kann und sollte in Programme Redundanz einbauen und Defensivcode, der über solche Redundanz erkennen kann, wenn ein Programm, während es abläuft, beginnt Unsinn zu machen. Es kann dann angehalten werden noch bevor Schaden entsteht.
Weg 2: Code-Interpreter sollten fehlertolerant arbeiten. Gutes Beispiel fehlertoleranter Software sind moderne Web Browser und die Definition von HTML5 (im Gegensatz zur Definition von XHTML). Ihr erklärtes Ziel ist, HTML-Seiten selbst dann noch korrekt – wenigstens aber sinnvoll – präsentieren zu können, wenn solcher Code zahlreiche Fehler enthält.
Gute Entwickler zeichnen sich dadurch aus, dass sie beide Wege gehen.
Dennoch: Viele logische Fehler lassen sich allein schon ihrer Natur nach weder über Redundanz erkennen noch über fehlertolerante Interpreter unschädlich machen. Wir müssen also doch weiter nach Wegen suchen, die Fehlerdichte zu verkleinern.