Die Website funktioniert nach einem Update nicht mehr? Hat der neue Entwickler etwas falsch gemacht? Was ist hier los?

So viele Fragen. Mit diesem kurzen Beitrag möchte ich Sensibilität für das Thema des "Updates" erzeugen.

Das Problem: Wenn Updates alles ruinieren

Zu Beginn möchte ich das Problem genauer erklären. In allen Bereichen des Lebens wird Software eingesetzt. Das geht bei der Lagerverwaltung los und hört bei Buchungssystemen auf. Das Problem ist, dass diese Software oft schon einige Jahre alt ist. Grundsätzlich nicht schlimm, jedoch wurde durch viele Auftraggeber:innen am falschen Ende gespart. Wenn Software beispielsweise als Werkvertrag erstellt wird, ist nach der finalen Auslieferung Schluss. Eventuell nicht mit dem Kundensupport für die Software, aber meist mit der Weiterentwicklung. Meist ist der Geschäftsprozess komplett abgebildet und es besteht über Jahre kein Bedarf an Weiterentwicklung.

Software, die so entstanden ist, wird dann irgendwann von den Lebenszyklen der umgebenden Software überholt. Die Abhängigkeiten sind so starr, dass ab einer gewissen Version des Betriebssystems, APIs, Datenbankservers, Webservers oder Browsers keine Funktionalität mehr gegeben ist.

Das neue Feature

Wenn nun nach vielen Jahren, in denen die eingesetzte Software ohne Probleme lief, ein neues Feature umgesetzt werden muss, stellen beauftragte Entwickler:innen schnell fest, dass es ein einziges Chaos ist, was sich hinter dem Frontend verbirgt. Im besten Fall ist der Code gut dokumentiert, im Worst-Case-Szenario jedoch sind veraltete Abhängigkeiten mit undurchsichtigem Code kombiniert.

Den Entwickler:innen bleiben dann meist nur zwei Möglichkeiten. In der Ersten würde ein Refactoring der Anwendung durchgeführt und im Endeffekt die Software neu geschrieben werden. Das kostet Zeit und somit Geld. Geld und Zeit, die die Auftraggeber:innen oft nicht ausgeben wollen. Die zweite Möglichkeit besteht darin, immer wieder Verbesserungen zu implementieren, die den Code noch weiter aufblähen und strukturell unwartbar machen. Wenn dann noch regelmäßig unterschiedliche Entwickler eingesetzt werden und die Dokumentation nicht passt, ist am Ende eine Software geschrieben, die nicht mehr weiterentwickelt werden kann. Hinzu kommt, dass dann das Stack (also die Rahmenbedingungen wie Betriebssystem, Browser etc. pp.) dann auch nicht modernisiert wird, sondern oft die alten Abhängigkeiten bestehen bleiben.

Für jede Entwickler:in ist das gewissermaßen der Super-GAU.

Nun gibt es noch eine dritte Möglichkeit, einen solchen Code zu aktualisieren. Dies ist aber mit Abstand die aufwendigste und unwirtschaftlichste. Kaum eine Auftragnehmer:in wird sich das antun. Bei dieser Variante wird quasi der ganze Code so weit einem Refactoring unterzogen, dass die strikten Abhängigkeiten aufgelöst werden. Das Problem bei diesem Vorgehen ist, dass es für Auftraggeber:innen von außen als sinnvoll angesehen wird. Für einige drängt es sich ja gewissermaßen auf, hier und da ein paar Anpassungen vorzunehmen und schon läuft die neue Software unter dem neuesten Kernel, auf einem anderen Webserver, mit einer anderen PHP-Version oder anderen Microservices. So einfach ist es jedoch nicht. Denn auch wenn die offensichtlichen Abhängigkeiten aufgelöst wurden, kann durch die veränderte Syntax der Programmiersprache an vielen Stellen ein Bug versteckt sein. Was früher nämlich wunderbar funktionierte, führt unter aktuellen Rahmenbedingungen zu Fehlern.

Nach dem Update überall Fehler im Code!

Diese Fehler im Code sind jedoch nichts, was die neuen Entwickler:innen eingebaut haben oder zu verschulden hätten. Diese Fehler sind im Endeffekt einfach so durch die Updates entstanden. Auch ursprüngliche Entwickler:innen tragen nicht unbedingt die volle Schuld. Natürlich hätten diese unter aktuellen Gesichtspunkten eine Software schreiben können, die durch Tests entsprechendes Fehlverhalten auffängt und zumindest meldet. Jedoch ist Test-Driven-Development etwas, was erst in den letzten Jahrzehnten so wirklich in der breiten Entwickler:innen-Gemeinde akzeptiert bzw. umgesetzt wurde.

Um es ganz deutlich zu sagen: Wer Software 10, 15 oder 20 Jahre nicht aktualisiert, dann ein Update auf eine schnellere/andere Umgebung durchführen will, ohne den Code neu zu schreiben, muss damit leben, dass immer wieder Fehler entstehen an Stellen, die all die Jahre funktionierten. Oft sind diese fehlerbehafteten Stellen auch Originalcode. D.h. das neue Entwickler:innen-Team hat daran nichts geändert. Diese Fehler passieren.

Je größere Versionssprünge eine Software macht, desto größer wird die Anzahl der Fehler. Eine Software aus den frühen 2000er Jahren in das Jahr 2021 zu updaten, ist eine Herkulesaufgabe. Oftmals ist hier die Neuentwicklung der sinnvollere Ausweg. Besonders dann, wenn die Software nicht von der Stange ist. Individuelle Programme/Onlineshops/CRM-Programme etc. pp. sind von den hier skizzierten Problemen deutlich mehr gefährdet als eine über Plug-ins modifizierte Standardanwendung.

Auftraggeber:innen sensibilisieren

Nun ist es die Aufgabe der Entwickler:innen, die Auftraggeber:innen zu sensibilisieren. Wer Software entwickelt und abliefert, sollte darüber informieren, dass eine regelmäßige Wartung wichtig ist. Dies sollte neben der Einhaltung von aktuellen Standards und einer guten Dokumentation einfach dazugehören.

Es ist aus meiner Sicht auch nicht verkehrt, einen Servicevertrag anzubieten, der regelmäßige Updates umfasst. Der Arbeitsaufwand kann so auf einem adäquaten Niveau gehalten werden, da meist die Unterschiede zwischen den Minor-Versionen minimal und zwischen den Major-Versionen gut dokumentiert - teils auch automatisiert sind.

Als letzten Punkt sind hier noch Tests zu erwähnen. Nicht nur einzelne Funktionalitäten sollten im Sinne von TDD automatisiert überprüft werden. Auch das Frontend und die dort gewünschten Zustände sollten mittlerweile Teil des Testfalls sein.

Ja, das ist viel Arbeit. Und ja, viel Arbeit kostet Geld. Aber nur wenn viel Arbeit investiert wurde, steigt die Wahrscheinlichkeit auch in Zukunft mit der Software, dem Onlineshop, dem Abrechnungssystem und allen anderen Anwendungsmöglichkeiten eine update-fähige Entwicklung zu haben.