Keine Vermeidungsstrategie kann Bugs allein verhindern

Der Anbieter eines Codescanners, der Software mit der Methode der statischen Analyse nach Fehlern durchforstet, hat sich Ende vergangenen Jahres den Linux-Kern 2.6.32 des Android-Betriebssystems 2.2 Froyo für das Smartphone HTC Droid Incredible angesehen. Dabei fand er in rund 765 000 Zeilen Code nachweislich 359 Fehler, davon 88 kritische, die zu Buffer Overflows oder Ähnlichem führen könnten [1].

Das Unternehmen Coverity, Hersteller des Tools, bemerkte, dass das rund 0,47 Fehler pro 1000 Zeilen Code ergibt. Als Durchschnitt gilt für professionell entwickelte Software etwa ein Fehler pro 1000 Zeilen. So gesehen hat der Android-Kernel ziemlich gut abgeschnitten.

Auch in anderen Bereichen wurde im Laufe nur eines Jahres eine Vielzahl durchaus spektakulärer Softwarebugs entdeckt, sie hielten die Anwender, IT-Abteilungen und Entwickler in Atem: Einige der Probleme mit Automobilbremsen seien auf Programmfehler zurückzuführen, erklärt ein Dienstleister für Softwarequalität und führt weitere Beispiele an: Da dem Vernehmen nach Bankkarten Zeitstempel als dezimale Darstellung der Jahre nach 2000 speichern, gab es Anfang 2010 einen Überlauf, der dazu führte, dass Geldautomaten kein Geld rausrückten. Ein weiterer Programmfehler ließ I-Phone-Besitzer Anfang dieses Jahres einige Tage länger als vorgesehen in süßen Träumen schlummern, da der Timer fehlerhaft programmiert war.

Vermeiden und beheben

Die Liste ließe sich beliebig fortführen. Ohne die Folgen in konkreten Fällen kleinreden zu wollen, lassen sich bislang die Auswirkungen auf makroskopischer Ebene meist gut überschauen. Sobald sich Probleme offenbaren, geht es meist ziemlich schnell, bis der Verursacher sie behebt – oder mindestens einen Workaround anbietet. Dass mancher Datenbankriese oder Betriebssystemhersteller solche Angelegenheiten gern erst mal verschweigt, ist eine andere Geschichte. Dennoch ist es erstaunlich, dass sich etwa eine Software, die Hersteller in Monaten oder Jahren entwickelt haben, binnen Tagen reparieren lässt.

Außerdem steht zu hoffen, dass jeder Fehlschlag einen Lernerfolg verursacht. Viele Lernverfahren der künstlichen Intelligenz verbessern sich beispielsweise nur dann, wenn ein Ergebnis nicht zufriedenstellend ausfiel. Dann versuchen sie einen anderen Weg. Beim Menschen klappt das "Trial and Error" allerdings nicht immer, anders lassen sich die konzeptionell gut erforschten Buffer Overflows und dereferenzierten Nullzeiger kaum erklären.

"Da muss man doch etwas tun!", stöhnen Entwickler jetzt sicher auf. Doch wenn es darum geht, sich auf effektive Reaktions- und Präventionsmaßnahmen zu einigen, gibt es nur selten einen Konsens. Die einen schwören auf technische Hilfe, etwa auf die statische Software-Analyse, auf dynamisch getypte Sprachen oder nicht ausführbare Stacks.

Damit lässt sich in der Tat eine Reihe von Schwachstellen entdecken. Den Methoden ist aber gemeinsam, dass zumindest das Muster der Fehler schon vorher bekannt sein muss. Gegen kreative Ideen, etwa die Speicherung der Gültigkeit in Jahren seit 2000, ist mit diesen Mitteln nur schwer beizukommen.

Andere fordern ein Umdenken bereits vor und während der Entwicklung: Qualifikation der Entwickler, ein stressfreies Arbeitsumfeld sowie Tests und Qualitätsmanagement sollen Fehler gar nicht erst entstehen lassen. Mancher, der so arbeiten muss, beklagt die Bürokratisierung der einst als Kunst angesehenen Software-Entwicklung. Vielleicht vermag wieder Goethe beide Lager zu vereinen, der im Prolog zu seinem "Faust" trotz allem feststellt: "Ein guter Mensch, in seinem dunklen Drange, ist sich des rechten Weges wohl bewusst."