Universitat Potsdam

Ausarbeitung in der Ring-Veranstaltung Medienproduktion im Wandel

Lernt die Informatik aus Fehlern?

Uber negatives Wissen und seine Chancen

Jan Brennenstuhl

 Universitat Potsdam

Institut fur Informatik

Ausarbeitung in der Ring-Veranstaltung Medienproduktion im Wandel

Lernt die Informatik aus Fehlern?

Uber negatives Wissen und seine Chancen

Does computer science learn from mistakes?

About negative knowledge and its chances

Bearbeiter: Betreuer: Abgabedatum:

Jan Brennenstuhl, B.Sc. Prof. Dr. Klaus Rebensburg 31. Mrz 2012 a

The scientist builds in order to study; the engineer studies in order to build. Fred Brooks, 1996

Abstract

Aus Fehlern lernen meint im Grunde genommen Handlungen wie Fehleranalyse und Ursachenforschung, die als Folge eines Fehlerereignisses ausgefhrt werden und zudem als negau tives Wissen zuknftige Ttigkeiten beeinussen. Ziel dieser Arbeit ist es heruaszustellen, u a ob die Informatik aus ihren Fehlern lernt und weiterhin herauszustellen welche Chancen dieses negative Wissen fr die Wissenschaft im Allgemeinen und die Informatik im Speziu ellen bereit hlt. Dazu werden im Folgenden die Grundlagen erfahrungsbasierten Wissens a beschrieben, werden ausgewhlte Katastrophen der Informatik und weiterhin auch testgea triebene Software-Entwicklung erlutert. Erwartet wird, dass die jetzige wissenschaftliche a Fehlerkultur nur in Anstzen dazu geeignet ist, aus ihren Fehlern zu lernen und das es einem a Kulturwechsel bedarf, um Wissenschaft und Forschung ezienter und qualitativ hochwertiger gestalten zu knnen. o

VI

Inhaltsverzeichnis
1 Einleitung 2 Grundlagen erfahrungsbasierten Wissens 2.1 Negatives Wissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Aus Fehlern lernen 3.1 Katastrophen der Informatik . . . . . . . . . . 3.1.1 Der Pentium-Bug . . . . . . . . . . . . . 3.1.2 Die Ariane 5 Explosion . . . . . . . . . 3.1.3 Das Denver-Koer-Debakel . . . . . . . 3.2 Negatives Wissen in der Software-Entwicklung 3.3 Exkurs: Testgetriebene Entwicklung . . . . . . 3.4 Negatives Wissen in der Informatik . . . . . . . 4 Fazit Literaturverzeichnis Web-Quellenverzeichnis Glossar 1 3 3 5 5 5 6 6 6 7 8 11 IX XI XIII

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

VII

1 Einleitung
Fehler, also Merkmalswerte beziehungsweise Zustnde, die die vorgegebenen Forderungen a nicht erfll[en] und somit als Nichterfllung einer Anforderung(DIN 9000 2005) gesehen u u werden, sowie das Begehen von Fehlern gehren genauso zum Leben im Allgemeinen wie auch o zur Informatik als Wissenschaft im Speziellen. Fehler ermglichen es uns Menschen, aus iho nen zu lernen und auf diese Weise neue Erkenntnisse zu erlangen. Sie werfen neue Fragen auf, rufen neue Probleme hervor, die wiederum unter Einuss einer nicht zu unterschtzenden a Fehlerquote gelst werden knnen. Kurz: Fehler sagen uns nicht nur, was etwas nicht ist o o und wie etwas nicht funktioniert, sondern knnen auch zur Klrung des Warums (warum o a bestimmte Zusammenhnge nicht stimmen) beitragen (vgl. Oser u. Spychiger 2005, S. 26). a Dennoch sind Fehler verpnt. Insbesondere in Wissenschaften und auch in der recht juno gen Informatik gilt das Begehen von Fehlern hug als Untergrabung der eigenen Expertise, a die sich, so die Befrchtung, durch Reputationsverlust und ngerzeigende Reaktionen Dritu ter uert. Wer einen Fehler macht, hat versagt - so eine verbreitete Ansicht (vgl. Unger a 2009, S. 1). Dabei kann eine positive Fehlerkultur in der Wissenschaft, eine die begangene Fehler dokumentiert, publiziert und diskutiert, nicht nur zu einem Mehr an Erkenntnissen fhren, wie nachfolgend erlutert wird, sondern wirkt auf gleiche Weise als Vorbild u a fr die gesamte Gesellschaft. Insbesondere die Informatik verfgt hierbei uber ausreichend u u groe Mglichkeiten und nutzt diese bereits mit Bug-Tracking1 Systemen und Wikis2 zur o Fehlerdokumentation, zwar nicht in theoretisch-wissenschaftlichen aber dafr verbreitet in u praktisch-anwendungsorientieren Bereichen. In den nachfolgenden Kapiteln soll betrachtet werden, inwiefern die Informatik aus Bugs und verschieden klassifzierbaren Fehlern lernt und welche Chancen ein etabliertes Forum fr u negative Ergebnisse im Bezug auf die Vermeidung der kleinen und groen Katastrophen der Informatik haben kann. Dazu werden zunchst allgemeine Grundlagen erfahrungsbasierten a Wissens erlutert sowie positives und negatives Wissen gegeneinander abgegrenzt. Beispiele a fr negative Ergebnisse und ein vorausschauendes Fazit runden diese Ausarbeitung ab. u

