312 Milliarden Dollar für die Suche nach Fehlern im Softwarecode Deloitte mit Tipps zum Abbau technischer Schulden

Autor / Redakteur: Ludger Schmitz / Ulrike Ostler

Nein, es geht nicht um ein Defizit im IT-Budget. „Technical Debts“, so der englische Ausdruck, umfasst die direkten und indirekten Kosten von Fehlern in der Architektur und bei der Programmierung von Software.

Firma zum Thema

Rund 200 Codereviews, 10.000 Kommentare menschlicher Tester und 25.000 Kommentare von Test-Tools brachten den Roboter „Curiosity“ beim zweiten Anlauf zum Mars. Hat Ihr Unternehmen eine solche Chance?
Rund 200 Codereviews, 10.000 Kommentare menschlicher Tester und 25.000 Kommentare von Test-Tools brachten den Roboter „Curiosity“ beim zweiten Anlauf zum Mars. Hat Ihr Unternehmen eine solche Chance?
(Bild: NASA)

Als die NASA in einer „flagship mission“ 2009 den Roboter „Curiosity“ zum Mars schicken wollte, baute sie zunächst auf ein Steuerungsprogramm, dessen Grundlagen in den 1990er Jahren entstanden waren. Es hatte dermaßen viele Bugs und rätselhaftes Testverhalten, dass die ganze Mission abgeblasen wurde, obwohl sich das nächste Zeitfenster für einen Start erst zwei Jahre später öffnen würde.

Es folgte ein irrsinnig aufwändiges Verfahren mit zweihundert Codereviews, 10.000 Kommentaren menschlicher Tester und 25.000 Kommentaren von Test-Tools. Das Ergebnis war ein völlig neues Programm mit 3,5 Millionen Codezeilen und 150 verschiedenen Modulen. Curiosity startete 2011 und übertrifft seit der Mars-Landung am 5. August 2012 sämtliche Erwartungen.

Das Beispiel findet sich in „Tech Trends 2014“, einer umfangreichen Aufsatzsammlung von Deloitte University Press, einer Abteilung von Deloitte Touche Tohmatsu, neben PwC, KPMG und Ernst & Young einer der „Big Four“ unter den Beratungs- und Finanzdienstleistungsleistern. Die Analyse enthält ein Kapitel zum Thema „Technical debt reversal“. Es geht die Kosten schlecht gemachter Software, die im IT-Budget unter „Softwarepflege“ und „Maintenance“ anfallen. Es geht um Altlasten der IT, ihren Preis und ihre Bewältigung. Dafür hat Ward Cunningham 1992 einen Begriff geprägt: „Technical Debt“, technische Schulden.

Fehler gibt es immer, immer

Die Entwicklung einer Software ist kein einmalig anfallender Budgetposten. Sie enthält immer Fehler, die bestenfalls bei Freigabe des Programms noch nicht entdeckt sind. Manchmal wird das erst Jahre später der Fall sein. Manchmal werden erst bei einer späteren Modernisierung oder Erweiterung um moderne Module nicht nur „Böcke“ in der Entwicklung, sondern gravierende Schwächen in der Architektur einer Software entdeckt.

Die Fehler waren keine böse Absicht, vielmehr waren wahrscheinlich die Anforderungen zu komplex oder der Projektzeitplan zu eng gesetzt oder wiederverwendeter proprietärer Code zu kompliziert oder Projektziele „dynamisch“ verändert worden oder... Aber all das hatte damals auch schon gute Gründe.

In vielen Fällen besteht anders als im Curiosity-Fall keine Chance, dies oder jenes alte Programm als „ferner liefen“ der hauseigenen IT-Geschichte zu übergeben. Die Software ist zu wichtig, zumindest scheint sie es zu sein – schließlich wurde mit ihr nicht nur lange gearbeitet.

Rauswurf oder Lebensrettung?

Vielmehr sind an ihr über die Jahre immer wieder Fehler behoben und für sie sogar Erweiterungen geschrieben worden. Ob ein Programm nun gefühlt oder wirklich so notwendig ist, lässt sich mit guten Verfahren durchaus feststellen, so die Deloitte-Studie: Der Military Health Service der US-Streitkräfte identifizierte so dutzende obsolete IT-Systeme und sparte sich durch deren Rauswurf 50 Millionen Dollar laufender Betriebskosten.

Wie in diesem Fall tritt das Ende eines Software-Lebenszyklus häufig erst ein, wenn die Umstände zu radikalen Maßnahmen Anlass geben. Die Regel sind Bug-Fixes, Workarounds und die Ankündigung, dass demnächst ohnehin alles auf den Prüfstand kommt und besser wird.

Das geht so lange weiter, bis die mangelhafte Stabilität des Systems zur Belastung für das eigentliche Business eines Unternehmens wird. Eine Belastung für die IT sind solche Anwendungen ohnehin, denn sie gehen auf deren Budget und Arbeitszeitkonten. Sie blockieren ferner Investitionen in moderne Anwendungen für neue Business-Anforderungen.

Deutliche Zahlen

Deloitte hat ein paar Zahlen aus anderen, meist universitären Studien herangezogen. Demnach kostet jede Zeile Code im Durchschnitt 3,61 Dollar extra auf dem Kontoposten Technical Debts. Für Software-Debugging wurden 2012 weltweit 312 Milliarden Dollar ausgegeben. Die üblicherweise angewendeten Testverfahren erkennen gerade einmal ein Drittel der Fehler. Die Behebung von Architekturfehlern kostet 53 Prozent der Ausgaben, obwohl sie nur 8 Prozent der Defekte ausmachen.

Das Dokument „Deloitte Tech Trends 2014 Report“ ist voll von relevanten Statistiken, Best Practices und Fallstudien.
Das Dokument „Deloitte Tech Trends 2014 Report“ ist voll von relevanten Statistiken, Best Practices und Fallstudien.
(Bild: Detoitte University Press)

Das Marktforschungsunternehmen Gartner schätzt den globalen IT-Altlastenberg auf gegenwärtig 500 Milliarden Dollar. Es soll 2015 schon eine Million Dollar betragen. Die übertrieben erscheinende Zahl begründen die Analysten damit, dass beim derzeitigen IT-Umbruch neuartige Technologien implementiert werden, die eng mit alten Systemen verknüpft werden. Dabei werde sich deren Fehlerhaftigkeit in einem ungeahnten Ausmaß offenbaren. Die IT-Schulden wachsen.

Daraus leitet Deloitte nicht nur die Aufforderung ab, diesen Schuldenberg schnellsten abzutragen, vielmehr proklamieren die Finanzspezialisten das gleich zum Trend. Denn den Unternehmen, gerade denen mit einem weiten Einsatz von Altsystemen, würden deren Lasten über den Kopf wachsen, gar ihre Operationsfähigkeit, zumindest aber ihre Profitabilität in Frage stellen.

Deliotte spricht sechs Ratschläge aus:

  • 1. Analysieren Sie Ihre technische Schulden, also die Bedeutung aller Systeme und deren Bedarf an Überarbeitung.
  • 2. Überlegen Sie, wie tief neue Anwendungen in Altsysteme integriert werden und ob diese die künftige Umgebung stabil unterstützen werden.
  • 3. Ist das IT-Personal überhaupt noch in der Lage, die alten Systeme kosteneffizient zu pflegen und zu modernisieren?
  • 4. Belohnen Sie Entwickler für gute Codequalität und rigoroses Testing. Lieber weniger sehr gute Entwickler und mehr Tester.
  • 5. Versuchen Sie insbesondere für das Testing, dessen Umfeld sehr breit anzulegen, nämlich auf die Anwender. Die Open-Source-Community ist das Musterbeispiel, wie das Vielaugen-Prinzip die Softwarequalität anhebt.
  • 6. Kalkulieren Sie, welche Schulden – die sind ja nicht grundsätzlich schlecht – akzeptabel und welche vermeidbar sind. Zumindest sollte transparent sein, was wofür aufgewendet wird.

* Ludger Schmitz ist freiberuflicher Journalist in Kelheim.

(ID:42956597)