Kolumne: Stropek as a Service

Feiert Legacy! Langfristig erfolgreiche Firmen gehen gelassen mit Legacy um
Keine Kommentare

„Legacy software is software that earns money.“ In diesem Sprichwort steckt mehr als nur ein Körnchen Wahrheit und doch feiert die Branche immer nur die neusten Trends und heißesten Tools. Irgendwann wird aber auch daraus eine Legacy-Lösung. Wie geht man damit um?

„Legacy software is software that earns money.“ In diesem Sprichwort steckt mehr als nur ein Körnchen Wahrheit. Unsere Softwarebranche feiert sich selbst wegen ihrer rasch aufeinander folgenden Innovationen. Wer dazugehören will, nutzt immer die aktuellsten Sprachen, die neuesten Frameworks und heißesten Tools. Es kann nicht Beta und Preview genug sein. Wir vergessen dabei, dass fast jede Software, die heute mit (B)Leading-Edge-Technologie gebaut ist, im Laufe der Zeit viele Legacy-Komponenten enthalten wird. Ich kenne kein einziges Softwareunternehmen, das in der Lage wäre, genügend finanzielle und personelle Ressourcen auf die Beine zu stellen, um dieser Tatsache vollständig zu entkommen.

Selbsterkenntnis

Unternehmen, die langfristig mit Software Erfolg haben wollen, brauchen daher eine Strategie, um mit Legacy umzugehen. Dabei steht aus meiner Sicht wie bei so vielen Dingen die Selbsterkenntnis am Anfang. Es braucht eine ehrliche Betrachtung des Status quo und das Erkennen, Sichtbar- und Bewusstmachen von technischen Schulden.

BASTA! 2020

Entity Framework Core 5.0: Das ist neu

mit Dr. Holger Schwichtenberg (www.IT-Visions.de/5Minds IT-Solutions)

Memory Ownership in C# und Rust

mit Rainer Stropek (timecockpit.com)

Softwarearchitektur nach COVID-19

mit Oliver Sturm (DevExpress)

Delphi Code Camp

Delphi Language Up-To-Date

mit Bernd Ua (Probucon)

TMS WEB Core training

mit Bruno Fierens (tmssoftware.com bvba)

Viele Teams schrecken vor einer solchen Bestandsaufnahme zurück, da es ihnen unangenehm ist, offen zuzugeben, dass ihre Software zum Teil auf veralteten Komponenten aufgebaut ist. Das klingt nach Versagen. Ist es aber nicht! Softwarealterung ist eine unvermeidliche Tatsache für Software, die über lange Zeit im Einsatz und am Markt erfolgreich ist. Kunden wünschen sich neue Funktionen, und die Arbeit an ihnen steht in Konkurrenz zu Modernisierungsmaßnahmen an der Basis. Hat ein Team alle Zeit der Welt, um alle Komponenten auf dem Laufenden zu halten und jedem Trend hinterherzulaufen, dann fehlen ihm wahrscheinlich die nach funktionalen Erweiterungen rufenden Kunden.

Legacy-Management

Innovative Entwicklungsteams managen ihre technischen Schulden aktiv. Diese sind Teil des Product Backlogs. Die Teams wissen, wo Legacy-Komponenten im Einsatz sind und sind realistisch, was den Zeitplan für eine Aktualisierung oder ein Ersetzen betrifft. Das bedeutet manchmal, dass es noch keinen Zeitplan gibt. An erster Stelle steht daher das ehrliche Eingeständnis, dass man bis auf weiteres mit Legacy in gewissen Bereichen leben muss. Meiner Erfahrung nach ist die wiederholte Ankündigung von Modernisierungsprojekten, die dann doch nicht stattfinden, eine größere Gefahr, wertvolle Teammitglieder zu verlieren, als das offene Ansprechen der Tatsache, dass gewisse alte Teile einer Software kurz- bis mittelfristig nicht überarbeitet werden können.

Mit diesen Aussagen meine ich keinesfalls, dass es der richtige Weg ist, veraltete Systemteile als gegeben hinzunehmen und keinerlei Schritte hin zu ihrer Modernisierung zu unternehmen. Diese Extremposition wäre genauso verkehrt wie das manische Bedürfnis, immer mit allem auf dem neuesten Stand sein zu müssen. Es braucht eine gesunde Balance aus funktionalen Erweiterungen und technischer Modernisierung, die durch einen Priorisierungsprozess geleitet ist. Die Priorisierung sollte, soweit machbar, auf objektiven Kriterien wie Nutzungsdaten, Kundenbefragungen und Risikokalkulationen aufbauen.

Legacy-Kultur

Entscheidend für die langfristige Teammotivation ist meiner Erfahrung nach eine Unternehmenskultur, die nicht nur technische Neuerungen, sondern auch das Aufrechterhalten eines Systems trotz älterer Komponenten wertschätzt. Viele Unternehmen tendieren dazu, immer nur diejenigen Mitarbeiterinnen und Mitarbeiter vor den Vorhang zu holen, die unbekanntes Territorium mit den neuesten Softwarewerkzeugen beschreiten. In solchen Bereichen kann man allerdings auf der grünen Wiese ohne Zeitdruck und ohne Kunden im Nacken arbeiten. Da ist es für die Teammitglieder frustrierend, die die Cash Cows am Laufen halten und deren Arbeit die Gehälter der ganzen Firma trägt, wenn ihre Leistungen nicht genauso sichtbar gewürdigt werden.

