Senior Programmer händeringend gesucht – für 60 Jahre alte Programmiersprache
Die Datenverarbeitungssysteme vieler Institutionen des US-amerikanischen Staates basieren auf Cobol, einer Programmiersprache, die seit den 80er Jahren als Legacy-Language gilt. Die Coronakrise hat jetzt dazu geführt, dass die Nachfrage nach Cobol-fähigen Entwicklern innerhalb kürzester Zeit explodierte: Die Programmiersprache spielt eine Schlüsselrolle in den Datenverarbeitungssystemen des amerikanischen Arbeitsministeriums. Auch im Finanzsektor verwendete Technologien basieren heute noch zu weiten Teilen auf dem Programmiersprachen-Urgestein.
Eine aussterbende Art: Der Cobol-Entwickler
Cobol gibt es schon seit 60 Jahren. Die Abkürzung steht für Common Business Oriented Language – zum Einsatz kam und kommt die Technologie vor allem in Wirtschaft und Verwaltung: Die Systeme von Banken, Versicherungen und des US-amerikanischen Äquivalents zur Agentur für Arbeit sind offenbar zu weiten Teilen immer noch in Cobol geschrieben. Die Coronakrise rückte den Dinosaurier unter den Programmiersprachen unerwartet in den Fokus der Aufmerksamkeit: Vor allem in den USA mussten sich sehr viele Menschen in sehr kurzer Zeit arbeitslos melden. Ein Ansturm, dem das auf Cobol basierende, 40 Jahre alte Datenverarbeitungssystem des amerikanischen Arbeitsministeriums nicht standhielt: Über das erste Aprilwochenende rief etwa der Gouverneur von New Jersey Freiwillige mit Cobol-Kenntnissen zur Mithilfe bei der Aufrüstung auf. Das Problem dabei: Cobol-Programmierer sind selten. Unter den wenigen Entwicklern, die die Sprache noch beherrschen, befinden sich viele bereits im Ruhestand. Wer von ihnen noch berufstätig ist, arbeitet oft in der Finanzbranche.
Entwickelt zur Programmierung kaufmännischer Anwendungen
Entwickelt wurde Cobol in den 50er Jahren von einer vom amerikanischen Verteidigungsministerium für diesen Zweck gebildeten Arbeitsgruppe – interessanterweise zu einer Zeit, in der Programmieren noch als überwiegend weibliche Domäne galt. So war auch das Entwicklerteam um die Sprache herum zu gut 50 Prozent weiblich. Entworfen wurde Cobol als hardwareunabhängige Programmiersprache, die sich vor allem für die Programmierung kaufmännischer Anwendungen eignet. Nachdem mit dem Aufkommen von Fortran die Programmierung technischer Anwendungen maßgeblich einfacher wurde, sollte Cobol die Arbeit mit großen Datenmengen und deren Ein- und Ausgabe vereinfachen – bis dato wurden dafür meistens Assemblersprachen verwendet.
Cobol beherrscht die Finanzwelt
Cobol fand schnell den Weg in die zivile Nutzung und wurde eine der ersten kommerziell eingesetzten Programmiersprachen. Zum Einsatz kam sie vor allem in Banken, Verwaltungen und Behörden. IBM verkauft bis heute Cobol-kompatible Mainframes. Laut Reuters läuft etwa die Hälfte aller Finanzsysteme auf Cobol. Weltweit basieren etwa 80 Prozent aller kartenbasierten Transaktionen auf in Cobol geschriebenem Code. Nur: Warum gibt es dann so wenige Cobol-Entwickler? Und wie kommt es, dass die Systeme nicht mit der Zeit durch modernere Lösungen ersetzt wurden?
Noch vor der Floppy Disk
Das Fehlen der Sprache mächtiger Programmierer ist auf eine Reihe von Gründen zurückzuführen: Zum einen wird die Sprache seit den 80er Jahren nicht mehr an Hochschulen gelehrt. Zum anderen gab es in den 1980er und 1990er Jahren keine quelloffene Version der Programmiersprache. Andere, nativ mit dem Internet kompatible Sprachen waren einfach viel attraktiver. „Über eine Zeitspanne von 20 Jahren wurde Cobol für tot gehalten. Niemand lehrte es, niemand lernte es. Cobol kam auf, bevor es überhaupt die Floppy Disk gab, geschweige denn das Internet“, wird J. Ray Scott, einer der wenigen Professoren, der Cobol noch lehrt, in einem Artikel der Medium-Publikation Onezero zitiert.
Trägheit, Geiz und Kurzsichtigkeit
Die zynische Antwort auf diese Fragen lautet: Eine Kombination aus Trägheit und Kurzsichtigkeit führte dazu, dass es weder Entwickler, noch die Möglichkeit zur Modernisierung des Legacy Codes gibt. Unternehmen und Verwaltungen waren in der Vergangenheit ganz einfach zu inkompetent und zu geizig, um für die fortlaufende Wartung ihres Cobol-Codes ein ausreichendes Budget bereitzustellen. Für nachkommende Entwicklergenerationen gab es schlicht zu wenige Anreize, sich mit Cobol zu beschäftigen. Frei nach dem Motto: „Never change a running system“ sahen Entscheider offenbar zu lange keinen Grund, in die Überarbeitung der Legacy-Codebases zu investieren.
Angesichts der damit verbundenen Kosten ist das nachvollziehbar: Für die Modernisierung ihrer Banking-Plattform im Jahr 2012 bezahlte die Commonwealth Bank of Australia 750 Millionen US-Dollar. Andere Banken entschieden sich trotz des größer werdenden Personalengpasses dafür, bei ihren in Cobol programmierten Systemen zu bleiben.
Besser in Mathe als Java
Es gibt aber noch einen anderen Grund. So absurd es klingen mag: Cobol kann genauer rechnen als Java oder Python. In Cobol werden Berechnungen anders ausgeführt als in modernen Programmiersprachen. Das hat mit Speicherung von Dezimalzahlen zu tun. Ähnlich wie der gute alte Casio-Taschenrechner aus der Schulzeit greift Cobol dafür auf ein Fixed-Point-Design zurück, modernere Programmiersprachen speichern Dezimalzahlen mit sogenannten Floating Points. Eine Übersetzung von Cobol-Code in ein Java-Programm würde aufgrund dieses Designunterschieds unweigerlich zu Ungenauigkeiten bei Berechnungen führen. Eine Schwachstelle, die sich weder Banken noch Verwaltungen leisten könnten. Die fundamentalen Architekturunterschiede auszugleichen, ist zwar theoretisch möglich, bringt aber andere Schwierigkeiten mit sich.
Cobol wird vermutlich bleiben
Die Antwort auf die Frage, warum Cobol immer noch die Welt am Laufen hält, ist also nicht nur eine Geschichte von verpassten Updates und fehlendem Maintenance-Budget. Die Verhaltensweisen des Programmiersprachen-Dinos ließen sich schlicht kaum in einer moderneren Sprache auf einem modernen Betriebssystem abbilden. Möglich, dass Cobol auf einem Mainframe auch noch in 20 Jahren die performantere, genauere und günstigere Lösung für die Anforderungen der globalen Finanz- und Verwaltungsinfrastruktur sein wird. Vorausgesetzt, es gibt dann noch Entwickler, die sich um die Systeme kümmern können.
In 2 Wochen zum Cobol-Programmierer
Der einzige Lichtblick dabei: Cobol ist wohl relativ einfach zu lernen. Scott, der Cobol-unterrichtende Informatikdozent, hatte seine Entwicklerkarriere bei den Pittsburgher Stahlwerken gestartet. Die Rekrutierung neuer Programmierer aus der bestehenden Arbeiterschaft war damals eine übliche Praxis. Wer den Eignungstest bestand, wurde auf einen zweiwöchigen Lehrgang bei IBM geschickt und kam anschließend in der IT-Abteilung der Werke zum Einsatz. Heutzutage zeigt sich ein ganz ähnliches Bild: Um den plötzlich so dringenden Bedarf an Cobol-Programmierern zu decken, bietet IBM kostenfreie Onlinekurse zum Erlernen der Programmiersprache an. Auch Plattformen wie Udemy und Coursera haben das Angebot an MOOC zum Lernen der 60 Jahre alten Sprache vor Kurzem erweitert. Ob das reicht, um den Entwickler-Nachwuchs für die Programmiersprache zu begeistern, bleibt abzuwarten; ganz lukrativ wäre eine Karriere als Cobol-Entwicklerin aber bestimmt.
Hallo,
ich bin 50 Jahre alt und habe im Rahmen eines Wirtschaftsinformatik-Studiums in der Anfangszeit noch COBOL gelernt.
Wo könnte man sich denn hinwenden, wenn man Interesse an einer derartigen Aufgabe in den USA hat?
Das Argument mit der Rechenart ist absoluter Blödsinn. Letztendlich werden Berechnungen vom Prozessor und nicht von der Programmiersprache durchgeführt. Zumindest von Python weiß ich, dass sowohl mit dem Standard-Modul `decimal` als auch mit NumPy Fixed-Point-Berechnungen möglich sind.
Unternehmen, die jetzt wieder lieber in alte Programmierer statt in eine Modernisierung ihrer Systeme investieren, zeigen nur, dass sie unflexibel sind und nichts aus ihren Fehlern gelernt haben.
Die mittels EDV abzubildenden Geschäftsvorfälle der Finanzbranche sind extrem monoton und insgesamt trivial. Hauptprobleme sind die schiere Masse der Transaktionen sowie die fehlende Dokumentation der
endlosen COBOL-Strickwaren
Dass Cobol in 20 Jahren „noch“ (als wäre das heute so) die performantere, genauere und günstigere Lösung sein wird halte ich für Unsinn.
1. Mainframes, die heute noch im Einsatz sind, sind im Schnitt 17 Jahre alt – Mainframes von damals haben weniger Rechenleistung als ein Raspberry Pi 3 (keine Übertreibung!)
2. Zur Genauigkeit hat Sven Heinemann schon genug gesagt.
3. Viele Banken zahlen hunderte millionen Euro pro Jahr für ihre Mainframes (Betrieb, Wartung, etc.).
4. So wie sich der Job-Markt im Bereich Cobol entwickelt, wird es in ca 10 Jahren praktisch keine Cobol Entwickler mehr geben. Wer dann noch nicht migriert ist, wird schlicht kaputt gehen.
Auch die Behauptung, dass Cobol relativ einfach zu lernen wäre, möchte ich nicht unkommentiert lassen.
Man kann man JEDE Programmiersprache in 1 Tag soweit lernen, dass man damit kleine bis mittelgroße Programme SCHREIBEN kann. Dazu braucht man nur Variablen, Arithmetik, Vergleiche, Verzweigungen und While-Schleifen (Stichwort Turing-Vollständigkeit).
Aber damit ist man noch LANGE nicht so weit, dass man große Programme von ANDEREN Entwicklern verstehen kann – das gilt für jede Programmiersprache (die 26 Buchstaben des Alphabets zu kennen macht einen ja auch nicht zu einem virtuosen Buchautor).
Aber gerade bei COBOL ist das ein besonders großes Problem, weil COBOL über 500 Keywords hat. Und da man bei COBOL im Gegensatz zu anderen Sprachen manchmal mehrere Keywords hintereinander setzen muss und da man auch kein Syntax Highlighting hat (weil massive Fehler im Sprach-Design das nahezu unmöglich machen – COBOL ist nämlich nicht Kontextfrei) ist man dadurch ständig am rätseln, ob das Wort, das man gerade liest, ein Schlüsselwort oder ein Variablenname ist.
Von Gültigkeitsbereichen der Variablen und Exit-Conditions der PERFORM-THRU Aufrufe will ich gar nicht anfangen.
Und obendrein wird im Mainframe-Umfeld ein komplett anderes Vokabular verwendet als wir es heute verwenden. Beispielsweise spricht man auf dem Mainframe nicht von Festplatten, Dateisystemen und Dateien, sondern von DASDs, Katalogen und Datensätzen. Von daher kann man zwar gerne ein COBOL-Buch lesen, aber man wird es schlicht nicht verstehen.
COBOL war vielleicht damals leicht zu lernen IM VERGLEICH zu Assembler oder zu handgeschriebenem, Gerätespezifischem Bytecode (was damals die einzigen Alternativen waren) aber heute ist die Aussage m. E. völliger Unsinn.