Als Bug-Tracker werden Werkzeuge fr die Softwareentwicklung bezeichnet, mit Hilfe derer sich Programmu fehler und ihre Lsungen erfassen und dokumentieren lassen, um auf diese Weise fr nachfolgende Ento u wicklungen recycled zu werden. Sie ermglichen es Software-Entwickler/innen demnach auch, aus den o Fehlern und Lsungsanstzen Anderer zu lernen. o a 2 Bei einem Wiki, hawaiisch fr schnell, handelt es sich um speziell auf die Kollaboration und Interaktiu on ausgerichtete Content-Management-Systeme (CMS), die auch in der Software-Entwicklung zur projektbergreifenden Dokumentation von Anforderungen, Problemen und Lsungsanstzen genutzt werden. u o a

2 Grundlagen erfahrungsbasierten Wissens

Wissen ist Macht - So oder hnlich beschrieb Francis Bacon bereits 1597, zu einer Zeit in der a das vorherrschende, durch Traditionen bestimmte Wissensmodell uberwiegend Autoritten a zugestandt, Wissen anzuhufen und weiterzugeben, die Bedeutung von Erkenntnissen. Zwar a geht auch heutzutage Wissenszuwachs oft mit gesellschaftlicher Aufwertung einher, Herkunft und Natur von Wissen haben sich allerdings weiterentwickelt und gipfeln in dem heute gngigen Modell der Wissenschaft. Dieses basiert in erster Linie auf nachvollziehbaren Beoba achtungen, sowie auf uberprfbaren Erklrungen, die als Modelle oder Theorien formuliert u a werden und erschat somit uberprfbare und vor allem falsizierbare Ansichten. u Diese Widerlegbarkeit der Ergebnisse ist es, die die heutige Wissenschaft von Religion unterscheidet. Sie ist es allerdings auch, die zusammen mit einem zunehmenden Wettkampf der Forschungseinrichtungen untereinander dafr sorgt, dass im Alltag zumeist Informationen u zu geglckten Experimenten angetroen werden. Auf diese Weise wird das Bild einer von u der Idee uber die Uberprfung und das Experiment bis hin zum Erfolg geradlinig verlauu fenden Forschung vermittelt, das allerdings nur wenig mit der Realitt zu tun hat. Es ist a gerade der Irrtum, der neben gescheiterten Versuchen eine Wissenschaft ausmacht, wrde u doch die Durchfhrung von Experimenten, deren Resultate mit absoluter Sicherheit feststeu hen, keinerlei Erkenntniszuwachs bedeuten. Dennoch und auch aufgrund einer mangelnden Fehlerkultur gibt es bis auf wenige Ausnahmen kaum Anlauf- und Publikationsstellen fr u Wissenschaftler, die ihre Irrtmer und fehlgeschlagenen Experimente verentlichen wollen u o (Freistetter 2011). Um im weiteren Verlauf dieser Arbeit uberprfen zu knnen, welchen Einuss das Veru o o entlichen eben jener negativen Ergebnisse auf die Wissenschaft im Allgemeinen und die Informatik im Speziellen haben kann, wird im Folgenden negatives Wissen, als eine spezielle Form des Erfahrungswissens, nher erlutert und gegenber positivem Wissen abgegrenzt. a a u

2.1 Negatives Wissen

Der Begri des negativen Wissens lsst sich nach Oser u. Spychiger (2005) gut mit der Mea tapher der Spiegelseite der Dinge erlutern und wird von ihnen in vier Typen (negativ a deklarativ, negativ prozedural, negativ strategisch und negativ schemata-orientiert) unterteilt, die sich auf alle Bereiche des Lebens und damit auch auf die Wissenschaft anwenden lassen. Demnach beschreibt negatives Wissen (im Gegensatz zu positivem Wissen) beispielsweise nicht, welche Strategien zur Lsung komplizierter Probleme geeignet sind, sondern o welche es nicht sind und schat somit eine Art Abgrenzungswissen, das es ermglicht an o a hnlichen Problemen nicht immer mit den gleichen Strategien zu scheitern, sondern neue, eventuell erfolgreiche Strategien zu entwickeln.

2 Grundlagen erfahrungsbasierten Wissens Der Besitz negativen Wissens bringt somit verschiedene Vorteile mit sich, die sich zunchst a in einer Art Schutzmantel uern, der davor schtzt in gleichen oder hnlichen Situationen a u a die gleichen Fehler wieder zu begehen und somit sich selbst oder anderen zu schaden bzw. eine Aufgabe nur suboptimal oder garnicht zu lsen (Unger 2009). Dieses Schutzwissen lsst o a sich wiederum in einen inneren und einen ueren Teil unterscheiden. Ersterer bezeichnet ein a Warnsystem, welches auf konkreten Erinnerungen basiert, auf gemachte Fehler verweist und somit das Wiederholen eines Fehlers einschrnken kann. Als ueres Schutzwissen werden a a Warnhinweise in der Umwelt bezeichnet, die beispielsweise als Warnschilder oder Sicherheitshinweise auftreten und an abstrakte, unkonkrete Fehlersituationen erinnern (vgl. Unger 2009, S. 10). Es bedarf allerdings einer ausreichend groen emotionalen Bindung, um das Schutzwissen eektiv arbeiten zu lassen. Diese wird erst durch das Begehen von Fehlern ermglicht und erfordert somit, neben der Einsicht, dass ein Fehler aufgetreten ist, eine auso geprgte Fehlerkultur (vgl. Oser u. Spychiger 2005, S. 27). a Wie und ob dieses Wissen um die Macht des negativen Wissens den Erkenntniszuwachs von Wissenschaftlern beschleunigen kann, wird nachfolgend am Beispiel der Informatik, mit dem Ziel zu klren, ob diese junge Wissenschaft aus ihren Fehlern lernt, genauer betrachtet. a Dazu werden Fehler zunchst in verschiedene Arten unterteilt und prominente, auf Fehler a zurckzufhrende historische Katastrophen beschrieben, bevor anschlieend Empfehlungen u u fr ein eektives Nutzen negativen Wissens in der Wissenschaft formuliert werden. u

3 Aus Fehlern lernen

Nachdem im vorangegangenen Kapitel die Vorteile negativen Wissens herausgestellt wurden, kann an dieser Stelle festgehalten werden, dass die Konzepte des negativen Wissens und die damit einhergehenden Fhigkeiten, aus Fehlern lernen zu knnen, der Informatik a o nicht fremd sind. Insbesondere im Fachbereich der knstlichen Intelligenz (KI) wird veru sucht, intelligentes Verhalten, wie zum Beispiel Bedauern1 , auf Maschinen und Programme zu ubertragen und auf diese Weise auch menschliche Fehlerroutinen fr Computer nutzbar u zu machen. Aber auch in der weniger forschungsorientierteren Software-Entwicklung lassen sich zumindest Anstze, sich negativen Wissens zu bedienen, nden. So kommen mit Buga Trackern spezialisierte Anwendungen zum Einsatz, deren vordergrndigstes Ziel sich in der u zentralisierten Sammlung und Verwertung aller whrend des Software-Entwicklungsprozesses a gemachten Fehler uert. Im Folgenden wird diese Entwicklung aufgegrien und dargelegt, a wie auf der einen Seite die Software-Entwicklung und auf der Seite Informatik als Wissenschaft aus ihren Fehlern lernen knnen. Zunchst werden allerdings einige der populrsten, o a a da kostenintensivsten Katastrophen der Informatik auszughaft vorgestellt.

3.1 Katastrophen der Informatik

Angefangen bei Laufzeitfehlern aufgrund von Divisionen durch Null und O-By-One-Fehlern2 , bis hin zum Ausfall von Hardware existiert wegen der hohen Komplexitt von Computera systemen eine Vielzahl mglicher Bugs. Die zunehmende Computerisierung erweitert demo nach nicht nur Mglichkeiten und Chancen der Entwickler, mit ihren Systemen und Proo grammen umzugehen, sondern verschrft auf gleiche Weise auch ihre Verantwortung fr die a u Verlsslichkeit, knnen doch bereits kleine Fehler die unwissentlich oder nicht in einem Coma o puter auftreten, wirtschaftlichen Schaden in Milliardenhhe verursachen, Menschenleben o gefhrden oder umfangreiche Katastrophen auslsen (vgl. Klauer 2004). Zu den populrsten a o a Katastrophen der Informatik zhlen neben dem Pentium-Bug und der Ariane 5 Explosion a auch der Verlust des Mars Climate Orbiters, das sogenannte Denver-Koer-Debakel, der Y2K Millenium-Bug sowie viele weitere. Einige Ausgewhlte werden im Folgenden beschrieben: a

3.1.1 Der Pentium-Bug

Kurz nachdem Intel 1994 mit umfangreichen Werbekampagnen (Stichworte wie Pentium und intel inside sind noch heute bekannt) seine neue Prozessorgeneration, die sich durch eine verbesserte Architektur und der Uberarbeitung des Divisions-Algorithmus fr Flieu kommazahlen auszeichnete, auf dem Markt platziert hatte, wurde bekannt, dass der neue
1

Bedauern beschreibt hier das Lernen aus dem Abstand zwischen gewnschten und tatschlichen Ergebnis u a und wird beispielsweise an der Universitt Tel Aviv, untersttzt vom Internet-Giganten Google Inc., a u erforscht (vgl. Mayer 2011). 2 O-By-One-Fehler sind ein in der Software-Entwicklung hug anzutreendes Logikproblem der Indiziea rung, bei dem Speicher- oder Puergrenzen um einen Schritt uberschritten werden.

3 Aus Fehlern lernen Fliekommazahlen-Algorithmus Fehler produzieren konnte. Die Folge der weltweiten Publicity, die Intel im Zuge der Markteinfhrung fr den Pentium gewann, sowie die eher mangelhaft u u einzuschtzenden, durch Verheimlichen und Aussitzen des Problems geprgten Reaktionen a a nach Bekanntwerden des Bugs, war die kostspieligste Rckrufaktion in der Geschichte der u Halbleiterindustrie. Ausgelst wurde das Problem durch fnf falsche Eintrge in einer Tao u a belle und der daraus resultierenden fehlerhaften Ubertragung auf die Hardwareebene (vgl. Ljepoja u. a. 2003).

3.1.2 Die Ariane 5 Explosion

Als im Juni 1996 die Ariane 5 Rakete der Europischen Weltraumbehrde (ESA) auf ihrem a o Jungfernug explodierte, entstand nicht nur ein direkter Schaden von ungefhr 1,7 Milliarden a DM sondern wurden zudem die Ergebnisse der zehnjhrigen Entwicklungszeit, mit Entwicka lungskosten von etwa 11,8 Milliarden DM, gefhrdet. Das Ziel der unbemannten Rakete, die a sich Sekunden nach dem erfolgreichen Start selbst zerstrte, war die Befrderung von vier o o identischen Satelliten in den Orbit. Ausgelst wurde der Selbstzerstrungsprozess durch ein o o Versagen des Trgheitsnavigationssystems, zustndig fr die Positionsbestimmung der Rakea a u te im Raum, aufgrund dessen die Rakete auseinander zu brechen drohte. Als Grund fr das u Versagen des Systems machte die eigenes eingesetzte Untersuchungskommission ungeschtzte u Variablen verantwortlich, die whrend der Entwicklung aufgrund fehlerhafter Spezikatioa nen und der Verwendung technischer Daten des Vorgngermodells Ariane 4 als uberlaufsicher a klassiziert worden waren (vgl. Riedl 2002).

3.1.3 Das Denver-Koer-Debakel

Zwischen 1993 und 1994 gab es mehrere Versuche, den Flughafen in Denver neu zu ernen. o Integraler Bestandteil der neuen Abfertigungsanlagen war ein softwaregesttztes, voll auu tomatisches Gepcksystem, das zwischen 150 und 300 Computer3 mit Laserscannern und a Photozellen in einem Ethernet-Netzwerk verband und dessen Ziel es war, den Abfertigungsprozess eektiver zu gestalten. Aufgrund der hohen Komplexitt des Gesamtproblems, der a damit einhergehenden Informations- und Nachrichtendichte und der daraus resultierenden Uberlastung des LAN, konnten Sortier- und Transportanweisungen nicht rechtzeitig verarbeitet werden. Fehlende oder zerquetschte Koern waren die Folge, weshalb das Gepck a wieder von Hand sortiert werden musste. Die Verluste und Kosten durch die fehlerhafte Anlage summierten sich am Ende auf etwa 3,2 Milliarden US-Dollar (vgl. Huckle 1999).

3.2 Negatives Wissen in der Software-Entwicklung

Trotz der Popularitt dieser und hnlicher Beispiele ist die Annahme, dass hnliche Fehler a a a in Zukunft ausbleiben, eher unwahrscheinlich. Es ist insbesondere die Komplexitt der bea troenen Systeme, die es notwendig macht, Modelle mathematisch und durch eingehende Simulationen zu verizieren, sowie Toleranzen und Redundanzen zu integrieren, um auch nicht vorhersehbare oder unwahrscheinliche Fehlerquellen so gut wie mglich eliminieren zu o knnen (vgl. Klauer 2004). Die Komplexitt ist es auch, die es beinahe unmglich macht auf o a o Grundlage von einzelfallbasiertem negativen Wissen spezische Bugs zu vermeiden. Dennoch haben Software-Entwickler, insbesondere die Vertreter agiler Vorgehensmodelle, aus
3

Die unterschiedlichen Angaben verschiedener Quellen lassen keine genaue Aussage zu.

3.3 Exkurs: Testgetriebene Entwicklung den Fehlern ihrer Vorgnger gelernt und beispielsweise mit der testgetriebenen Entwicklung a (TDD) neue, qualittsbewusste Programmiertechniken etabliert, die einen entscheidenden a Teil zu einer positiveren Fehlerkultur in der Software-Entwicklung beitragen knnen. o

3.3 Exkurs: Testgetriebene Entwicklung

Als testgetriebene Entwicklung wird eine qualittsbewusste Programmiertechnik beschriea ben, die es ermglicht, Software dem agilen Manifest4 folgend, iterativ, in kleinen Schritten o zu entwickeln. Die Besonderheit und gleichzeitig das Unterscheidungsmerkmal zu anderen Anstzen oder dem klassischen Vorgehen besteht darin, dass bei der testgetriebene Entwicka lung automatisierte Unit-Tests5 intensive Verwendung nden, die als explizite Anforderungen an den Code auftreten und es nicht nur ermglichen, Software in kleinen, ubersichtlichen Eino heiten zu prfen, sondern Programmierer auf gleiche Weise bei der korrekten Entwicklung u zu untersttzen. Weiterhin erlauben es automatisierte Akzeptanztests auch, die Anforderunu gen des Kunden an das komplette Produkt testbar zu machen, indem sie ein Programm als integrierte Einheit betrachten (Westphal 2006, S. 2f). Die Leitidee des testgetriebenen Vorgehens ist das sogenannte Tests-First-Denken. Ziel dabei ist es, bereits vor der Implementierung des zu testenden Produktiv-Codes Testflle a aufzustellen und darauf aufbauenden Testcode zu entwickeln, der die Anforderungen an die zu programmierende Logik explizit deniert und die Korrektheit uberprft. Der Testsu First-Ansatz basiert im Wesentlichen auf folgenden drei Gesetzen (Martin 2007, S. 32):
Erstes Gesetz - Schreiben sie erst Produktions-Code, wenn sie einen scheiternden Unit-Test geschrieben haben. Zweites Gesetz - Der Unit-Test darf nicht mehr Code enthalten, als fr ein Scheitern u notwendig ist. Jeder Test sollte genau eine Sache prfen. u Drittes Gesetz - Es darf nur so viel Produktions-Code geschrieben werden, wie fr u das Bestehen des Tests ntig ist. o

Der daraus resultierende Workow entspricht folglich einem Kreislauf, der mit dem Schreiben eines Tests beginnt (Phase 1). Durch das Testen von Funktionalitt, die (noch) nicht a vorhanden ist, wird infolgedessen ein Fehler im System erzeugt, der anschlieend durch das Erstellen des eigentlichen Programm-Codes behoben wird (Phase 2). Whrend des abschliea enden sogenannten Refactorings (Phase 3) werden Code-Duplizierung entfernt, eventuell notwendige Abstraktionen eingefgt, Code-Smells6 beseitigt, gngige Style-Konventionen u a
4