Vor einigen Monaten hatte ich als Berater ein Engagement bei einem Kunden, bei dem es um die Modernisierung einer in die Jahre gekommenen Standardsoftwarelösung ging. Das bestehende Produkt basierte auf sehr alter Technologie, war aber am Markt erfolgreich und wurde von einem einzigen Mitarbeiter am Leben erhalten, der schon lange im Unternehmen tätig war. Ihm gegenüber saß ein mehrköpfiges, junges Entwicklungsteam, dessen Aufgabe die komplette Neuentwicklung der Software war. Der Mitarbeiter, der die bestehende Lösung zu warten hatte, war ständigen (teilweise) unterschwelligen Vorwürfen wegen mangelnder Innovationsbereitschaft ausgesetzt, weil er auf viele Hürden für die Neuentwicklung hinwies, die er aus jahrelanger Praxis kannte. Niemand kam auf die Idee, ihn zu fragen, wie er mit technisch und personell beschränkten Mitteln in der Lage war, die Software so lange erfolgreich am Laufen zu halten. Das Management stellte mir gegenüber das neue Entwicklungsteam als technologische Superstars vor. Keine Rede von dem Teammitglied, dessen erfolgreiche Arbeit das Neuentwicklungsprojekt finanziell erst ermöglicht hatte.

Eine solche Vorgehensweise ist menschlich nicht in Ordnung und unternehmerisch riskant. Das Managementteam muss eine Kultur fördern, in der die Aufrechterhaltung eines Systems trotz technischer Einschränkungen geschätzt und als intellektuelle Herausforderung anerkannt wird. Innovationsfähigkeit ist eine wertvolle Eigenschaft eines Teams, aber nicht die einzige.

Respekt vor Erreichtem

Personen, die Teams leiten, sollten meiner Erfahrung nach insbesondere unerfahreneren Teammitgliedern gegenüber Vorbild sein, indem sie Respekt vor Erreichtem zeigen. Das gilt speziell bei der Diskussion neuer Technologien. Oft erscheinen Technologieänderungen als reizvoll, weil sie versprechen, gewisse Probleme von Legacy-Komponenten von Grund auf auszumerzen. Erfahrene Entwicklerinnen und Entwickler wissen aber, dass keine Programmierplattform perfekt ist und dass es keine Silver Bullets gibt. Im täglichen Einsatz wird auch die neue Technologie ihre Macken haben, man kennt sie nur noch nicht. Im Idealfall sind es weniger Macken als im Legacy-Bereich, los wird man aber sicher nicht alle. Insofern braucht es gerade bei technischen Strategieentscheidungen ein Abwägen von Vor- und Nachteilen, das von Emotionen und subjektiven Vorlieben so frei wie möglich ist.

Neben neuen, technischen Herausforderungen dürfen bestehender Code und vorhandenes Wissen nicht außer Acht gelassen werden. Im vorhandenen Code steckt eine Menge Hirnschmalz, das man nicht achtlos vergeuden sollte. Die Teammitglieder haben im Laufe der Jahre gelernt, bekannte Tools zu meistern. Das ist ein großer Pluspunkt, den man entsprechend würdigen muss.

Too big to fail

Der Hang zum Perfektionismus steht vielen Teams bei der Bewältigung von technischen Schulden im Weg. Wenn eine Modernisierung angegangen wird, dann soll es diesmal richtig gemacht werden. Man will Best Practices einhalten und von Anfang an alles richtig machen. Durch diesen gutgemeinten Vorsatz wird der Berg an Aufgaben so groß, dass das Projekt nie startet –währenddessen altert die Software weiter vor sich hin. Irgendwann steht man vor einer Codebasis, die so groß und unternehmenskritisch ist, dass sich niemand mehr traut, etwas daran zu ändern. Das gilt insbesondere, weil parallel zu einem veralteten Softwaremonolithen meistens auch eine hohe Personalfluktuation zu finden ist.

Schrittweise Verbesserung schlägt Perfektionismus so gut wie immer. Microservices sind ein Mittel, sie zu ermöglichen. In Microservices-Workshops können Kunden oft nicht glauben, welche Regeln bei Microservices gelten: Eine gemeinsame Datenbank für mehrere Microservices als Antipattern, im Ernst? Da hat man doch nur noch mit inkonsistenten Daten und Schnittstellen zu tun; so etwas und ähnliches wird diskutiert. Übersehen wird, dass Microservices nicht primär ein Mittel zur technischen Effizienzsteigerung sind, die kann ein Nebeneffekt sein. Ziel ist es, lose gekoppelte Komponenten zu erstellen, die mit unterschiedlichen Geschwindigkeiten weiterentwickelt und gegebenenfalls auch ausgetauscht werden können. Damit wird die Microservices-Architektur zu einer langfristigen Strategie, gelassen mit Legacy-Code umzugehen.

Umwälzungen

Meine oben angeführten Argumente möchte ich nicht als Appell missverstanden wissen, dass Änderungen generell eine Sackgasse sind und man am besten alles beim Alten belässt. Ganz im Gegenteil, ich bin davon überzeugt, dass viele der aktuellen technischen Entwicklungen wie Serverless Computing, Event-getriebene Architekturen, neue Programmiersprachen wie Go, Dart und Rust, Microservices und so weiter fundamentale Verbesserungen gegenüber manchen etablierten Prinzipien in der Softwareentwicklungen darstellen. Ich möchte mit diesem Beitrag allerdings davor warnen, Legacy-Code zu verurteilen und als die Wurzel allen Übels darzustellen.

Nachhaltige Innovationen entstehen schrittweise. Ein funktionierendes, komplexes Gesamtsystem basiert auf kleineren, funktionierenden Einheiten. Erfolgreiche Teams wissen das und finden einen Weg, wie Legacy und Leading Edge nebeneinander existieren und die dafür jeweils zuständigen Personen respektvoll miteinander umgehen können.

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. Außerdem ist der Windows Developer weiterhin als Print-Magazin im Abonnement erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -