Fehleranalyse statt Bugfixing

Wie Sie Softwarefehler nicht nur beheben, sondern aus ihnen lernen

Jürgen Lampe

© Shutterstock.com / Bakhtiar Zein

Niemand scheitert gern. Dabei ist die Folge von Versuch und Irrtum die natürliche Basis jedes Lernens. Aus einem Fehlschlag lässt sich gewöhnlich sehr viel mehr lernen als aus einem schnellen und möglicherweise leichtsinnig machenden Erfolg. So gesehen müsste die IT-Branche eine unübertroffene Quelle nützlicher Erkenntnisse sein – ist sie aber nicht. Woran liegt das und wie könnte man das ändern?

Es ist seit Langem bekannt, dass ein erheblicher Teil der IT-Projekte abgebrochen wird oder die angestrebten Ziele nicht oder nicht vollständig erreicht. Aufgearbeitet wird dieses Problem jedoch fast ausschließlich auf der projektorganisatorischen Ebene. Das ist nicht falsch, lässt aber Wichtiges unberücksichtigt. Tatsächlich liegen Misserfolgen oft fehlerhafte Managemententscheidungen zu Grunde. Aber das ist nur ein Teil der Wahrheit. Der andere Teil wird gern hinter dem Motto „Einsatz unausgereifter Technologien“ eher versteckt als klar benannt. Was bedeutet „unausgereift“ in einem derart schnelllebigen Gebiet? Ist damit nicht eher gemeint, dass eine falsche Technologie oder auch die richtige Technologie falsch eingesetzt wurde?

Damit kommen wir zum Kern des Problems: Es gibt in der IT keine Fehler- und darauf basierende Lernkultur. Jeder frage sich selbst, wann er das letzte Mal eine Analyse gelesen hat, die sich mit den konkreten Problemen befasste, die sich aus dem Einsatz einer Software, eines Design- oder Architektur-Patterns oder eines Programmierstils ergeben hat?

Das ist das Schöne an einem Fehler: Man muss ihn nicht zweimal machen. – Thomas Alva Edison

Im Gegensatz dazu gibt es jede Menge Berichte, die uns glauben machen wollen, dass durch die Anwendung von XYZ die Softwareentwicklung zum Kinderspiel wird. Selbstverständlich lernt man auch aus Erfolgsbeispielen. Dabei erfährt man aber nicht, wie weit ein Konzept wirklich trägt. Grenzen kann man nur durch Scheitern erkunden. Wenn ein Seil einer Belastung von 20 N standhält, weiß ich zwar, dass es für 15 N reicht, aber nicht, ob das auch noch für 30 N gilt. Vielleicht ist es auch hoffnungslos überdimensioniert und hält 2 000 N aus. Genauso verhält es sich mit Erfolgsberichten.

Lesen Sie auch: Wie Sie technische Schulden in Architekturen abbauen

Umgang mit Fehlern am Beispiel der Luftfahrt

Flugzeuge lassen sich in ihrer Komplexität mit IT-Systemen vergleichen und verfügen zudem über zahlreiche softwaregesteuerte Funktionen. Ein Fehler kann fatale oder katastrophale Auswirkungen haben. Vor ihrer Freigabe müssen Flugzeuge deshalb unzählige Prüfungen und Zertifizierungsprozesse durchlaufen. Trotzdem lassen sich Fehler nicht vollständig verhindern, und es passieren Abstürze und andere Unfälle. Bemerkenswerterweise und in deutlicher Diskrepanz zur IT-Welt nimmt die Anzahl der erheblichen technikbedingten Vorkommnisse bei Flugzeugen seit Jahren ab, trotz wachsender Komplexität der Systeme, Zunahme des Verkehrs und Anstieg des Durchschnittsalters der Flotten. Diese erfolgreiche Entwicklung beruht vor allem darauf, dass es weitgehend gelingt, das Wiederholen von Fehlern zu verhindern. Erreicht wird das durch die sorgfältige Untersuchung aller relevanten Vorfälle durch unabhängige Inspektoren. In den meisten Ländern gibt es dazu Institutionen wie die Bundesstelle für Flugunfalluntersuchung (BFU) in Deutschland, die im Ergebnis ihrer Auswertungen dann auch Empfehlungen für das Beseitigen von Risiken aussprechen können. Die Prüfungen und Zertifizierungen gehen zu einem erheblichen Anteil auf solche Empfehlungen zurück. Derartige Untersuchungsberichte weisen einige wichtige Charakteristika auf:

  • Sie sind sehr detailliert: Sie enthalten nicht etwa „Der Pilot traf die falsche Entscheidung“, sondern eine genaue Beschreibung der Umstände und Einflüsse, unter denen diese Entscheidung getroffen wurde.
  • Varianten werden ausführlich diskutiert, da auch klar vorliegende Fakten immer unterschiedliche Interpretationen zulassen.
  • Der Fokus liegt auf der Aufklärung der Kausalitäten und Abläufe. Es ist nicht das Ziel, Verantwortliche (Sündenböcke) zu ermitteln.

Neben der Neutralität ist der letzte Punkt besonders wichtig, weil nur so die wirklich entscheidenden Fehlerquellen offengelegt werden können. Um Probleme in Zukunft vermeiden zu können, müssen sie klar benannt werden. Das geht nur, wenn persönliche Betroffenheit aus der Aufklärung herausgehalten wird.

Die Erarbeitung solcher Auswertungsberichte ist meist langwierig, schwierig und erfordert ausgeprägte Expertise. Das verursacht mithin erhebliche Kosten. Die hohe Sicherheit im Luftverkehr rechtfertigt diesen Aufwand und beweist die Richtigkeit einer solchen Strategie. In Bereichen wie Bahnverkehr, Reaktorsicherheit oder Bauaufsicht gibt es ähnliche Verfahren mit mehr oder weniger ausgeprägter Stringenz. So eindrucksvoll das geschilderte Beispiel sein mag, so schwierig ist es auf die IT-Welt zu übertragen, allein schon aus quantitativen Gesichtspunkten. Aber das heißt nicht, dass es nicht möglich wäre, nutzbringende Schlüsse zu ziehen.

Was sind Fehler?

Fehler sind jedes unerwünschte abweichende Verhalten einer Software, also nicht nur funktionale Fehler, sondern auch mangelnde Leistungsfähigkeit, zu hoher Ressourcenverbrauch, zu hohe Kosten oder verspätete Fertigstellung.

Umgang mit Fehlern in IT-Systemen

Ganz allgemein hat sich gegenüber Fehlern ein gewisser Fatalismus breit gemacht. Überraschung löst es eher aus, wenn Projekte ohne große Verzögerung und Mehrkosten abgeschlossen werden können. Mit dieser Haltung ignoriert man das Verbesserungspotenzial, das die konsequente Auswertung von Fehlern bietet. Natürlich ist es aus Kostengründen gar nicht möglich, jeden Fehler vollständig zu analysieren. Aber es muss das Bewusstsein dafür geschärft werden, dass jeder Fehler die Chance bietet, seine Wiederholung zu vermeiden. In der Softwareentwicklung findet sich häufig die Einstellung, dass es alte Projekte nicht wert seien, genauer untersucht zu werden, weil beim nächsten Projekt ein anderer Ansatz oder neue Tools gewählt werden. Das ist jedoch ein Irrtum. Denn viele Fehler, die eigentlich die gleiche Ursache haben, können in veränderten Umgebungen erneut auftreten.

Analyse von Fehlern

Um aus Fehlern effektiv lernen zu können, müssen diese gründlich aufgeklärt werden. Das ist nicht einfach und verursacht Aufwand, der sich nicht kurzfristig rechtfertigen lässt. Das Ziel der Aufklärung besteht ja nicht darin, den Fehler zu finden – das wäre Bugfixing –, sondern die Umstände aufzuklären, unter denen es zu diesem Fehler kommen konnte. Wenn das Problem erst nach der Abnahme auftritt, wäre beispielsweise die Frage zu klären, weshalb es keinen entsprechenden Testfall gab. Eine andere Frage, die viel zu oft unberücksichtigt bleibt, ist die nach der Angemessenheit der eingesetzten Tools und Frameworks. Da passiert zu viel nach dem Motto: Das machen doch alle so, das wird schon richtig sein.