Das Manifesto for Agile Software Development(Beck u. a. 2001) wurde 2001 entlichkeitswirksam publio ziert und zog eine Welle wissenschaftlicher aber auch populistischer Auseinandersetzungen nach sich. Allein die Online-Suche der amerikanischen Webseite des weltweit agierenden Online-Warenhauses Amazon.com, Inc. listete im Februar 2012 uber 1,600 Publikationen die den Begri Agile software development im Namen tragen oder direkt mit ihm assoziiert sind. 5 Unit-Tests uberprfen in der Regel jeweils nur wenige Zeilen Quellcode (der Unit) (Kbeck 2009, S. 46). Prou u grammbibliotheken wie JUnit fr Java, NUnit fr .Net oder hnliche Portierungen liefern dafr notwendige u u a u Programmbausteine und ermglichen als quelloene Bibliotheken Tests ohne proprietre Werkzeuge zu o a entwickeln. 6 Code-Smells, also schlechte Code-Gerche, bezeichnen subjektive Indizien fr schlechten Code, denen in u u der Regel ein tiefer liegendes Problem im System zugrunde liegt (Westphal 2006, S. 75).

3 Aus Fehlern lernen umgesetzt und der Code so in seine (temporr) einfachste Form gebracht (Pilone u. Miles a 2008). Damit einher geht ferner die Notwendigkeit eines evolutionren Designs, welches den a agilen Charakter von TDD ein weiteres Mal unterstreicht. So wird das Design der Software nicht im Voraus und in seiner Detailiertheit geplant, viel eher kommt es im Laufe der Entwicklung zu (temporren) Design-Entscheidungen, die sich im Wesentlichen auf die vora denierten Testflle sttzen und somit, wie auch die Code-Entwicklung, einem iterativen a u Prozess untergeordnet sind. Auf diese Weise existiert im Idealfall zu jeder Zeit der Software-Entwicklung nur so viel Code wie unbedingt ntig, der zudem in hohem Mae mit Testfllen abgedeckt ist und soo a mit nicht nur ausschlielich seine Anforderungen erfllt (das tut was er soll), sondern auch u ubersichtlich und nachvollziehbar bleibt. Den Entwicklern wird so ermglicht, einen exako 7 ) Programm-Codes erhalten zu ten Uberblick uber die Korrektheit des (beinahe gesamten knnen, was sie wiederum befhigt, untersttzt durch die automatisiert laufenden Tests, o a u Bugs und Probleme bereits whrend der Entwicklung erkennen zu knnen und des Weiteren a o verpichtet auf diese auftretende Fehler zeitnah zu reagieren. Im Gegensatz zu klassischen Software-Entwicklungsprozessen wie dem Wasserfall- oder V-Modell (als Extrembeispiele), die eine sogenannte Test-Phase oft an das Ende ihrer Prozesskette hngen, ermglicht TDD Tests zeitnah zur eigentlichen Programmierung zu erstela o len und sorgt somit dafr, dass diese nicht unter Zeitdruck wegrationalisiert werden. Zudem u fhren die automatisierte Wiederholbarkeit und das durch die Gesetze der TDD implizit u notwendige huge Kompilieren des Quellcodes nicht nur dazu, dass Tests selbst unter Zeita druck ausgefhrt werden knnen, sondern ermglichen auch das Erkennen von Fehlern und u o o Seiteneekten gleich bei ihrer Entstehung. Ein eektives Testen ist die Folge. Testgetriebene Entwicklung versetzt EntwicklerInnen demnach auf der einen Seite in die Lage, mit Hilfe von automatisierten Tests vom Beginn der Programmierarbeit an die funktionale Qualitt a der Software zu bewahren und gestattet es durch fortlaufendes Refactoring zudem auch, die strukturelle Qualitt zu erhalten (vgl. Westphal 2006, S. 4). Folglich wird das Risiko, a Bugs oder andere Probleme, wie sie der Ausgangspunkt fr die im vorangegangenen Kapiu tel beschriebenen Katastrophen der Informatik waren, im Produktionscode zu hinterlassen deutlich gesenkt. Die Software-Entwicklung hat mit TDD in jngster Zeit somit Konzepte u etabliert, die den Schluss zulassen, durchaus aus ihren vergangenen Fehlern gelernt zu haben.

3.4 Negatives Wissen in der Informatik

Im Gegensatz zur ingenieurisch geprgten Software-Entwicklung, bei der in erster Linie die a Entwicklung und Produktion marktreifer Software und seltener die Erforschung neuer Konzepte im Vordergrund steht, ist die Erkenntnisgewinnung in der Wissenschaft zentraler Bestandteil, weshalb das Aus-Fehler-Lernen hier auch eine andere Bedeutung besitzt. So geht es weniger um Konzepte, die wie TDD dazu beitragen Fehler zu vermeiden, sondern viel eher um die Dokumentation von Irrtmern und fehlgeschlagenen Experimenten, denn wie u bereits in Kapitel 2 erwhnt, verluft Wissenschaft nicht geradlinig, sondern besteht zu eia a
7

Je nach Programm und Programmiersprache unterscheidet sich der Umfang der eektiv zu erreichenden Testabdeckung. Eine hundertprozentige Testabdeckung wird nur in Ausnahmefllen erreicht und ist aufa grund des relativ groen Overheads nur bedingt erstrebenswert.

3.4 Negatives Wissen in der Informatik nem groen Teil aus falschen Annahmen, fehlgeschlagenen Versuch und Irrtum. Dennoch werden diese Fehlschlge, verglichen mit erfolgreichen Experimenten und Gea dankengngen, allerdings nur selten der Oentlichkeit zugnglich gemacht, was zu einem a a Groteil an der etablierten Publikationskultur der Wissenschaften liegt, die spektakulren a Ergebnissen einen besonderen Stellenwert einrumt, da diese im Anschluss mit hherer Wahra o scheinlichkeit zitiert werden und auf diese Weise einen Reputationsgewinn des Forschenden einleiten und sich darber hinaus besser verkaufen lassen. Als Folge dieser einseitigen Beweru tung von Ergebnissen werden wissenschaftliche Fehlschlge, nicht nur durch die Forschenden a sondern auf gleiche Weise durch die Publikationsorgane, als unspektakulr und unpraktikaa bel eingestuft (Freistetter 2011). Dabei ist es genau dieses negative Wissen, das helfen knnte, auch in der international o weit verzweigten Informatik, aus den Fehlern Anderer zu lernen, auf der einen Seite kostbare Forschungsmittel und Zeit einzusparen und auf der anderen Seite unerwartete oder unklare Ergebnis genauer zu erforschen. Ein Kulturwechsel wre angebracht und wird mit a international steigenden Studierendenzahlen und einer immer weiter vernetzten Forschergemeinde zunehmend zwingend notwendig, um im Sinne der Wissenschaft festzuhalten, welche Anstze aus welchen Grnden nicht zielfhrend waren. Auf diese Weise wre es mglich, a u u a o den wissenschaftlichen Forscherdrang weg von bereits fehlgeschlagenen Experimenten und Untersuchungen hin zu einer eektiveren Erforschung bisher noch nicht untersuchter Gegenstnde zu kanalisieren. a Doch solange es beispielsweise mit dem Forum for Negative Results8 (FNR) oder dem Journal of Unsolved Questions9 (JUnQ) nur wenige kleine Herausgeber fr negative Ergebu nisse gibt, die zudem mehrheitlich eher ein Schattendasein fristen, ist die Wissenschaft im Allgemeinen und die Informatik im Speziellen weit davon entfernt, aus ihren Fehlern zu lernen.

8 9

http://page.mi.fu-berlin.de/prechelt/fnr/ http://junq.info

4 Fazit
Die Chancen, die negatives Wissen fr Forschung und Wissenschaft bereit hlt, sind enorm u a und bewegen sich zum einen im Bereich der Optimierung von Forschungsmitteln durch die Vermeidung von Mehrfachuntersuchungen des gleichen, bereits fehlgeschlagenen Experiments und zum anderen im Bereich Lenkung wissenschaftlicher Arbeit. Das Lernen aus Fehlern ist integraler Bestandteil des Lebens und obwohl einige Teilbereiche der Informatik, wie beispielsweise die Software-Entwicklung wie gezeigt werden konnte in Anstzen aus ihren Feha lern gelernt haben, weigert sich die ubergeordnete Wissenschaft (mit wenigen Ausnahmen) aufgrund von historisch gewachsenen Fehler- und Publikationskulturen stetig diese Chancen zu erkennen und sie fr sich zu nutzen. u Ein umfangreicher Kulturwechsel innerhalb der Wissenschaft ist somit unabdingbar, um Forschung ezienter und qualitativ hochwertiger zu gestalten. Die Informatik als recht junge Wissenschaft wre prdestiniert dafr, den ersten Schritt in diese Richtung zu unternehmen a a u und neben ihren oft einussreichen Errungenschaften auch negative Ergebnisse, Fehlinterpretationen und unplausible Ideen im groen Stil zu publizieren. Das Internet macht es mglich, o dies auch ohne kommerzielle Publikationsorgane selbstorganisiert umzusetzen.

11

Literaturverzeichnis
Beck u. a. 2001 Beck, Kent ; Beedle, Mike ; Bennekum, Arie van ; Cockburn, Alistair ; Cunningham, Ward ; Fowler, Martin ; Grenning, James ; Highsmith, Jim ; Hunt, Andrew ; Jeffries, Ron ; Kern, Jon ; Marick, Brian ; Martin, Robert C. ; Mellor, Steve ; Schwaber, Ken ; Sutherland, Je ; Thomas, Dave: Manifesto for Agile Software Development. The Agile Alliance, 2001 DIN 9000 2005 DIN EN ISO 9000:2005-12, Qualittsmanagementsysteme - Grundlagen und Begrie. a Beuth Verlag, 2005 Kubeck 2009 K beck, Sebastian: Software-Sanierung - Weiterentwicklung, Testen und Refactoring u bestehender Software. mitp Verlag, 2009 Martin 2007 Martin, Robert C.: Professionalism and Test-Driven Development. IEEE Computer Society Press, 2007 Oser u. Spychiger 2005 Oser, F. ; Spychiger, M.: Lernen ist schmerzhaft: Zur Theorie des negativen Wissens und zur Praxis der Fehlerkultur. Beltz, 2005. ISBN 9783407253736 Pilone u. Miles 2008 Pilone, Dan ; Miles, Russ: Softwareentwicklung von Kopf bis Fu. OReilly Verlag, 2008 Unger 2009 Unger, M.: Negatives Wissen im Kontext einer positiven Fehlerkultur. GRIN Verlag GmbH, 2009. ISBN 9783640435678 Westphal 2006 Westphal, Frank: Testgetriebene Entwicklung mit JUnit & FIT - Wie Software a nderbar bleibt. dpunkt Verlag, 2006

IX

Web-Quellenverzeichnis
Freistetter 2011 Freistetter, Florian ; Fraunhofer-Gesellschaft (Hrsg.): Die Entdeckung des Scheiterns. Version: August 2011. http://www.forschungs-blog.de/dieentdeckung-des-scheiterns/, Abruf: 14. Mrz 2012 a Huckle 1999 Huckle, Thomas: Kleine BUGs, groe GAUs. Version: 1999. http://www5.in.tum. de/~huckle/bugs.html, Abruf: 21. Mrz 2012 a Klauer 2004 Klauer, Bernd: Die Katastrophen der Informatik. Version: Juli 2004. http://www.ti.informatik.uni-frankfurt.de/lehre/ss04_wissenschaftliche_ dokumentation/book/node17.html, Abruf: 21. Mrz 2012 a Ljepoja u. a. 2003 Ljepoja, Boris ; Pfennig, Thomas ; Rosenegger, Stefan: Der Pentiumbug. Version: 2003. http://www5.in.tum.de/lehre/seminare/semsoft/unterlagen_02/ pentiumbug/website/, Abruf: 21. Mrz 2012 a Mayer 2011 Mayer, Boris ; Allgemeine, Jdische (Hrsg.): Aus Fehlern lernen - Israelische Inforu matiker bringen Computern Bedauern bei. Version: Mai 2011. http://www.juedischeallgemeine.de/article/view/id/10323, Abruf: 21. Mrz 2012 a Riedl 2002 Riedl, Mathias: Ariane 5 - Absturz des Flugs 501. Version: 2002. http: //www4.in.tum.de/lehre/seminare/ps/WS0203/desaster/Riedl-Arianne5Ausarbeitung-27-11-02.pdf, Abruf: 21. Mrz 2012 a

XI

Glossar
Kurzel CMS ESA FNR JUnQ KI LAN TDD Beschreibung Content-Management-System European Space Agency Forum for Negative Results Journal of Unsolved Questions knstliche Intelligenz u Local Area Network Test-Driven Development 1 6 9 9 5 6 6

XIII