• IT-Karriere:
  • Services:

IT in Unternehmen: Wie sich Softwareverrottung verhindern lässt

Programme können lange vor sich hin laufen, ohne dass sich jemand für sie interessieren muss. Wird Codepflege aber systematisch vernachlässigt, kann es zu Abstürzen kommen, die niemand mehr beheben kann.

Artikel von Rajiv Prabhakar veröffentlicht am
Computer Rot hängt nicht direkt mit Software Rot zusammen; aber beides ist schlecht.
Computer Rot hängt nicht direkt mit Software Rot zusammen; aber beides ist schlecht. (Bild: Issouf Sanogo/AFP via Getty Images)

Dieser Artikel ist eine Übersetzung. Das Original des Softwareentwicklers und Bloggers Rajiv Prabhakar ist hier zu finden. Es wurde am 25. April 2020 veröffentlicht.

Inhalt:
  1. IT in Unternehmen: Wie sich Softwareverrottung verhindern lässt
  2. Es gibt Wege, katastrophale Programmausfälle zu vermeiden

Vor kurzem bin ich bei Twitter auf einige Tweets gestoßen, die eine Geschichte erzählten, die ebenso amüsant wie schockierend ist:

"Einer meiner Kunden ist für mehrere der 100 größten Pensionsfonds der Welt verantwortlich. Er hatte einen nächtlichen Batch-Job laufen, der abstürzte. Zuerst wusste niemand, was los war. Dieser Batch-Job war noch nie abgestürzt, zumindest nicht, soweit sich jemand erinnern konnte oder Logs dafür hatte.

Die Person, die das Programm geschrieben hatte, war vor 15 Jahren oder mehr verstorben und seit Jahrzehnten nicht mehr in der Firma beschäftigt gewesen. Das Programm war nicht sehr groß, aber ziemlich undurchdringlich - und es war in einem Stil geschrieben, der die Effizienz der Berechnung der Lesbarkeit für Menschen vorzog. Und natürlich gab es keine Tests.

Stellenmarkt
  1. Börse Stuttgart GmbH, Stuttgart
  2. WBS GRUPPE, Berlin (Home-Office)

Wie der Zufall es wollte, war am Vortag eine Änderung in der Orchestrierung der Skripte gepusht worden, die in dieser Umgebung liefen. Man vermutete, dass das die Ursache war. Die Entwickler setzten alles auf die vorherige Version zurück. Leider wurde es dadurch schlimmer.

(...)

Ein anderes Programm, der Leistungsverteiler, sollte eine Warnung ausgeben, wenn die Beiträge für die aktuellen Projektionen nicht ausreichten. Da es keine Ausgabe des ersten Programms gab (es war ja abgestürzt), nahm es folgenden Fall an: "Alle Beiträge sind 0". Das sollte natürlich nicht so sein. Aber niemand wusste, dass sich dieses Programm so verhielt, denn das erste Programm war ja noch nie abgestürzt.

(...)

Ich bekam eine überraschende Nachricht vom CIO. 'Tut mir leid, dass ich dich störe, wir haben ein großes Problem. s1X. Könntest du heute Nachmittag herfliegen?' S1X bedeutet: 'schlimmer als Schweregrad 1, weil das Problem Auswirkungen auf andere, unabhängige Teile des Geschäfts hat'."

Glücklicherweise sind die Pensionsfonds sicher und die Geschichte ging gut aus. Aber: Es ist beunruhigend, dass so etwas Essenzielles wie unsere Finanzsysteme mit veralteter Software arbeiten, die buchstäblich niemand versteht.

(Noch eine Geschichte mit einem weniger glücklichen Ende: 16.000 Coronavirus-Fälle wurden in England nicht gemeldet, weil eine Behörde ein überholtes, 30 Jahre altes Dateiformat verwendet hatte.)

Geschäftsmodelle für erodierende Systeme

Das oben genannte Beispiel ist kein Einzelfall. Als ich 2012 Intel verließ, um zu Sun zu wechseln, wurde mir klar, wie schlecht es um deren Sparc-Produktlinie bestellt war. Einst die goldene Gans der Dot-Com-Server-Ära, war sie unglaublich weit hinter Intels Xeon-Produktlinie zurückgefallen.

Tatsächlich wurde mir von meinem eigenen Vorgesetzten gesagt, ich solle unsere Simulationen auf den Xeon-Servern laufen lassen - und nicht auf der Sparc-Serverfarm, denn diese sei "sehr langsam". Schlimmer noch: Intels CPUs waren nicht nur leistungsfähiger, sondern durch die Produktionsvorteile auch deutlich billiger in der Herstellung.

Die nächste naheliegende Frage, die ich hatte: Warum in aller Welt kauften die Leute überhaupt unsere Sparc-Chips, wenn sie so weit hinter der Konkurrenz lagen? Die Antwort, die ich von einem Senior-Architekten erhielt, machte mich sprachlos: Unsere Kunden hätten Softwaresysteme, die so veraltet seien, dass sie nur noch auf Sparc/Solaris-Systemen betrieben werden könnten.

Handbuch für Softwareentwickler: Das Standardwerk für professionelles Software Engineering

Eine Migration auf x86/Linux wäre für sie nicht zu bewältigen gewesen. In vielen Fällen war sogar der Quellcode verloren gegangen, was verhinderte, dass sie ihre Anwendungen überhaupt neu hätten kompilieren können. Das Beste, was sie tun konnten, war ein Upgrade auf die neueste Generation der gleichen Sparc-Prozessoren - egal, wie langsam oder teuer sie waren.

Es ist wirklich so: Das Geschäftsmodell unserer gesamten Abteilung drehte sich um die erodierenden Softwaresysteme der US-amerikanischen Unternehmen.

Die Kosten, den Betrieb am Laufen zu halten

Als ich bei Amazon anfing, arbeitete ich mit dem Archetyp eines Legacy-Systems. Es enthielt riesige Mengen technischer Schulden und war von einem anderen Team entwickelt worden, das sich längst aufgelöst hatte. Die Verantwortung für das Projekt wurde auf unser Team übertragen - und es erwies sich als so unbeliebt, dass die Entwickler in Scharen abwanderten. Von den rund zehn Teammitgliedern, die es gab, als ich kam, war ein Jahr später kein einziges mehr da.

Oberflächlich betrachtet hatte das System viele Vorteile. Es war in einer modernen Sprache und einem modernen Tech-Stack (Java 8) geschrieben. Ein ganzes Team von Entwicklern mit sechsstelligen Einkommen war täglich daran zugange. Es wurde ständig aktualisiert, um Bugs zu beheben und/oder neue Funktionen hinzuzufügen.

Trotzdem war es offensichtlich, dass die Fluktuation das System niederdrückte. Infolge des Verantwortungs- und Teamwechsels ging eine enorme Menge an institutionellem Wissen verloren. Wissen um das allgemeine Code-Design, um die End-to-End-Funktionalität, um Best Practices und Debugging-Techniken. Wir arbeiteten hart, um es am Laufen zu halten. Und doch hatten wir das Gefühl, in einem Sumpf zu versinken, ständig jede Änderung in Frage stellen zu müssen und von allen Seiten von einer Art Kriegsnebel umgeben zu sein.

Können Sie sich vorstellen, wie viel schlimmer alles noch hätte sein können, wäre das Projekt auf Java 1 gelaufen - mit gar keiner aktiven Entwicklung und ohne Entwickler, die sich gekümmert hätten?

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed
Es gibt Wege, katastrophale Programmausfälle zu vermeiden 
  1. 1
  2. 2
  3.  


Anzeige
Top-Angebote
  1. (u. a. LG OLED55CX9LA 55 Zoll OLED 120Hz VRR für 1.299€, Samsung GU82TU8079 82 Zoll LED für 1...
  2. 77€ (Bestpreis)
  3. (u. a. WD MyPassport externe HDD 5TB für 99€, Sony KD-55XH9077 55Zoll LED für 799€ (inkl...
  4. (u. a. Lords of the Fallen Game of the Year Edition für 2,50€, Toybox Turbos für 3,33€, Heavy...

xUser 23. Mär 2021 / Themenstart

Schau mal in die anderen Threads. Viele Entwickler scheinen das mit den sich...

Typhoonx 20. Mär 2021 / Themenstart

Man kann ehrlich gesagt mit guter Planung auch die Komplexität aus Prozessen abbauen und...

Typhoonx 20. Mär 2021 / Themenstart

Das sehe ich so ähnlich das es kein "best practise" gibt. Aber gerade beim Strukturieren...

Marwonline 19. Mär 2021 / Themenstart

Einige Teile aus dem Beitrag sind 1:1 identisch mit dem Vortrag, der auf den CLT2021 von...

Elkarlo 19. Mär 2021 / Themenstart

Ich kann das nur bestätigen: 2014 habe ich auf ein Routing ein Mini-Script geschrieben...

Kommentieren


Folgen Sie uns
       


Mafia (2002) - Golem retro_

Wer in der Mafia hoch hinaus will, muss loyal sein - ansonsten verstößt ihn die Familie. In Golem retro_ haben wir das erneut selbst erlebt.

Mafia (2002) - Golem retro_ Video aufrufen
Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme

      •  /