Fehler können in allen Phasen der Softwareentwicklung verursacht werden. Gerade die nicht offensichtlichen Ursachen werden gern übersehen. Wie weit das reichen kann, sei an einem einfachen Beispiel erläutert: In einem kaufmännischen Programm wurde statt der Variablen kumulativerJahresUmsatz die Variable kumulativerJahresAbsatz als Parameter übergeben. Ganz klar: Da hat sich der Programmierer verschrieben. Doch warum ist das passiert? Sicherlich erhöhen so nah beieinander liegende Bezeichnungen die Verwechslungsgefahr, sie lassen sich aber nicht immer vermeiden. Möglicherweise taucht in den Designdokumenten nur der zweite Begriff auf, und der erste wurde später ergänzt, um bestimmte Sonderfälle zu behandeln. Vielleicht erfolgte irgendwann eine Umbenennung.

Das Beispiel soll illustrieren, dass Fehler in der Software zu einem erheblichen Teil auf Fehler in der Kommunikation zurückgehen, insbesondere auf sprachliche Nachlässigkeiten. Es wird wenig bedacht, dass Unklarheiten und fehlende Präzision in der Konzeption die Wahrscheinlichkeit von Fehlern in der Umsetzung erhöhen. Extrem wichtig ist dabei das genaue Erfassen und Einbeziehen dessen, was als Kontext häufig implizit vorausgesetzt wird. Klare und eindeutige Begriffe, die durchgängig von der Aufgabenbeschreibung bis in den Code verwendet werden, wirken qualitätssteigernd. Dies muss ergänzt werden durch einheitliche Regeln für die Bildung abgeleiteter Bezeichnungen im Code. Besonders eine leicht erkennbare Unterscheidung zwischen Singular und Plural verdient dabei Beachtung.

Wie wird analysiert?

Das oberste Grundprinzip bei der Fehleranalyse muss die Fokussierung auf die Ursachensuche sein. Nur so kann aus der Untersuchung nützliches Wissen entstehen. Es geht auf keinen Fall darum, Verantwortlichkeiten aufzuklären oder Schuldige zu finden. Als Vorbild können dabei effektive Codereviews dienen. Genau diese konstruktive und von Lernwillen geprägte Herangehensweise ist bei der Fehleranalyse gefragt. Wichtig ist, dass alle an der Analyse Beteiligten sich als gleichberechtigte Experten verstehen und hierarchische Strukturen vermieden werden.

In vielen Fällen ist ein Codereview der geeignete Ausgangpunkt. Allerdings sind die Fehler im Code aus dieser Sicht nur die Symptome der zu findenden Mängel. Abhängig von der Art der Fehler müssen weitergehende Hypothesen über mögliche Ursachen aufgestellt werden. Die Häufung von trivialen Schreibfehlern kann auf ungünstige Arbeitsbedingungen wie Lärm, häufig wechselnde Aufgaben oder persönliche Probleme zurückzuführen sein. Als weitere Faktoren kommen auch fehlende Kompetenzen im Entwickler- oder Designerteam in Betracht.

Die vielen verschiedenen zu berücksichtigenden Einflüsse erfordern für die Analyse möglichst breite Erfahrung über den gesamten Entwicklungsprozess. Dabei müssen für einzelne Teilaspekte jeweils entsprechende Spezialisten hinzugezogen werden. Überhaupt wird ein großer Teil der Arbeit aus Interviews mit den Beteiligten bestehen, weil das häufig die einzige Quelle ist, aus der Motive und Intentionen von Realisierungsentscheidungen ergründet werden können.

Außerdem sei noch erwähnt, dass das Ziel einer solchen Analyse nicht nur darin besteht, die genaue und einzige Ursache eines Fehlers zu finden. Oft wird es diese gar nicht geben oder sie lässt sich nicht mehr rekonstruieren. Der eigentliche Wert wird schon allein durch die Darstellung möglicher Szenarien und deren abwägende Diskussion erreicht. Deshalb ist ein Dokument, das diese Auswertung übersichtlich zusammenfasst, das eigentlich wertvolle Ergebnis der Analyse. Wenn es dann auch von möglichst vielen gelesen und beherzigt wird.

Wer analysiert?

Die Frage wer die Fehler analysieren soll kann sehr unterschiedlich beantwortet werden, weil das Schaffen unabhängiger Institutionen wohl illusorisch ist. Denkbar wäre immerhin, dass größere IT-Abteilungen ein Team von fähigen Auswertern mit Erfahrungen in Betrieb, Entwicklung und Business etablieren, die für ausgewählte Fehler die beschriebene tiefgründige Analyse vornehmen. Das ist auf jeden Fall sinnvoller, als wenn ein schnaubender CIO von seinem Entwicklungsleiter verlangt, dass bis Freitag 15:00 Uhr die Ursache geklärt sein muss. Das führt gewöhnlich dazu, dass nur oberflächlich Symptome erfasst werden, nicht aber die tiefer liegenden wahren Ursachen.

Eine interessante Möglichkeit könnte sich ergeben, wenn größere Consulting-Firmen im Anschluss an abgeschlossene Projekte nun ihre vormaligen Auftraggeber dafür bezahlen würden, solche Auswertungen vornehmen zu dürfen. Dass die Zahlungsrichtung dabei umgekehrt wird, ist angemessen, denn der Nutzen solcher Analysen kann durch sie in anderen Aufträgen realisiert werden. Ein Vorteil dieses Wegs läge auch darin, dass den externen Consultants das Projekt ja bereits bekannt ist und somit für den Kunden keine zusätzlichen Risiken bezüglich Geschäftsgeheimnisse entstehen. Gewinnen würden in diesem Szenario auf die Dauer alle.

Eine dritte etwas utopische Variante wäre die Versicherung des Erfolgs von Softwareprojekten. Das hätte ganz automatisch den Aufbau passender Kompetenzzentren zur Folge. Bei Brand- und Arbeitsschutz hat sich dieses Modell beispielsweise bewährt.

Schließlich sei auch die Informatik als Wissenschaft an ihre Aufgabe erinnert. Bedingt durch die starken mathematischen Wurzeln hat die analytische Beschreibung immer ein Schattendasein geführt. Der vor allem auf Innovationen ausgerichtete Zeitgeist hat diese ungute Tendenz noch verstärkt. Das ist auch ein Grund für die vielfach anzutreffende Entfremdung zwischen Praxis und universitärer Forschung. Um in dieser Situation nützliche Erkenntnisse gewinnen zu können, ist es nötig, Untersuchungsmethoden der deskriptiven Naturwissenschaften anzuwenden. Neben der hier betrachteten Fehleranalyse sollten dazu auch Experimente gehören, die beispielsweise den Einfluss von Änderungen auf die Performance oder Zuverlässigkeit untersuchen. Obwohl diese Tätigkeiten jahrhundertelang den Kern der Wissenschaft ausmachten, wird ihnen heute leider vielfach der wissenschaftliche Wert abgesprochen. Entsprechend selten findet man solche aufklärenden Arbeiten.

Projekt oder Produkt

Eine zu starke Fokussierung auf den Projekterfolg birgt die Gefahr, dass langfristig wichtige Eigenschaften des zu erstellenden Produkts vernachlässigt werden. Der Vergleich mit komplexen materiellen Produkten, seien es Industrieanlagen, Flugzeuge oder Autos, zeigt, dass selbst bei sorgfältiger Planung und Vorbereitung auf den Praxistest mit Vorserienprodukten nicht verzichtet werden kann. Aus dieser Perspektive liefern IT-Projekte gewöhnlich Ergebnisse, die den Charakter von Vorserienprodukten haben. Um daraus hochwertige Produkte zu machen, ist genau das erforderlich, was bereits beschrieben wurde: Dokumentation und Aufklärung der gefundenen Defizite. Je gründlicher das erfolgt, desto kostengünstiger und effektiver kann an der weiteren Verbesserung gearbeitet werden. Für das Durchführen dieser Untersuchungen existieren bewährte Methoden, wie die Root Cause Analysis (RCA). Diese sind in der IT indes kaum bekannt und werden daher selten verwendet. Neben Einsichten über das konkrete Produkt oder Projektresultat erhält man mit Sicherheit wertvolle und verallgemeinerbare Hinweise.

Ich bin nicht 10 000 Mal gescheitert. Ich habe erfolgreich 10 000 Wege gefunden, die nicht funktionieren. – Thomas Alva Edison

Wissen vermehrt sich durch Teilen

Wirklich sinnvoll ist die Fehleranalyse nur, wenn ihre Ergebnisse von möglichst vielen an der Softwareentwicklung beteiligten rezipiert werden. In anderen Bereichen ist es gängige Praxis, dass Unfallauswertungen in einschlägigen Zeitschriften veröffentlicht werden. Die Auswahl erfolgt dabei vorrangig nach dem vermuteten Erkenntniswert. Das ist ein gutes Vorbild. Natürlich besteht dabei immer die Gefahr, dass einzelne Eigenschaften gewisser Produkte negativ erwähnt werden. Die Hersteller sollten das nicht als Bedrohung, sondern als Chance sehen. Denn sie erhalten wertvolle Hinweise für die Weiterentwicklung ihres Produkts. Noch viel wichtiger ist jedoch die Möglichkeit, potenziellen Nutzern von Anfang an Hinweise geben zu können, wie sie bestimmte Probleme vermeiden können. So ist es immer ärgerlich, wenn sich erst bei den Tests Probleme herausstellen, die konzeptionelle Modifikationen erfordern. Eine etablierte Fehlerkultur sollte dazu führen, dass derartige Fallen und wie diese zu vermeiden sind, offensiv dokumentiert werden. Damit wäre allen geholfen.

In rudimentärer oder versteckter Form gibt es solche Fehlerberichte bereits. Userforen, FAQs und Listen bekannter Probleme enthalten einen Teil des Rohmaterials. Warum also nicht den nächsten Schritt gehen und konsequent zu Fehlern stehen? Wenn Open-Source-Projekte mutig vorangehen, werden sich dem auf Dauer auch die kommerziellen Anbieter nicht verschließen können. Für Konsumentenprodukte sind unabhängige Vergleichstests längst akzeptiert. Für komplexe Software ist das so sicher nicht möglich. Aber Berichte, die Grenzen und Mängel aufzeigen, leisten ebenfalls einen Beitrag zu erhöhter Transparenz.

Ohne Zweifel ist alles bisher gesagte nicht viel mehr als eine Wunschliste. Aber Träumen und Wünschen ist nicht verboten, denn sie können helfen, Entwicklungen anzustoßen. Vielleicht findet sich jemand, der daraus einen Hype generiert. Derzeit sieht es nicht danach aus, und deshalb folgen nun einige Vorschläge, wie man in kleinen Schritten trotzdem vorwärts kommen kann.

Erfahrung nennt man die Summe aller unserer Irrtümer. – Thomas Alva Edison

Werben und überzeugen

Die Idee, dass Fehler eine ergiebige Quelle neuer Erkenntnisse sein können, muss verbreitet werden. Bei etwas Nachdenken wird dem niemand ernsthaft widersprechen wollen. Doch von der Akzeptanz einer Wahrheit bis zur Umsetzung daraus folgender Erkenntnisse ist es ein weiter Weg. Deshalb muss immer wieder für diese Idee geworben werden: Steter Tropfen höhlt den Stein.

Die Analyse wird nur so weit erfolgreich sein können, wie alle Beteiligten von der Sinnhaftigkeit überzeugt sind und ihre Kenntnisse und Erfahrungen einbringen. Ein tief liegendes psychologisches Muster lässt uns Fehler lieber verdrängen als lange darüber nachzugrübeln. Dieses an sich sinnvolle Muster muss überwunden werden. Dazu bietet sich ein auf Peter Naur zurückgehendes Konzept an, das Software u. a. als formalisierte Theorien über bestimmte Aspekte der Realität interpretiert. So gesehen ist jedes Programm ein Experiment zur Prüfung einer Hypothese über diese Realität. Die experimentelle Falsifikation von Hypothesen ist in der Wissenschaft ein anerkanntes Mittel. Wenn man sich eingesteht, dass die Komplexität der Aufgaben einfach so hoch ist, dass Experimente sich nicht vermeiden lassen, verlieren hoffentlich auch die negativen Ergebnisse, die pauschal Fehler genannt werden, den abschreckenden Charakter.

Fehler auswerten

Eine brauchbare Grundlage für die angesprochene Analyse wird fast überall schon verwendet: das Bugtracking. Gewissenhaft durchgeführt, lässt sich damit schon sehr viel erreichen. Voraussetzung ist allerdings, dass alle Beteiligten im Sinne des Aus-Fehlern-Lernens daran mitwirken. Der erste Schritt besteht darin, die Klassifizierung von entdeckten Fehlern zu verfeinern, indem nicht nur die Schwere der Auswirkung und der Aufwand zur Behebung erfasst werden, sondern auch die Schwere oder Quelle der Ursache, beispielsweise konzeptionelle Defizite.

Im Rahmen der Testauswertung lassen sich dann möglicherweise nicht nur bestimmte Codeteile als Schwerpunkte identifizieren, sondern vielleicht auch Schwachstellen in der Aufgabenbeschreibung. Technisch lässt sich das relativ einfach realisieren: Entweder durch entsprechende Konfiguration der Trackingsysteme oder feste Stichwörter im Ticket. Unabhängig vom gewählten Weg sind so nützliche Einsichten zu erwarten.

Lessons Learned diskutieren

Ein anderer Ansatz, der ebenfalls in die gewünschte Richtung weist, ist die Auswertung von Projekt- oder Sprinterfahrungen unter dem Motto Lessons Learned. Wenn die Fehlererfassung bereits wie oben vorgeschlagen erfolgt ist, bietet eine globale Zusammenfassung, nach Möglichkeit ergänzt um erste Vermutungen über bisher verborgene Fehlerquellen, eine ausgezeichnete Grundlage für die Diskussion und Anhaltspunkte für weitergehende Analysen.

Nichts unbeachtet lassen

Nachdem sich ein Bewusstsein für Fehlerquellenerforschung etabliert hat, kann ohne großen Aufwand ein „Backlog für Risiken“ installiert werden. Jeder Entwickler kennt die Situation, dass im Laufe des Projekts kleinere Dinge auftauchen, die nicht schön sind, ohne jedoch eine unmittelbare Aktion zu erfordern. Manchmal mag das ein irritierender Begriff sein, ein anderes Mal die unterschiedliche Reihenfolge von gleichen Parametern bei ähnlichen Methoden. In der Praxis wird da bestenfalls kurz drüber geklagt, und das war es dann. Die Erfahrung lehrt, dass große Fehler häufig unscheinbare Ursachen haben. Besser wäre es daher, solche Dinge zu erfassen. Wobei es sicher einiger Übung bedarf, das richtige Maß zu finden, um nicht in Trivialitäten unterzugehen. Später kann dann versucht werden, diese Einträge mit zwischenzeitlich erkannten Fehlern zu korrelieren. Der Nutzen wäre gleich zweifach: Erstens lernen alle daraus, welche der als riskant eingeschätzten Punkte sich tatsächlich als Risiko erwiesen haben und worauf man also in Zukunft achten sollte. Und zweitens erhält die Projektleitung wichtige Hinweise, was bei einer Überarbeitung vorrangig zu berücksichtigen ist.

Wissenschaft in die Pflicht nehmen

Viele Unternehmen bieten Praktika und Graduierungsarbeiten an. Häufig werden in dieser Form Erkundungsthemen wie die konkrete Eignung neuer Technologien bearbeitet. Die nachträgliche Auswertung von Entwicklungsprojekten kann aber ebenfalls wichtige neue Erkenntnisse liefern. Wenn genügend derartige Themen aus der Praxis gestellt werden, wird hoffentlich auch die wissenschaftliche Forschung mehr Interesse zeigen.

An dieser Stelle sei angemerkt, dass es um qualitative Analysen geht, die sich heute noch nicht automatisieren lässt. Metriken, die offenbar ein beliebterer Gegenstand sind, können zwar als Indikatoren wichtige Hinweise und Ansatzpunkte liefern, aber die inhaltliche Beurteilung nicht ersetzen. Es lässt sich beispielsweise nicht automatisch entscheiden, ob die erhöhte Komplexität eines Codeteils auf die Ungeschicklichkeit des Programmierers, die umständliche Modellierung während der Aufgabenerfassung oder den tatsächlich komplizierten Sachverhalt zurückzuführen ist.

Wandel von unten beginnen

