Technische Schulden überall

Veröffentlicht von

Alter Code, alte Projekte, alte Frameworks, alte Programmiersprachen.

Auf Golem.de gibt es einen Artikel über technische Schulden. Darauf will ich mal meinen Senf dazu geben. Reden wir von technischen Schulden in Softwareprojekte, geht es meist um akute Dinge. Das aktuelle Projekt, ein Interface hier, eine Ableitung da. Irgendwas ist schlecht programmiert, das könnte uns am Ende auf die Füße fallen.

Im Golem-Artikel geht es um das große Ganze der Geschichte. Vieles von dem, was entwickelt wird, wird automatisch zur technischen Schuld. Eine Programmiersprache kommt aus der Mode, das hippe Framework wird nicht mehr unterstützt oder es gibt neue Endgeräte, wie Smartphones.

Alte Programmiersprachen

Meine ersten Gehversuche in der Programmierung machte ich auf dem Amiga. AmigaBasic von Microsoft. Die ganze Plattform gibt es inzwischen nicht mehr. Es folgten QBasic und Turbo-Pascal auf dem PC. Diese Sachen bekommt man heute auch noch mit etwas Aufwand in der DOSBox zum Laufen.

Unter Windows verwendete ich erst Visual Basic 6, dann Delphi. VB6-Projekte kompiliert zu bekommen ist schwierig, gleiches gilt für alte Delphi-Projekte. Eine Migration zu Lazarus ist schwierig und früher wurden gerne irgendwelche Komponenten verwendet, welches es so nicht mehr gibt.

Es folgten Visual C++, Microsoft Access und irgendwann C#. C# läuft immer noch und ich denke, irgendeine alte Access-Anwendung bekommt man noch zum Laufen, sofern diese überhaupt noch benötigt.

Die wichtigen Delphi-Anwendungen habe erst nach Lazarus konvertiert, dann mit C# neu geschrieben. Erst mit Windows-Forms, dann mit WPF. WPF funktioniert problemlos, aber Microsoft hat in der Zwischenzeit schon weitere Frameworks bereitgestellt. Plattformunabhängigkeit gibt es nur da.

Ich habe Webanwendungen geschrieben. Erst in PHP, dann in C# mit Webforms. Bei PHP war jeder Versionssprung eine Menge-Arbeit. Webforms sind inzwischen auch veraltet.

Beim letzten Webprojekt haben wir Spring-Boot mit Java als Backend und React als Frontend verwendet. Schaue ich auf die Liste der alten Webtechniken und Frameworks, ist es auch nur eine Frage der Zeit, bis darauf eine technische Schuld wird, welche niemand mehr pflegen kann und will.

Dazu kommen nun auch die mobilen Endgeräte. Damit habe ich mich bisher nur wenig beschäftigt. Aber den Versuch, ein altes Android-Projekt in der aktuellen Version von Android Studio zum Laufen zu bekommen, habe ich entnervt aufgegeben.

Aktuell arbeite ich an einem Java Eclipse RCP Projekt in der Arbeit. Eclipse war mal ein toller Standard und IDE. Wir haben ein paar Wochen gebraucht, um das Projekt auf die aktuelle Eclipse-Version zu hieven. Heute ist es schwierig dafür Leute zu finden, geschweige denn Dokumentation im Internet. Gepflegt werden muss die Anwendung weiterhin. Eine Neuentwicklung ist verdammt aufwändig und teuer. Und am Ende steht man auch wieder nur mit einem weiteren Versuch und Technik da, welcher in ein paar Jahren nur noch eine Randnotiz ist.

Gibt es eine Lösung?

Ich denke nicht! Jede Technik, Programmiersprache und Framework ist irgendwann veraltet. Wann und wie, ist schwierig zu sagen. Eine Software löst die aktuellen Probleme, nicht mehr und nicht weniger. Die meiste Software verschwindet auch in ein paar Jahren wieder.

Ansonsten hilft nur eine stetige Weiterentwicklung. Die IDE regelmäßig zu aktualisieren, neue Version zügig umzusetzen. Externe Abhängigkeiten zu reduzieren.

Ich bin inzwischen auch pragmatischer geworden, was die Programmierung und Architektur angeht. Viel wurde in der Vergangenheit von Wiederverwendbarkeit, Erweiterbarkeit und Zukunftssicherheit geredet. Oft hat es keine Rolle gespielt, weil am Ende die Anwendung eingestellt wurde oder neu entwickelt wurde.

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert