OK, zurück zum eigentlichen Thema:
Auf Jobangebote, in denen Delphi erwähnt wird, bekommen wir seit Jahren schon keine Bewerbungen von jüngeren Leuten mehr. Woran das genau liegt, kann ich nicht sagen.
Ob die Leute mit Delphi gar nichts anfangen können oder ob sie damit nichts zu tun haben wollen?
Vielleicht liegt es auch an sonstigen Bedingungen, denn wer kennt schon unsere kleine Firma (Auch wenn wir Marktführer in Deutschland sind)? Oder auch andersrum: Bis vor kurzem gehörten wir (auch dem Namen nach) zu einem großen, bekannten Konzern, der eher ein schlafmütziges Behördenimage hat. Oder vielleicht hört sich Straßenzustandserfassung zu langweilig an? Oder nach viel in der Gegend rumfahren (was auch bei uns Softwarentwickler eher nicht machen, dafür gibt es Meßfahrer)?
Man kann nicht vorhandene Bewerber ja nicht danach fragen, warum sie sich nicht bewerben.
Eigentlich bräuchten wir dringend einen weiteren jüngeren Kollegen (oder gerne auch eine Kollegin), der/die hier langsam übernimmt, bevor wir alten Säcke in Rente gehen. (Und komme mir jetzt keiner mit "Altersdiskriminierung". Es geht ja gerade darum, dass nicht alle Leute gleichzeitig in Rente gehen und der Laden dann plötzlich ohne Softwareentwickler da steht. Da hilft es nicht wirklich, noch einen weiteren "alten Sack" einzustellen, der dann zur gleichen Zeit ebenfalls wegfällt.)
Aber mal angenommen, es läge an der Verwendung von Delphi:
Was sollte man denn dann tun? Umstellen auf eine "hippere" Entwicklungsumgebung? Am besten noch mit Microservices, Cloud und KI (oder was gerade die aktuelle Sau ist, die durchs Dorf getrieben wird)? Dafür dann einige Millionen Zeilen Sourcecode wegwerfen und das
Rad neu erfinden?
Mal ganz abgesehen davon, dass es in unserem speziellen Fall (auch) um Software geht, die auf Messfahrzugen durch die Gegend gefahren wird. Da hat es sich dann was mit Cloud oder stromfressenden Rechnern für KI. Auch Java oder irgendwelche Scriptsprachen sind für solche Pseudo-Echtzeit Anwendungen nicht geeignet. Das Performanceproblem mit Hardware zu erschlagen geht bei der begrenzten Stromversorgung in einem Messfahrzeug auch nicht: Ab dem 4. Rechner saugt man dann die Pufferbatterie leer und braucht einen zusätzlichen Stromgenerator.
OK, in dem Bereich könnte man auf C/C++ umstellen, aber wie schon geschrieben: Man müsste Millionen Zeilen von Sourcecode neu schreiben. Und nach meinen Erfahrungen (in anderen Firmen), braucht man 2-3 C/C++-Entwickler um die Produktivität eines Delphi-Entwicklers zu erreichen. Aber das mag ein falscher Eindruck sein, vielleicht war das auch eher 2-3 mittelmäßige C/C++ Entwickler, um einen exzellenten Delphi-Entwickler zu ersetzen
Im (Back-)Office-Bereich (Aufbereitung/Auswertung der Daten), könnte man auf irgendwas anders umstellen. Dann müsste man aber zumindest die Zugriffsroutinen für die Datendateien immer doppelt schreiben: Einmal in Delphi zur Verwendung auf den Fahrzeugen, und dann nochmal in einer anderen Programmiersprache zur Verwendung im Büro. Doppelter Code -> Doppelte Fehlerquellen. Ich hatte mal dazu angesetzt, alles in Datenbanken statt in binären Dateien zu speichern, aber die Datenmenge und Performance hat mir da schnell einen Strich durch die Rechnung gemacht. Faktor 10 bis 100 langsamer beim Datenzugriff ist einfach nicht zumutbar. (Noch schlimmer wurde es, als die Auftraggeber dann ein
XML-Format eingeführt haben, Die Dateien sind dann 100-mal so groß und der Zugriff mindestens 10 mal langsamer.)
/rant
Ich sehe einfach keine Lösung, die irgendwie umsetzbar und bezahlbar wäre. Wenn Delphi irgendwann den Bach runter geht, gibt es immerhin noch Lazarus, auf das man dann allmählich umstellen könnte, während man weiter mit alten Delphi-Versionen arbeitet.
Ist das jetzt "Technical Debt"?