Neues allein um des Neuen willen ohne Mehrwert, wer hat da wirklich was davon?
Wenn dann die "old school" Programmierer ("die gegen jede Neuerung sind und nur blockieren") "endlich" in den Ruhestand gehen, ist der Laden nach einiger Zeit pleite, weil die Software, die bisher für Einkommen sorgte, nicht mehr gepflegt werden kann.
(Ich klinge wie ein verbitterter alter Sack, vermutlich bin ich das inzwischen auch. Es wird Zeit, dass bei uns endlich mal ein junger, unverbrauchter Mensch, frisch von der Uni und ausgestattet mit dem Wissen über die neuesten Trends in der Softwareentwicklung das Ruder übernimmt. Unsere Software müsste endlich unbedingt nach Rust portiert werden und natürlich eine Anbindung per Cloud und App bekommen.)
Interessanterweise habe ich genau das erlebt, vor einigen Jahren. Ich kam sozusagen als Frischfleisch ins Team weil man sich wegen der Rente in Sichtweise bei einigen Programmierern Gedanken machte. Ich konnte vorher Delphi und machte weiter mit Delphi, insofern nix Karrieregift.
Was ich aber vorfand war grausam unlesbarer Bestandscode. Allein der Versuch von Refaktorierung war ein K(r)ampf. Sowohl mit der
IDE als auch mit den "alten Hasen". Einfach nur eine Programmiersprache zu beherrschen reicht noch lange nicht, um ein gutes Produkt zu bauen. Du brauchst das historische Wissen, warum manche Dinge so unfassbar schräg programmiert wurden. Du brauchst das fachspezifische Wissen um die Probleme die deine Software lösen soll. Große Firmen wie Microsoft haben dafür Manager, die nur fürs Denken und Erklären bezahlt werden. Dort braucht der Programmierer im Wesentlichen ein Lastenheft. Je kleiner aber die Firma, umso mehr Verantwortung haben die einzelnen Programmierer. Geht dann einer in Rente oder fällt aus anderen Gründen aus, ist das Chaos vorprogrammiert.
Ist das am Ende nicht die eigentliche "technische Schuld", um das Buzzword mal aufzugreifen? Der Wissenstransfer zwischen den Entwicklern? Vielleicht ist es genau das, was Open Source Software langfristig erfolgreicher macht. Die Wege sind manchmal länger, weil die quasidemokratischen Prozesse zu vielen Parallelentwicklungen führen (siehe Wildwuchs an Linux-Distributionen). Andererseits kann man dann aus vielen Lösungen die besten auswählen und macht das Gesamtkonstrukt am Ende besser.