Zu Ehren des 500. Todestages von Leonardo da Vinci finden rund um die Welt Ausstellungen seiner Werke und Erfindungen statt. Völlig berechtigt, befinden allerlei Journalisten [Zeit19], und Museen, Hochschulen und Werkstätten haben seine genialen Maschinen nachgebaut. Leonardo hat uns ein extrem beeindruckendes Vermächtnis hinterlassen.
Szenenwechsel: Mozart. Wolfgang Amadeus, lebte 1756 bis 1791. Nicht ganz so lange her wie da Vinci, aber auch schon alt. Mozarts musikalisches Vermächtnis rockt auch heute noch die Konzertsäle dieser Welt (eine Internet-Suche nach Mozart-Konzerten 2019 bei einigen Online-Ticketbörsen ergab mehrere Hundert Treffer).
Nein, dieser kleine Ausflug in Kunst und Kultur ist kein Fehler – sondern der Versuch, die oftmals positive Bedeutung des Begriffes „Vermächtnis“ exemplarisch zu erklären. Vermächtnis, Hinterlassenschaft, geistiges oder schöpferisches Erbe – eben „Legacy“: Das gilt meistens als etwas Positives, Werthaltiges, an das sich zu erinnern lohnt. Böse Diktatoren und Tyrannen bilden unrühmliche Ausnahmen. In unseren IT-Kreisen hat das Wort „Legacy“ ebenfalls eine negative Konnotation.
Was ist „Legacy-Software“?
In der Regel werden Legacy-Systeme aktiv benutzt, es wird Geld damit verdient oder wichtige Arbeit damit erledigt – sie sind „in Produktion“. Es gibt ergo Menschen, die dieses System erhalten oder sogar erweitern wollen, auch wenn das nicht immer im Sinne der betroffenen Entwicklungsteams ist. Gemeinsam ist vielen Legacy-Systemen ebenfalls, dass Arbeit daran meist länger dauert, als es unbedingt sein müsste, das heißt, in Legacy stecken teilweise erhebliche technische Schulden (siehe [Kru19], ein ganz aktuelles Buch zu diesem Thema).
Lassen Sie uns einige sehr unterschiedliche Definitionen des Begriffes „Legacy“ anschauen – wie oft in unserer Branche gibt es dazu nämlich vielerlei Meinungen:
- Michael Feathers bezeichnet in [Fea04] „Code ohne Tests“ als Legacy. Im Groben lautet seine Argumentation: Hast Du keine Tests, kannst Du nur mit hohen Risiken ändern.
- Adam Tornhill nennt in [Tor18] Legacy „Code mit Qualitätsmängeln, den wir nicht selbst geschrieben haben“. Mir gefällt der erste Teil der Definition, weil ich Legacy persönlich mit Qualitätsmängeln in Verbindung bringe. Persönlich habe ich jedoch Code auf dem Gewissen, der aus meiner heutigen Sicht eindeutige Qualitätsmängel aufweist – und daher für mich zu Legacy zählt – obwohl ich ihn selbst verbrochen habe.
- Wikipedia [WikiLC] nennt Legacy hingegen „Code mit Abhängigkeiten zu nicht mehr unterstützten Betriebssystemen oder anderen Technologien“.
- Eli Lopian nennt Legacy in [Lop18] denjenigen Code, „den Entwicklungsteams nicht mögen“ (oder sogar „fürchten“).
Manche Legacy-Systeme leiden unter dem sogenannten „Revision-Lock“: Sie sind von einer bestimmten Version einer Technologie (etwa: Library, Framework, Betriebssystem oder auch Hardware) abhängig, die wir nicht ohne Weiteres austauschen oder upgraden können – weil wir schlimmstenfalls von Features dieser Technologie abhängig sind, die in aktuellen Versionen nicht mehr zur Verfügung stehen (ja, richtig – das klingt, wie sich selbst ins Knie schießen – aber in der Vergangenheit konnten unsere Vorgänger ja noch nicht wissen, welche Features später mal nicht mehr unterstützt werden).
Natürlich geht es noch schlimmer: Es gibt Legacy-Systeme, die noch produktiv laufen, aber deren Sourcecode nicht mehr auffindbar ist. Selbst der finanziell ja recht gut ausgestatteten NASA ist solches passiert (siehe [NASA]). Dann habe ich doch lieber Systeme, an denen ich zumindest noch aktiv arbeiten und ändern kann …
Es war (meist) teuer …
Im schlechten Scherz „ab dem zweiten Sprint ist es Legacy“ steckt natürlich ein kleiner Kern Wahrheit – aber bei vielen Systemen dauert es merklich länger, bis Teams sie als „Legacy“ bezeichnen. Vom Zeitpunkt der grünen Wiese, dem Start der Entwicklung, bis heute, hat irgendjemand für dieses System Geld bezahlt, für Implementierung, Test, Abstimmungen, Bugfixes und alle weiteren Aktivitäten.
Nehmen wir an, an einem IT-System arbeitet ein Team von 5 bis 10 Personen zusammen: Bei geschätzten 200 Arbeitstagen pro Person und Jahr fließen jedes Jahr also 1000 bis 2000 Personentage in unser System. Wir konzipieren, entwickeln, diskutieren, wir beheben Fehler, reagieren auf neue und geänderte Anforderungen von Fachbereichen und Anwendern – ganz normale Entwicklung halt. Unser System erweist sich wirtschaftlich als erfolgreich, also arbeiten wir weiterhin unter dem allseits bekannten Zeit- und Feature-Druck, sagen wir drei Jahre lang. In Summe kommen also zwischen 3000 und 6000 Personentage an Arbeitsaufwand zusammen, nicht eingerechnet sind Hardware, Lizenzkosten, Miete, Reisekosten und sonstige Nebenkosten.
Sie wissen vermutlich selbst, was IT-Spezialisten heutzutage kosten. Bei unseren 3000 bis 6000 Personentagen kommen wir da schnell auf mehrere Millionen Euro an Investition in unser System, nur an Personalkosten. Das sind beeindruckende Summen, die Entscheider nur ungerne „in den Wind“ schreiben, sondern (fast) alles dafür tun möchten, diese Investition, sprich unser nun Legacy genanntes IT-System, am Leben zu erhalten.
In meiner eigenen Laufbahn bin ich übrigens mehr als einem Dutzend (Legacy-)Systemen „begegnet“, in deren Entwicklung noch eine Größenordnung mehr an Aufwand geflossen ist – also mehrere 10.000 Personentage. Diese Zahlen rühren entweder von viel größeren Entwicklungsteams oder signifikant längerer Laufzeit: In manchen Branchen „leben“ Systeme ja durchaus 20 Jahre oder länger – und kontinuierlich wird an ihnen gearbeitet.
Aber es ginge doch viel besser
Oft wird der Ruf laut, man (sprich: das Entwicklungsteam) solle doch dieses angeblich so schlechte Legacy-System durch ein komplett neues Stück Software ersetzen. Dieser Big Rewrite ist eine ebenso schlechte Idee wie der Versuch, in ein verzögertes Projekt noch weitere Leute zu stopfen (siehe [WikiBL] und [Spo00]). Hello-World-artige, winzig kleine Systeme bilden sicherlich eine Ausnahme – die können Sie gerne wegwerfen und neu implementieren.
Wenn Sie ernste Defizite an Ihrem (größeren) Legacy-System feststellen, dann verbessern Sie sukzessive – am besten iterativ und inkrementell, mit möglichst kurzfristigem Feedback (siehe [aim42]).
Ausbildung fokussiert Neuentwicklung
Schätzungsweise 70 bis 80 Prozent der gesamten Zeit verbringen Entwicklungsteams rund um die Welt damit, bestehende Systeme (also: Legacy) zu erweitern, zu aktualisieren oder zu optimieren. In typischen IT-Ausbildungen oder Studiengängen jedoch nimmt die Pflege bestehender Systeme einen verschwindend geringen Teil ein.
Es wäre schön, wenn in der IT-Ausbildung auch Legacy-bezogene Aufgaben auftauchen würden – etwa in einem Team mit 2 bis 3 Personen mal einige Bugs von bekannten Open-Source-Bibliotheken zu beheben. Zum Glück haben mittlerweile einige Hochschulen solche Aktionen „im Programm“ – etwa [HHU].
Fazit
Legacy ist unser Normalfall. Große, über lange Zeit historisch oder hysterisch gewachsene Systeme wegzuwerfen (aka Big Bang), ist in den weitaus meisten Fällen viel zu riskant und damit keine echte Option. Wir sollten das Vermächtnis vieler Hunderten oder Tausenden Tagen Entwicklungszeit eher wertschätzen, und uns trotz hoher technischer Schulden in diesen Systemen daran wagen, sie in kleinen Schritten kontinuierlich zu verbessern. Eine spannende Aufgabe für die Rolle „Softwarearchitekten“!||
Weitere Informationen
[aim42] aim42.org oder aim42.github.io, die Architecture Improvement Method – eine Open-Source-Methode zur systematischen Verbesserung von Legacy-Systemen
[Fea04] M. Feathers, Working Effectively With Legacy Code, Prentice Hall, 2004 (Trotz seines Alters ein zeitloses Buch, das unter anderem eine Menge Vorschläge enthält, wie Sie Abhängigkeiten in Ihrem Code reduzieren könnten. Eine Zusammenfassung einiger Themen finden Sie unterhttps://medium.com/@biratkirat/working-effectively-with-legacy-code-series-251b9c7d8c15)
[HHU] J. Bendisposto, Universität Düsseldorf, siehe:https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/team/bendisposto.html
[Kru19] Ph. Kruchten, R. Nord, I. Ozkaya, Managing Technical Debt: Reducing Friction in Software Development, SEI Series in Software Engineering, Pearson, 2019
[Lop18] E. Lopian, CEO von TypeMock, Defining Legacy Code, DZone, 15.5.2018, siehe: https://dzone.com/articles/defining-legacy-code
[NASA] R. Chirgwin, NASA finds satellite, realises it has lost the software and kit that talk to it, 30.1.2018, siehe: https://www.theregister.co.uk/2018/01/30/zombie_satellite_is_image/
[Spo00] J. Spolsky, Things you should never do, Part I, 6.4.2000, siehe: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
[swe-podcast] D. Thomas (interviewt von S. Johann) im Software-Engineering Radio unserer Branche, siehe: https://www.se-radio.net/2015/11/se-radio-episode-242-dave-thomas-on-innovating-legacy-systems/
(Ein kleiner grafischer Überblick ist hier: http://we-press-buttons.blogspot.com/2015/11/thoughts-on-se-radio-episode-242-dave.html)
[Tor18] A. Tornhill, Software Design X-Rays, Pragmatic Programmer, 2018 (Ein pragmatisches Buch über Analyse und Verbesserung von Code, mit Mitteln der Datenanalyse)
[WikiBL] Brooks Law, siehe: https://en.wikipedia.org/wiki/Brooks%27s_law
[WikiLC] Legacy Code, siehe: https://en.wikipedia.org/wiki/Legacy_code
[Zeit19] Leonardo da Vinci: Im Universum des Meisters, in: DIE ZEIT, 2.1.2019, siehe: https://www.zeit.de/2019/02/leonardo-da-vinci-jubilaeumsjahr-literatur-ausstellungen
