Technologie ändert sich täglich - sollte Ihr Unternehmen mithalten?

Eigentlich nein. Es sei denn, das Geschäft selbst erzeugt diesen Änderungsbedarf.

Diesen Fehler machen viele (auch ich). Eine neue Technologie kommt heraus, und unsere Software muss damit neu geschrieben werden. Aber welchen Vorteil bringt das unserem Geschäft und unseren Endnutzern? In den meisten Fällen keinen.

Statt Zeit damit zu verbringen, auf neuere Technologien umzustellen oder nach jedem Minor-Release Ihrer 250 Abhängigkeiten zu aktualisieren und neu zu testen, könnte diese Zeit genutzt werden, um neue Funktionen für Ihre Endnutzer zu entwickeln und auszuliefern. Wirklich, niemanden interessiert, dass Sie die neueste Angular-Version verwenden, wenn Ihnen Funktionen fehlen, die Ihre Konkurrenten haben.

Okay, könnten Sie sagen, aber was passiert in 3 Jahren, wenn ein Upgrade nötig wird, Sie 10 Major-Versionen hinterherhinken und tonnenweise “Legacy”-Code haben?

Erstens: Seien Sie stolz auf das, was Sie erreicht haben. Dass Sie Ihre Ressourcen richtig priorisiert haben, bedeutet, dass Ihr Geschäft nun den Wandel antreibt und ein Upgrade erforderlich macht. Ohne diese Priorisierung wäre Ihr Geschäft vielleicht nie abgehoben, und Sie würden noch im Dunkeln arbeiten und zwischen Angular-Versionen wechseln, ohne dass jemand Ihre Software wirklich nutzt.

Zweitens: Versuchen Sie nicht, Ihre gesamte Software neu zu schreiben. Das gilt besonders für Webanwendungen. Schreiben Sie zunächst nur die Module neu, für die das Upgrade erforderlich war. Setzen Sie das in neuen Modulen oder Funktionen, die Sie entwickeln, fort, und entscheiden Sie bei größeren Änderungen in anderen Modulen, ob sich ein Neuschreiben lohnt, und tun Sie es dann.

Wenn es funktioniert, fass es nicht an

Jede Änderung birgt Risiko, und so müssen Sie nach jedem Update Ihre Software erneut testen. Alternativ können Sie es einfach in die Welt entlassen und auf Brände warten; das funktioniert ebenfalls, bis zu einem gewissen Punkt, und hängt sehr von der Situation ab. Bei Ihrem eigenen Produkt mag das gehen, denn wenn etwas passiert und Sie Geld verlieren, ist es Ihre Schuld, Ihr Geld. Aber was passiert, wenn Sie diese Änderung für einen Kunden vornehmen, in der Annahme, etwas Gutes zu tun, der Kunde aber gar nicht danach gefragt hat und Sie ihn nicht informieren - und Sie einen Bug einbauen, der ihn Geld kostet? Genau. Sie sind ein Risiko für etwas eingegangen, das Ihr Kunde nicht beziffern kann, und es ist Ihnen um die Ohren geflogen.

Den Wechsel begründen

Ein Wechsel kann gerechtfertigt sein. Stellen Sie nur sicher, dass Sie sich nicht selbst (oder Ihrem Kunden, wenn Sie für jemand anderen arbeiten) etwas vormachen, nur um des neuen Spielzeugs willen. Spielzeuge kommen und gehen; sie zerbrechen, werden weggeworfen, und dann kauft man neue. Denken Sie in Werkzeugen, denken Sie an Produktivität, Performance, Sicherheit. “Risiko reduzieren” ist zu generisch. Bringen Sie echte Argumente und Zahlen, um eine solche Entscheidung zu stützen.