Warum Software so schlecht ist

Es ist einer der ältesten Witze im Internet, endlos von E-Mailbox zu E-Mailbox weitergeleitet. Ein Software-Mogul – normalerweise Bill Gates, manchmal aber auch ein anderer – hält eine Rede. Wenn sich die Automobilindustrie wie die Softwareindustrie entwickelt hätte, proklamiert der Mogul, würden wir alle 25-Dollar-Autos fahren, die 1.000 Meilen auf die Gallone bringen. Worauf ein Automobilmanager erwidert: Ja, und wenn Autos wie Software wären, würden sie ohne Grund zweimal am Tag abstürzen, und wenn man den Service rief, sagten sie einem, den Motor neu zu installieren.

Der Witz fasst eines der großen Rätsel der zeitgenössischen Technologie zusammen. In erstaunlich kurzer Zeit ist Software für fast jeden Aspekt des modernen Lebens entscheidend geworden. Von Banktresoren bis zu Stadtampeln, von Telefonnetzen bis zu DVD-Playern, von Auto-Airbags bis zu Flugsicherungssystemen – die Welt um uns herum wird durch Codes reguliert. Doch viele Software funktioniert einfach nicht zuverlässig: Fragen Sie jeden, der gesehen hat, wie ein Computerbildschirm blau angelaufen ist und stundenlangen Aufwand verloren hat. Allzu oft sagen Softwareingenieure, Code sei aufgebläht, hässlich, ineffizient und schlecht gestaltet; selbst wenn Programme richtig funktionieren, finden Benutzer sie zu schwer zu verstehen. Unter dem Gewicht ziegelsteinartiger Handbücher ächzend, zeugen die Regale der Buchhandlungen im ganzen Land von der anhaltenden Dysfunktionalität von Software.

Software ist heute einfach schrecklich, sagt Watts S. Humphrey, ein Stipendiat des Software Engineering Institute der Carnegie Mellon University, der mehrere bekannte Bücher über Softwarequalität geschrieben hat. Und es wird immer schlimmer. Gute Software ist nach Humphreys Ansicht verwendbar, zuverlässig, fehlerfrei, kostengünstig und wartbar. Und Software ist jetzt nichts davon. Sie können nichts aus der Box nehmen und wissen, dass es funktioniert. Nach Ansicht von Edsger W. Dijkstra, einem emeritierten Informatiker an der University of Texas in Austin, wurde der durchschnittliche Computerbenutzer im Laufe der Jahre so schlecht bedient, dass er erwartet, dass sein System die ganze Zeit abstürzt, und wir erleben eine massive weltweite Verbreitung fehlerbeladener Software, für die wir uns zutiefst schämen sollten.



Jim McCarthy ist großzügiger. Der Gründer, mit seiner Frau Michele, eines Trainingsunternehmens für Softwarequalität in Woodinville, WA, McCarthy ist der Ansicht, dass die meisten Softwareprodukte über die notwendigen Funktionen verfügen, um den Kauf, die Verwendung und die Einführung wert zu sein. Aber, so räumt er ein, nur die extreme Nützlichkeit von Software lässt uns ihre großen Mängel tolerieren. McCarthy beginnt seine Vorträge an seiner Schule manchmal mit einer PowerPoint-Präsentation. Die erste Folie lautet: Most Software Sucks.

Es ist schwer, die Einzigartigkeit der Probleme von Software zu betonen. Wenn Automobilingenieure über die Autos auf dem Markt sprechen, sagen sie nicht, dass Fahrzeuge heute nicht besser sind als vor zehn oder fünfzehn Jahren. Das gleiche gilt für Luftfahrtingenieure: Niemand behauptet, dass Boeing oder Airbus lausige Flugzeuge bauen. Auch beschweren sich Elektroingenieure nicht darüber, dass sich Chips und Schaltungen nicht verbessern. Wie der Ingenieurhistoriker Henry Petroski in seinem Buch von 1992 vorgeschlagen hat Die Evolution nützlicher Dinge , ständige Weiterentwicklung ist die übliche Regel in der Technik. Ingenieure bemerken ständig Mängel in ihren Konstruktionen und beheben sie nach und nach, ein Prozess, den Petroski ironisch als Form folgt dem Scheitern beschrieb. Infolgedessen verbessern sich Produkte inkrementell.

Software scheint leider anders zu sein. Man würde erwarten, dass ein 45-Millionen-Zeilen-Programm wie Windows XP, das neueste Betriebssystem von Microsoft, einige Fehler enthält. Und Software Engineering ist eine neuere Disziplin als Maschinenbau oder Elektrotechnik; die ersten richtigen Programme wurden erst vor 50 Jahren erstellt. Überraschend und sogar erstaunlich ist, dass viele Softwareingenieure glauben, dass sich die Softwarequalität nicht verbessert. Wenn überhaupt, sagen sie, wird es schlimmer. Es ist, als ob die Autos, die Detroit im Jahr 2002 produzierte, weniger zuverlässig waren als die Autos, die 1982 gebaut wurden.

Da Software immer wichtiger wird, werden die möglichen Auswirkungen von schlechtem Code entsprechend zunehmen, so Peter G. Neumann, Informatiker bei SRI International, einem privaten Forschungs- und Entwicklungszentrum in Menlo Park, Kalifornien. Allein in den letzten 15 Jahren haben Softwarefehler einen europäischen Satellitenstart zerstört, die Eröffnung des enorm teuren Flughafens von Denver um ein Jahr verzögert, eine Marsmission der NASA zerstört, vier Marinesoldaten bei einem Hubschrauberabsturz getötet, ein Schiff der US Navy zur Zerstörung veranlasst ein Zivilflugzeug, und schloss Krankenwagensysteme in London, was zu bis zu 30 Todesfällen führte. Und wegen unserer wachsenden Abhängigkeit vom Netz, sagt Neumann, geht es uns viel schlechter als noch vor fünf Jahren. Die Risiken sind schlimmer und die Abwehrkräfte sind nicht so gut. Wir gehen rückwärts – und das ist eine beängstigende Sache.

Einige Softwareunternehmen reagieren auf diese Kritik, indem sie ihre Verfahren überarbeiten; Microsoft, gestochen von Vorwürfen, dass seine Produkte fehlerhaft sind, ist öffentlich führend. Doch Probleme mit der Softwarequalität bestehen so lange und scheinen so hartnäckig in die Softwarekultur eingebettet zu sein, dass einige Programmierer beginnen, das Undenkbare zu denken. Zu ihrem eigenen Erstaunen fragen sich diese Leute, ob das eigentliche Problem mit Software darin besteht, dass nicht genügend Anwälte beteiligt sind.

Ein Mangel an Logik

Microsoft veröffentlichte Windows XP am 25. Oktober 2001. Am selben Tag veröffentlichte das Unternehmen, was möglicherweise ein Rekord ist, 18 Megabyte von Patches auf seiner Website: Fehlerkorrekturen, Kompatibilitätsaktualisierungen und Verbesserungen. Zwei Patches haben wichtige Sicherheitslücken geschlossen. Oder besser gesagt, einer von ihnen tat es; der andere Patch hat nicht funktioniert. Microsoft riet (und rät) Benutzern immer noch, kritische Dateien zu sichern, bevor die Patches installiert werden. Käufer der Home-Version von Windows XP stellten jedoch fest, dass das System keine Möglichkeit bot, diese Sicherungsdateien wiederherzustellen, wenn etwas schief ging. Wie die Online-Wissensdatenbank von Microsoft blöd erklärt hat, funktionieren die speziellen Backup-Disketten, die von Windows XP Home erstellt wurden, nicht mit Windows XP Home.

Kritiker sagen, solche Ausrutscher seien lediglich oberflächliche Versäumnisse – ein Zeichen dafür, dass die Entwickler der Software zu voreilig oder zu nachlässig waren, um offensichtliche Mängel zu beheben. Die wahren Probleme liegen laut R. A. Downes von Radsoft, einem Software-Beratungsunternehmen, im grundlegenden Design der Software. Oder besser gesagt, es ist Mangel des Designs. Die beliebte Programmiersoftware Visual Studio von Microsoft ist ein Beispiel für Downes’ Denkweise. Downes hat festgestellt, dass das einfache Platzieren des Cursors über dem Visual Studio-Fenster die Zentraleinheit mit Tausenden von unnötigen Nachrichten unsichtbar überflutet, obwohl das Programm nichts tut. Es ist katastrophal. Es ist das totale Chaos, beschwert er sich.

Das Problem ist nach Ansicht von Dan Wallach, Informatiker an der Rice University, nicht das sinnlose Aufwühlen des Prozessors – schließlich sei die Rechenleistung billig. Auch Microsoft-Software ist nicht besonders fehlerhaft; Kritiker verwenden die Produkte des Unternehmens oft eher als Beispiele, weil sie bekannt sind, als weil sie ungewöhnlich schlecht sind. Stattdessen verrät die blühende, summende Verwirrung in Visual Studio und so vielen anderen Programmen aus Wallachs Ansicht, dass die Techniken zum Schreiben von Software mit der explosionsartigen Zunahme ihrer Komplexität nicht Schritt gehalten haben.

Programmierer schreiben Code in Sprachen wie Java, C und C++, der von Menschen gelesen werden kann. Spezialisierte Programme, sogenannte Compiler, wandeln diesen Code in die von Computern verwendeten Zeichenfolgen aus Einsen und Nullen um. Wichtig ist, dass Compiler sich weigern, Code mit offensichtlichen Problemen zu kompilieren – sie spucken stattdessen Fehlermeldungen aus. Bis in die 1970er Jahre saßen Compiler auf großen Mainframes, die oft Tage oder Wochen im Voraus ausgebucht waren. Um nicht zu verhindern, dass Fehler Verzögerungen verursachen, blieben Programmierer – die in der Anfangszeit eher als Mathematiker oder Physiker ausgebildet wurden – lange in ihren Büros und überprüften ihre Arbeit gründlich. Das Schreiben von Software war ähnlich wie das Schreiben wissenschaftlicher Arbeiten. Strenge, Dokumentation und Peer-Review-Überprüfung waren an der Tagesordnung.

Aber mit der Verbreitung von Computern änderte sich die Einstellung. Anstatt Code akribisch zu planen, blieben die Programmierer in koffeinhaltigen Hacking-Sitzungen die ganze Nacht wach und gaben ständig Ergebnisse vom Compiler ab. Immer wieder spuckte der Compiler Fehlermeldungen aus; die Programmierer korrigierten die Fehler nacheinander, bis die Software richtig kompiliert war. Die heutige Einstellung ist, dass Sie jeden schlampigen Code schreiben können und der Compiler eine Diagnose durchführt, sagt Neumann von SRI. Wenn es keine Fehlermeldung ausspuckt, muss es richtig gemacht werden, oder?

Mit zunehmender Größe und Komplexität der Programme wurden jedoch die Grenzen dieses Code- und Fix-Ansatzes offensichtlich. Laut einer mehrjährigen Studie von Humphrey von Carnegie Mellon mit 13.000 Programmen machen professionelle Programmierer pro tausend Codezeilen, die sie schreiben, durchschnittlich 100 bis 150 Fehler. Nach Humphreys Zahlen wäre das Business-Betriebssystem Windows NT 4 mit seinen 16 Millionen Codezeilen also mit rund zwei Millionen Fehlern geschrieben worden. Die meisten wären zu klein gewesen, um irgendeine Wirkung zu haben, aber einige – viele Tausende – hätten ernsthafte Probleme verursacht.

Natürlich hat Microsoft NT 4 vor der Veröffentlichung ausführlich getestet, aber in fast jeder Testphase werden Sie weniger als die Hälfte der Fehler finden, sagt Humphrey. Hätte Microsoft vier Testrunden durchlaufen, ein teures und zeitaufwendiges Verfahren, hätte das Unternehmen höchstens 15 von 16 Fehlern gefunden. Das wird Sie mit ungefähr fünf Fehlern pro tausend Codezeilen zurücklassen, sagt Humphrey. Was sehr gering ist - aber die Software hätte immer noch bis zu 80.000 Fehler.

Software-Ingenieure wissen, dass ihr Code oft voller Lücken ist, und suchen seit langem nach neuen Technologien, um diese zu vermeiden. Um immer umfangreicher werdende Projekte wie beispielsweise Windows zu verwalten, haben sie eine Vielzahl von Techniken entwickelt, von denen die vielleicht bekannteste das komponentenbasierte Design ist. So wie Häuser mit standardisierten Zweier- und Elektrogeräten gebaut werden, werden komponentenbasierte Programme aus modularen, austauschbaren Elementen aufgebaut: Ein Beispiel ist die nahezu identische Menüleiste auf jedem Windows- oder Macintosh-Programm. Solche standardisierten Komponenten, so Wallach, seien nicht nur gute Ingenieurspraxis, sondern die einzige Möglichkeit, etwas von der Größe von Microsoft Office überhaupt zum Laufen zu bringen. Microsoft, sagt er, war ein früher, aggressiver Befürworter dieses Ansatzes – es ist die beste technische Entscheidung, die sie je getroffen haben.

Leider, sagen Kritiker, werden die Bauteile oft ohne wirklichen zentralen Plan zusammengeklebt – als ob Bauunternehmer versucht hätten, große Bauwerke ohne Baupläne zu errichten. Unglaublich, sagt Humphrey, das Design für große Softwareprojekte sei manchmal nichts anderes als ein paar Blasen auf der Rückseite eines Umschlags. Schlimmer noch, Unternehmen verdrahten aus Marketinggründen möglichst viele Features in neue Software und wirken so den Vorteilen der modularen Bauweise entgegen. Das am weitesten verbreitete Beispiel ist Windows selbst, von dem Bill Gates in einer April-Sitzung des Microsoft-Kartellprozesses aussagte, würde einfach nicht funktionieren, wenn Kunden einzelne Komponenten wie Browser, Dateimanager oder E-Mail-Programme entfernen würden. Das ist ein unglaublicher Anspruch, sagt Neumann. Es bedeutet, dass es keine Struktur oder Architektur, keinen Reim oder Grund in der Art und Weise gibt, wie sie diese Systeme erstellt haben, außer sie so gebündelt wie möglich zu machen, damit, wenn Sie einen Teil entfernen, alles fehlschlägt.

Kritiker argumentieren, dass die unzureichende Gestaltung der Endprodukte eine unzureichende Planung bei deren Herstellung widerspiegelt. Laut einer Studie der Standish Group, einer Beratungsfirma in West Yarmouth, MA, werden kommerzielle Softwareprojekte in den USA so schlecht geplant und verwaltet, dass im Jahr 2000 fast ein Viertel komplett abgebrochen wurde und kein Endprodukt entstand. Die stornierten Projekte kosten die Unternehmen 67 Milliarden US-Dollar; Überschreitungen bei anderen Projekten brachten weitere 21 Milliarden US-Dollar ein. Da Code und Fix jedoch zu so umfangreichen und kostspieligen Testrunden führen, können selbst erfolgreiche Projekte äußerst ineffizient sein. Unglaublicherweise widmen Softwareprojekte oft 80 Prozent ihres Budgets für die Behebung von Fehlern, die sie selbst erstellt haben - eine Zahl, die den noch kostspieligeren Prozess der Bereitstellung von Produktsupport und der Entwicklung von Patches für Probleme, die nach der Veröffentlichung festgestellt wurden, nicht einschließt.

Systemtests dauern fast die Hälfte des Prozesses, sagt Humphrey. Und selbst wenn sie es endlich zum Laufen bringen, gibt es immer noch kein Design. Folglich kann die Software nicht mit der Gewissheit aktualisiert oder verbessert werden, dass die Aktualisierungen oder Verbesserungen keine schwerwiegenden Fehler verursachen. So wird überall Software entworfen und gebaut – in Raumschiffen, um Gottes willen.

Ist Software ein Sonderfall?

Die potenziellen Risiken von schlechter Software wurden zwischen 1985 und 1987 düster illustriert, als ein computergesteuertes Strahlentherapiegerät, das von der staatlich unterstützten Atomic Energy of Canada hergestellt wurde, Patienten in den Vereinigten Staaten und Kanada massiv überdosierte und mindestens drei tötete. In einer ausführlichen Untersuchung wies Nancy Leveson, heute Informatikerin am MIT, einen Großteil der Schuld auf die unzureichenden Software-Engineering-Praktiken des Herstellers zurück. Da das Programm zum Einstellen der Strahlungsintensität nicht sorgfältig entwickelt oder getestet wurde, lösten einfache Tippfehler tödliche Explosionen aus.

Trotz dieser tragischen Erfahrung überdosierten ähnliche Maschinen, auf denen Software von Multidata Systems International aus St. Louis ausgeführt wurde, 2000 und 2001 Patienten in Panama massiv, was zu acht weiteren Todesfällen führte. Ein Team der Internationalen Atomenergiebehörde führte die Todesfälle auf die Eingabe von Daten zurück, die Programmierer nicht erwartet hatten. Wie Leveson feststellt, sollten einfache Dateneingabefehler keine tödlichen Folgen haben. Auch dieser Fehler kann also auf unzureichende Software zurückzuführen sein.

Programmierexperten sind sich einig, dass solche Katastrophen erschreckend häufig sind. Betrachten Sie den Mars Climate Orbiter und den Polar Lander, die beide 1999 durch bekannte, leicht verhinderte Codierungsfehler zerstört wurden. Einige argumentieren jedoch, dass Software einfach nicht auf dieselbe Weise wie andere technische Produkte beurteilt, gemessen und verbessert werden kann. Es ist einfach eine Tatsache, dass es Dinge gibt, die andere Ingenieure tun können, die wir nicht können, sagt Shari Lawrence Pfleeger, eine leitende Forscherin beim Rand Think Tank in Washington, DC und Autorin des Bandes von 2001 Software Engineering: Theorie und Praxis . Wenn eine Brücke ein Gewicht von 500 Kilogramm und ein Gewicht von 50.000 Kilogramm überlebt, so Pfleeger, können Ingenieure davon ausgehen, dass sie alle Werte dazwischen trägt. Mit Software, sagt sie, kann ich diese Annahme nicht treffen – ich kann nicht interpolieren.

Darüber hinaus sind Softwarehersteller unter außergewöhnlichen Anforderungen. Ford und General Motors stellen seit Jahrzehnten dasselbe Produkt her – eine vierrädrige Box mit einem Verbrennungsmotor. Infolgedessen, so Charles H. Connell, ehemaliger leitender Ingenieur von Lotus Development (jetzt Teil von IBM), konnten sie ihre Produkte schrittweise verbessern. Aber Softwareunternehmen werden ständig aufgefordert, Produkte zu entwickeln – Webbrowser in den frühen 1990er Jahren, neue Mobiltelefonschnittstellen heute – anders als alles zuvor Gesehene. Es ist, als ob ein Autohersteller sagt: Dieses Jahr bauen wir statt eines Autos eine Rakete“, sagt Connell. Natürlich werden sie Probleme haben.

Das klassische Dilemma bei Software ist, dass die Leute immer mehr und mehr Dinge wollen, sagt Nathan Myhrvold, ehemaliger Chief Technology Officer von Microsoft. Leider führe die ständige Nachfrage nach Neuheiten dazu, dass sich Software immer in der neuesten Phase befinde, in der Produkte von Natur aus weniger zuverlässig sind. 1983, sagt er, habe Microsoft Word nur 27.000 Zeilen Code gehabt. Das Problem ist, dass es nicht viel gebracht hat – was die Kunden heute nicht akzeptieren würden. Hätte Microsoft Word nicht immer wieder mit neuen Features aufgepumpt, gäbe es das Produkt nicht mehr.

Benutzer sind enorm nicht selbstbewusst, fügt Myhrvold hinzu. Bei Microsoft forderten Firmenkunden oft, dass das Unternehmen gleichzeitig neue Funktionen hinzufügte und keine neuen Funktionen mehr hinzufügte. Ich habe es buchstäblich in einem einzigen Atemzug, einem einzigen Satz gehört. Wir sind uns nicht sicher, warum wir auf diese neue Version aktualisieren sollten – sie enthält all das, was wir nicht wollen – und wann werden Sie diese drei Dinge einbauen?“ Und Sie sagen, was?“ Myhrvolds sardonische Zusammenfassung: Software nervt, weil die Benutzer es verlangen.

Höhere Standards

Im Januar rief Bill Gates Microsoft-Mitarbeiter dazu auf, zuverlässiger und sicherer Datenverarbeitung höchste Priorität einzuräumen. In einer der wichtigsten Initiativen des Unternehmens seit Jahren forderte Gates, dass Microsoft die Anzahl der Fehler in seinen Produkten drastisch reduziert. Einen Monat später unternahm das Unternehmen den beispiellosen Schritt, das Schreiben von neuem Code für fast zwei Monate auszusetzen. Stattdessen versammelten sie Tausende von Programmierern auf einmal zu Massenschulungen über Zuverlässigkeit und Sicherheit. Auf riesigen Bildschirmen in einem riesigen Auditorium zeigten Führungskräfte des Unternehmens peinliche Schnipsel fehlerhaften Codes, die von den Zuschauern erstellt wurden.

Gates' Initiative wurde offenbar von der heftigen Kritik inspiriert, die Microsoft im Juli 2001 überkam, als ein Pufferüberlauf – eine seit langem bekannte Art von Fehler – in seiner Webserver-Software für Internetinformationsdienste dazu führte, dass der Code Red-Wurm Tausende seiner Unternehmenskunden zum Opfer fiel. (Bei einem Pufferüberlauf empfängt ein Programm mehr Daten als erwartet – als ob man das Feld für eine Postleitzahl mit einer 50-stelligen Zahl ausfüllt. In einem Computer werden die zusätzlichen Informationen in benachbarte Teile des Speichers übertragen und beschädigt oder überschrieben die Daten dort, es sei denn, sie werden sorgfältig blockiert.) Zwei Monate später nutzte der Nimda-Wurm andere Fehler in der Software aus, um Tausende weiterer Maschinen anzugreifen.

Von solchen Erfahrungen geschlagen, achten Softwareentwickler immer mehr auf Qualität. Noch während Gates seine Truppen sammelte, entwickelten Denkfabriken wie das Kestrel Institute in Palo Alto, Kalifornien, Programmier-Toolkits, die nach Konstruktion korrekte Programmiertools enthalten, die Programmierer fast dazu zwingen, zuverlässige Programme zu schreiben ( siehe Erste Hilfe bei fehlerhaftem Code ). Bei Microsoft selbst, so Amitabh Srivastava, Leiter des Programmer Productivity Research Centers der Firma, arbeiten Programmierer mit neuen, höheren Sprachen wie C#, die bestimmte Fehler nicht zulassen. Im Mai gründete Microsoft zusammen mit der NASA und 16 anderen Firmen das 30 Millionen US-Dollar teure Sustainable Computing Consortium mit Sitz in Carnegie Mellon, um standardisierte Methoden zur Messung und Verbesserung der Softwarezuverlässigkeit zu fördern. Die Bemühungen um die Qualitätskontrolle können sich lohnen: Um Lockheed Martin bei der Überarbeitung der Software in seinem C130J-Flugzeug zu unterstützen, hat Praxis Critical Systems aus Bath, England, mit solchen Methoden die Entwicklungskosten um 80 Prozent gesenkt und gleichzeitig Software entwickelt, die strenge Prüfungen der Federal Aviation Administration bestanden sehr wenige Fehler.

verbergen