Kulturelle Wandel sind nicht leicht zu erreichen, insbesondere lassen sie sich nur sehr schwer von oben verordnen. Umso erfolgreicher haben sich so genannte Graswurzelbewegungen erwiesen, d. h., jeder, der von einer Idee überzeugt ist, beginnt lokal damit, sie zu verwirklichen. Warum sollte das für die IT-Fehlerkultur nicht auch möglich sein? Also sollte man, wann immer es möglich ist – und das ist trotz aller Terminzwänge gar nicht so selten – mit Kollegen darüber diskutieren, darüber schreiben oder vortragen. Immer unter dem Gesichtspunkt: Was kann man daraus lernen und wie kann man es in Zukunft besser machen?

Zusammenfassung

Nach Einschätzung der großen Consulting-Häuser werden jährlich Millionenbeträge durch gescheiterte IT-Projekte nutzlos verpulvert. Die Chancen, aus diesen Fehlschlägen zu lernen, werden bisher völlig ungenügend genutzt. Um das zu ändern, muss sich die Einstellung zu Fehlern und zum Scheitern stark ändern. Alle Erfahrung zeigt, dass der Weg zur Erkenntnis mit Fehlschlägen gepflastert ist. Man muss loskommen von dem Gedanken, dass man von Anfang an alles richtig machen kann. In komplexen Situationen ist die Versuch-und-Irrtum-Methode häufig unverzichtbar. Als fatal erweist es sich nur, wenn der Erkenntnisgewinn, der jedem Fehler innewohnt, aus Scham oder Ignoranz nicht genutzt wird. Dann entsteht aus Fehlern wirklich Schaden. Dabei sollte allen klar sein, dass Fehleranalyse nicht nebenbei erledigt werden kann. Sie verursacht zunächst Kosten. Der Gewinn zeigt sich erst allmählich. Die Beispiele aus anderen Technikbereichen belegen jedoch die großen langfristigen Vorteile für die Sicherheit und Zuverlässigkeit.

Lesen Sie auch: Von Bugs, Fehlern und Chancen: Wie Sie Bug-Tagebücher als Lerninstrument nutzen

Der erforderliche Wandel beim Umgang mit Fehlern wird auch in der IT nicht leicht zu erreichen sein. Aber jeder hat die Möglichkeit an seinem Platz, zunächst im Kleinen, darauf hinzuwirken. Offener Umgang mit Fehlern, wie er in der agilen Softwareentwicklung oder dem Design Thinking bereits gepflegt wird, muss ein erster Schritt sein.

Auf längere Sicht wird diese Entwicklung durch externe Einflüsse gefördert werden, weil Software immer stärker in lebenswichtige Bereiche wie Medizin oder autonome Fahrzeuge hineinwächst und damit die dort bereits etablierten Verfahren zur Ursachenforschung bei Zwischenfällen zwangsläufig auf die beteiligte IT ausgedehnt werden müssen.

Geschrieben von
Jürgen Lampe
Jürgen Lampe
  Jürgen Lampe ist IT-Berater bei der Agon Solutions GmbH in Frankfurt. Seit mehr als 15 Jahren befasst er sich mit Design und Implementierung von Java-Anwendungen im Bankenumfeld. An Fachsprachen (DSL) und Werkzeugen für deren Implementierung ist er seit seiner Studienzeit interessiert.
Kommentare
  1. Thomas Wenger2017-01-02 11:44:29

    Danke für die interessanten Überlegungen. Mir persönlich entspricht der Text ausgesprrochen gut.

    Treffende Aussagen. Spannende Ansätze.

    Der omnipräsente Fatalismus wird aber wohl bewirken, dass sich nicht so schnell was ändern wird. Leider.

  2. TestP2017-01-03 18:36:52

    Das Problem an der Sache ist: Die perfekte Software ist schnell, zuverlässig und günstig. Wähle zwei.

    Sprich, so eine Vorgehensweise wie sie in der Luftfahrt üblich ist würde die Kosten der Software so exorbitant in die Höhe treiben, dass sie niemand mehr bezahlen könnte. Ist auch kein Wunder, dass die Flugzeugbauer alle am Steuergeldtropf hängen und von reichlich Subventionen und Staatsaufträgen leben.

    Grüße

  3. Clemens Prill2017-01-03 18:50:26

    Danke für den spannenden Artikel! Ich würde mir mehr Artikel von Ihnen wünschen. Ihr Artikel ist fundiert, bringt interessante Eindrücke mit sich und ist ausreichend ausführlich beschrieben. Ihr Artikel gehört definitiv zu den besseren dieser Seite.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.