© Ozz Design/Shutterstock.com
Erfolgreich Softwareprojekte modernisieren - Teil 1

Der Faktor Mensch


Ein Softwareprojekt ist mitunter ein komplizierter Mikrokosmos. Diesen gilt es an die Veränderungen der Zeit anzupassen, zu warten und zu modernisieren. Wie kann das möglichst ohne Komplikationen gelingen? In dieser Artikelserie werden wir dieser Frage auf den Grund gehen.

Am Anfang ihrer Tätigkeit sorgen Softwareentwicklerinnen zumeist selbst für zukünftigen Modernisierungsbedarf. Bei der Mehrzahl der Projekte, an denen der Autor in den letzten zehn Jahren beteiligt war, wiesen diese Projekte bereits zu seinem Einstieg einen erheblichen Modernisierungsbedarf auf. Das ist nicht unbedingt verwunderlich, zumal der Auftrag in einigen dieser Fälle lautete, diese Projekte zu modernisieren. In anderen Fällen ging es eingangs darum, bei der Umsetzung dringend benötigter Funktionalitäten zu helfen. Hier waren sich die Auftraggeberinnen gar nicht im Klaren darüber, dass sich ihr Projekt in einem Zustand befand, der eine Weiterentwicklung nur schwerlich möglich machte. Nach den Einblicken, die der Autor im Laufe der Zeit gewonnen hat, geht er nun davon aus, dass die meisten Softwareprojekte einen massiven Modernisierungsbedarf haben. Dieser Bedarf bleibt meist so lange unentdeckt, bis sich etwas an den Umständen eines Unternehmens ändert.

Die Grundproblematik

Externe Schocks wie der Klimawandel, eine Wirtschaftskrise oder eine Pandemie können ein Unternehmen in Zugzwang bringen. Aufträge und ganze Geschäftsfelder brechen weg, Kosten müssen eingespart werden. Konkurrenten, die sich besser aufgestellt haben, drängen in den Markt. Die Gesetzgebung erwartet unter Androhung von hohen Strafen, dass bestimmte Funktionalitäten eingeschränkt oder umgesetzt werden. Plattformen, Frameworks und Bibliotheken veralten, und Anbieterinnen zeigen an, dass Weiterentwicklung und Support eingestellt werden. Nun muss dringend etwas getan werden! Fehlen diese externen Faktoren, kann der Modernisierungsbedarf oft erst erkannt werden, wenn neue Mitarbeiterinnen eingestellt oder Freiberuflerinnen, Beraterinnen und Agenturen beauftragt werden. Neue Mitarbeiterinnen und Externe verfügen in der Regel über einen anderen Schatz an Erfahrungen und Kompetenzen, vor deren Hintergrund der konkrete Modernisierungsbedarf erst sichtbar werden kann. In einem Projekt werden Versionen von PHP verwendet, die offiziell nicht mehr unterstützt werden. Während neuere Versionen von PHP neue Funktionsumfänge und deutlich mehr Leistung bieten, sind sie allerdings nur bedingt abwärtskompatibel. In einem weiteren Projekt stellt sich das von den Gründern eines Unternehmens mit- und dann intern weiterentwickelte Framework als Sackgasse heraus. Es ist komplett ungetestet und wenig dokumentiert, und Entwicklerinnen, die ein Interesse haben, sich in dieses Framework einzuarbeiten und es weiterentwickeln wollen, sind schwer oder kaum zu finden. Angesichts einer Vielzahl an alternativen Bibliotheken und Frameworks und begrenzter Kapazitäten lohnt sich die Weiterentwicklung nicht.

In einem anderen Projekt wurden die verwendeten Bibliotheken und Frameworks in die Versionskontrolle aufgenommen. Hier ist zum Teil nicht mehr feststellbar, woher diese Bibliotheken und Frameworks kommen. Da im Laufe der Zeit leider auch Änderungen an diesem Code vorgenommen wurden, ist die Identifikation der konkreten Versionen zusätzlich erschwert. Mit Sicherheit kann man aber davon ausgehen, dass diese Bibliotheken und Frameworks komplett veraltet sind. Wiederum in einem anderen Projekt wird immerhin Composer verwendet, um Bibliotheken und Frameworks ins Projekt einzubinden. Leider sind auch hier die verwendeten Versionen komplett veraltet. Eine Aktualisierung ist aufwendig, da die Geschäftslogik viel zu eng mit diesen Bibliotheken und Frameworks verheiratet worden ist. Zum Teil ist eine Aktualisierung auch nicht mehr möglich, da die Weiterentwicklung kompatibler oder gänzlich neuer Versionen bereits vor Jahren eingestellt wurde. Die meisten Projekte leiden an einem geringen Automatisierungsgrad. Einen einheitlichen Coding-Standard gibt es nicht. Hier wird manuell getestet, da man keine Zeit hat, automatisierte Tests zu schreiben. In der Open-Source-Community weit verbreitete Tools sind nicht bekannt und werden hier auch nicht verwendet. Entwicklerinnen und Managerinnen haben sich an eine geringe Entwicklungsgeschwindigkeit gewöhnt und sind sich nicht im Klaren darüber, dass Softw...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang