Sind wir veraltet?

[Papaschlumpf73]

Hier, ich melde mich. Ich glaube, dass ich tatsächlich zu alt bin. Ich verstehe nicht einmal, welches Problem Microsoft mit Windows 365 lösen will. Man kann sich doch bei jedem 0-8-15-Hoster ein kleines Windows-System mieten und per RDP drauf zugreifen...

[Bemi]

ich glaube, ich gehe in Frühpension... mir langt die cloudbasierte Arbeit im Büro schon lange, und bald auch zu Hause?

https://www.computerbase.de/2023-06/...cloud-bringen/

[Papaschlumpf73]

Und im ICE sehen wir bald wieder viele Menschen beim Bücher lesen. Zum Glück kommt Apple nicht auf solche großartigen Ideen.

[MyRealName]

Zitat von Bemi:

ich glaube, ich gehe in Frühpension... mir langt die cloudbasierte Arbeit im Büro schon lange, und bald auch zu Hause?

https://www.computerbase.de/2023-06/...cloud-bringen/

Ich glaube nicht, dass es alle Heimrechner ersetzen soll. Ich denke da an Grafikkarten, teils sogar noch Soundkarten etc. Cloudgaming hat nicht die Latenz die man lokal hat und bei manchen Spielen ist diese so wichtig, dass man sich sogar einen schnelleren Monitor kauft :p (ich nicht)

[freimatz]

Hat noch jemand Lust über das eigentliche Thema zu diskutieren? ("Wie sind eure Erfahrungen mit dem Thema? Sind wir veraltet und unsere Anwendungen gehören schleunigst abgelöst? Wie schaut es bei euch mit dem Recruiting aus? Fühlt ihr euch auch schon so richtig oldschool?") Sonst klinke ich mich aus.

[dummzeuch]

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"?

[freimatz]

Danke.
Sehe auch keine brauchbare Lösung. Immerhin ist bei uns 10 der Altersdurchschnitt nicht ganz so hoch. Haben doch zwei die noch kaum über 30 sind.
Was ist denn Technical Dept? Technische Schuld.
Ich denke wenn man auf ein System setzt das nicht langfristig benutzbar ist, dann ist das auch technische Schuld. Zu Ende gedacht bleibt dann aber nur noch C++ übrig. Das ist nach meiner Einschätzung die einzigste Sprache die es auch noch in 50 Jahren geben wird.

Ich selber habe noch ca. 10 Jahre. Ich werde das noch irgendwie überleben. Gerade baue ich auch wieder was in der UI um, wo Code drin ist Warum hat man kein Viewmodel gemacht. Schlimmer finde ich dass fast niemand in der Firma sich da Gedanken macht. Ab und zu mal ein Gejammer, aber eher der Sorte man müsste mal.

Noch was zu Bewerber: ich habe dem Chef gesagt er braucht keinen mehr Suchen. Selbst wenn er einen findet - wenn der bei einem Probetag sieht wie schlecht das Delphi (bei uns) funktioniert - kommt der sicher nicht. Es sei denn man belügt ihn.

[Phoenix]

Zitat von dummzeuch:

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.

Weder an Berufsschulen noch an FH's oder Universitäten wird Delphi gelehrt.
Es kommen einfach keine mehr nach.

Einstiegshürde? Wahnsinnig hoch. Community Edition schön und gut, aber man braucht ne Windows Kiste dafür. Viele haben Macs. Die ganz jungen Coden inzwischen mit ihren iPads im Browser auf Github Codespaces. Nix mehr mit lokaler Installation einer IDE.

Dazu kommt, das moderne Sprachen mit modernen Frameworks drunter einfach zigmal produktiver sind als man mit Delphi noch irgendwie sein könnte.

Das mag einem alteingesessenen Delphianer jetzt zwar komisch vorkommen (Wieso? Das ist super-produktiv was wir machen!), aber wenn ich mir anschaue war wir hier bei TT mit modernen Technologien machen und in wie wenig Zeit wir hier komplette Anwendungen von vorne bis hinten hinstellen, die wirklich alle Anforderungen an moderne Businessanwendungen erfüllen (läuft sowohl im Frontend als auch im Backend auf allen Plattformen inkl. nem Raspberry wenns not tut, ist offline-fähig, synchronisiert wenn es wieder online ist, hat Mehrmandantenfähigkeit, kann sowohl on-premises als auch in der Cloud oder sogar gemischt betrieben werden, entspricht dem aktuellen Stand was Sicherheit angeht), und ich mir dann überlege was das für ein Wahnsinnsgefrickel mit Delphi wäre, na dann gute Nacht.

Zitat von dummzeuch:

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

C/C++ ist schon gestorben. Du brauchst einen halben einigermaßen fitten Rust-Entwickler dafür.
Rust, mit seinem im Compiler-eingebauten Memory-Management sorgt nämlich dafür dass Du ganz sicher alles wieder deallokierst was Du Dir an Speicher holst und Du ganz sicher nicht auf einen falschen Speicherbereich zugreifst. Du schreibst den Code genau so schnell wie ein C/C++'ler aber du sparst Dir 85% der Zeit, die die dann hinterher am debuggen sind.

Es gibt viele Gründe warum z.B. bei Microsoft inzwischen viele Teile des Kernels in Rust neu geschrieben werden. Einer davon ist, das es kaum noch C/C++ am Markt gibt und Rust einfach inhärent sicherer ist.

Zitat von dummzeuch:

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?

Ja. Auch wenn sich das Krass anhört.

Die Alternative ist: Du findest keine Entwickler mehr. Die alten gehen weg. Es werden immer weniger. Man findet vielleicht ab und zu mal einen einzelnen neuen Entwickler, die sind aber auch alt und wissen was sie wert sind und rufen das auch ab. Die Entwicklung wird teurer, aber dadurch das es dennoch weniger werden gleichzeitig auch immer langsamer bis nahezu zum Stillstand. Das Produkt wird ohne sinnvolle Pflege da stehen. Kunden werden Bugfixes verlangen die nicht mehr (rechtzeitig) kommen. Werden unzufrieden, gehen zur Konkurrenz. Werden aber vorher ggf. sogar rechtlich gegen die Firma vorgehen weil sie einen Anspruch auf korrekte Software haben der nicht erfüllt wird (werden kann) - am Ende geht die Firma den Bach runter.
Das ist nicht nur theoretisch. Das habe ich schon mehrfach gesehen.

Die Lösung? Neu bauen. Das geht freilich nicht komplett. Man sucht neue Devs die sich mit modernen Technologien auskennen. Man baut neue Features in der neuen Technologie (und ja, das wird web-basiert sein). Die Anwender von morgen bedienen heute auch nur noch Tablets und Webapps. Die werden das auch später auf der Arbeit so erwarten. Und zurecht. Man kann dann diese neuen Features mittels eingebetteter Webview auch in der legacy-Software noch verwenden und diese so noch etwas am Leben erhalten. Stück für Stück nimmt man alte Features / Module und modernisiert diese (ja, auch wieder in die alte Software einbauen, die wird damit auch moderner), bis die neue Anwendung alle notwendigen Features hat um standalone eingesetzt zu werden.

So kann man noch einen fließenden Übergang hin bekommen, bevor es zu spät ist. Je früher man das erkennt und angeht, desto größer ist der Vorteil gegenüber Mitbewerbern. Wer das verpasst wird überholt und bleibt auf der Strecke.

[dummzeuch]

Zitat von Phoenix:

(und ja, das wird web-basiert sein).

Ich bezweifle irgendwie, dass man die Datenaufnahme von auf einem Messfahrzeug installierten Sensoren verchiedenster Art irgendwie web-basiert hinbekommen kann.

Und die Kunden werden sich nicht über fehlende Software-Updates beschweren, denn die bekommen von uns mit ganz wenigen Ausnahmen nur Daten, keine Software.

Aber OK, Rust könnte statt C++/C eingesetzt werden.

(Da ich der älteste der Softwareentwickler bei uns bin, bin ich der erste, der in Rente geht. D.h. von dem ganzen Mist, der danach kommt, kriege ich nichts mehr mit. Wer weiß, ob es bis dahin überhaupt noch Straßenzustandserfassung gibt. Vielleicht machen das dann die Sensoren in den Fahrzeugen nebenbei (und per Cloud), Entwicklungen in der Richtung gibt es schon.)

[Codehunter]

Zitat von freimatz:

Hat noch jemand Lust über das eigentliche Thema zu diskutieren? ("Wie sind eure Erfahrungen mit dem Thema? Sind wir veraltet und unsere Anwendungen gehören schleunigst abgelöst? Wie schaut es bei euch mit dem Recruiting aus? Fühlt ihr euch auch schon so richtig oldschool?") Sonst klinke ich mich aus.

Die Diskussion vorher drehte sich ja v.a. darum was es bräuchte, damit Delphi nicht mehr so "uncool" ist. Und da hat IMHO Emba mit seinen Entscheidungen kräftig Anteil dran.

Zitat von dummzeuch:

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)?

Anglifizierung soll ja manchmal helfen. "Road Condition Exploration (Engineer, Achitect)" vielleicht?

Eine spannende Frage könnte auch sein: Braucht es unbedingt Studierte? Reicht vielleicht auch ein interessierter Quereinsteiger? Oder man gibt mal Leuten eine Chance die sonst nie eine bekommen -> junge Teilzeitmütter, Menschen mit Behinderung, Ausländer... Grad aus der Ukraine ist nicht unwahrscheinlich, sogar alles dreies in Personalunion zu finden, die sogar gut Delphi können. Immerhin war Borland historisch in Osteuropa immer stark vertreten.

Zitat von freimatz:

Noch was zu Bewerber: ich habe dem Chef gesagt er braucht keinen mehr Suchen. Selbst wenn er einen findet - wenn der bei einem Probetag sieht wie schlecht das Delphi (bei uns) funktioniert - kommt der sicher nicht. Es sei denn man belügt ihn.

Ich würde genau das Gegenteil machen: "Schau, so ein Murks ist unser Code. Wir brauchen dich und geben dir den Rückhalt, da Struktur rein zu bringen." Was ich nämlich oft erlebt habe sind festgefahrene Denkweisen, Senior-Entwickler die nicht einsehen wollen dass es anders besser ginge usw. Ich glaube junge Leute wollen was bewegen und etwas Wertschätzung neuer Ideen kommt immer gut an.

Zitat von Phoenix:

Weder an Berufsschulen noch an FH's oder Universitäten wird Delphi gelehrt.
Es kommen einfach keine mehr nach.

Wir haben zwei junge Leute von der Uni bekommen, die haben bei uns ihren Praxisteil absolviert. Also was an der Uni nicht gelehrt wird haben wir ergänzt. Programmiersprachen haben alle irgendwo was gemeinsames. Und für junge Leute ist das oft überraschend leicht, sich an andere Sprachen zu gewöhnen. So aus meiner verkalkten Perspektive mit 20 Jahren Delphi-Erfahrung heraus ^^

Zitat von Phoenix:

Einstiegshürde? Wahnsinnig hoch. Community Edition schön und gut, aber man braucht ne Windows Kiste dafür. Viele haben Macs. Die ganz jungen Coden inzwischen mit ihren iPads im Browser auf Github Codespaces. Nix mehr mit lokaler Installation einer IDE.

Ich denke, Delphi bzw. RAD Studio hat seinen Fokus immer noch auf Desktop-Anwendungen für Datenbankanwendungen. Den Bedarf wird es weiter geben. Ob es unbedingt noch Windows bräuchte oder Emba die IDE nicht auch auf MacOS und Linux portieren könnte wenn sie wollten, ist eine andere Frage. Für mich sind Online-Editoren jedenfalls kein Ersatz für eine echte IDE. Allein schon was Debugging angeht.

Zitat von Phoenix:

Dazu kommt, das moderne Sprachen mit modernen Frameworks drunter einfach zigmal produktiver sind als man mit Delphi noch irgendwie sein könnte.

Hängt auch wieder von der Aufgabenstellung ab. Aber es stimmt schon, wenn ich sehe wie schnell manchmal eine Cloudanwendung hochgezogen und deployed ist, da bin ich schon manchmal neidisch. Wenn man aber später sieht, wie umständlich die Bedienung ist, grad mit responsive Design dann auf dem Smartphone, das ist schon manchmal grausam. Und wird zumindest von unserer Kundschaft auch nicht so stark nachgefragt - zum Glück.