Was haben Software-Archäologie und Jurassic Park gemeinsam?
Auch Software kann altern. Besser gesagt: Software altert, wenn auch nicht im biologischen Sinne. Und so ungewöhnlich es klingen mag, weist dieser Prozess doch einige Parallelen zur prähistorischen Ära der Dinosaurier auf. Du fragst dich jetzt: „Dinosaurier, ja okay. Aber warum ausgerechnet Jurassic Park?“ Ganz einfach: Weil ich ein großer Fan davon bin.
Bei BettercallPaul machen wir beides: Wir entwickeln neue Software und wir sorgen dafür, dass alte Software letztlich wieder neu ist. Grundlage für Letzteres ist, dass Software altert. Woran das liegt? Dafür kann es unterschiedliche Gründe geben. Denn oftmals haben wir wechselnde Teams oder Dienstleister und mit jedem Wechsel gehen möglicherweise Wechsel der Architektur einher. Es kann zudem passieren, dass Refactorings nicht zu Ende geführt werden, weil der eine Dienstleister startet und ein anderer übernimmt, dann aber meint: „Das ist alles Mist – wir machen das anders.“ Und schon ändert sich wieder alles. Außerdem gibt es häufig ein Ungleichgewicht zwischen den Anforderer:innen und den Entwickler:innen. Mal ist die eine Seite stärker, mal die andere – und manchmal kommen beide auf nicht so gute Ideen. Die Ergebnisse können dann in der Software wiedergefunden werden. Ein weiterer Punkt sind alte Frameworks oder Bibliotheken, die nicht immer aktuell gehalten werden und irgendwann ausgetauscht, aktualisiert oder durch neue Versionen ersetzt werden müssen. Des Weiteren gibt es in fast allen Software-Projekten gewisse „Ecken“, an die sich niemand herantraut und die keiner anfassen möchte, weil dabei doch so viel kaputt gehen könne. Ich nenne dieses Phänomen emotionale Hürden. Ein letzter Punkt ist die Attraktivität neuer Software. Denn diese ist für viele Entwickler:innen meist interessanter als alte Software. Der Hype zieht die Aufmerksamkeit.
Da jetzt klar ist, wie oder warum Software alt wird, blicken wir nun auf die Dinosaurier. Diese wurden nämlich 170 Millionen Jahre alt und letztlich segnete für sie ein Meteorit das Zeitliche. Dieser hinterließ in Mexiko einen Krater von 180 Kilometern Durchmesser, von dem aktuell nur noch die Ränder zu sehen sind. Von den Dinosauriern sind heute nur noch versteinerte Knochen übrig. Nicht jedoch bei Jurassic Park. Dort waren in kleinen Bernsteinen Mücken eingeschlossen, in denen das But der Dinosaurier versteinert war. Den Stein haben sie schließlich aufgebohrt, das Blut herausgezogen und die DNA der Dinosaurierer sozusagen wiederbelebt. Das Ziel war Leben zu schaffen, was wir auch so von der Software-Archäologie behaupten können. Alte Software soll erneuert oder eben wiederbelebt werden.
Dinogroße Software
Das klingt im ersten Moment aber einfacher als es letztlich ist. Denn manchmal starten wir in ein Projekt, das 500.000 Codes of Line beinhaltet. Bei dieser Größe kann es einem schon mal so vorkommen, als stünde ein riesiger Giraffatitan direkt vor einem – mit 13,27 Metern ist er das bis heute größte montierte Dinosaurierskelett der Welt, ausgestellt im Berliner Museum (und eine absolute Besuchsempfehlung meinerseits). So groß und faszinierend die Dinos damals waren, ist es ebenso faszinierend für mich, wie groß Software ist. Denn was machen wir jetzt mit dieser Menge an Codes of Line? Genau, das Gleiche, was sie bei Jurassic Park gemacht haben. Sie haben in den Bernstein hineingebohrt und die DNA herausgeholt, in unserem Fall die Essenz der Software. Für mich in meiner Rolle ist das die fachliche Logik, die in der Software steht.
Für die Erhebung dieser gibt es mehrere Methoden. Für mich ist die beste Methodik, sich einfach mal neben die User zu setzen und zu schauen, was sie eigentlich den ganzen Tag machen. Dadurch sehen wir, was wirklich wichtig ist. Denn manche Buttons oder Anwendungen werden nie genutzt, stecken aber immer noch in der Software. Ist das der Fall, kommt meine Lieblingsaufgabe: Alles, was nicht gebraucht wird, schmeiße ich einfach weg. Wir schneiden sozusagen den Bernstein außen Stück für Stück ab und finden innendrin dann die DNA. Und haben wir uns erst mal dieser Thematik Stück für Stück genähert und verstehen, was eigentlich gemacht wird und was notwendig ist, wirken die 500.000 Codes of Line gar nicht mehr so groß. Wenn wir die Software besser verstehen, können wir zudem nachvollziehen, wie der:die Programmierer:in der Software gedacht hat. Daraus und aus Fehlern, die gemacht wurden, können wir lernen und es letztlich besser machen.
Wir erwecken etwas zum Leben…
Nun wissen wir, was die Software macht, wissen jedoch noch nicht, wie wir sie renovieren können. Hier gibt es verschiedene Vorgehensweisen. Die einfachste wäre, die Software zu teilen, indem wir sie in der Mitte durchschneiden. Dafür müssen wir aber wissen, wo wir genau schneiden müssen, was wiederum nicht ganz leicht ist. Eine andere Vorgehensweise ist, die Software wegzuwerfen und sie komplett neu zu erschaffen. Dafür benötigen wir aber die DNA, denn sonst können sämtliche Fehler aus den Jahren der Abhärtung zuvor erneut gemacht werden. Deshalb: Immer erst in den Quellcode schauen!
Am härtesten ist die Wiederbelebung. Hierbei nehmen wir die Software, so wie sie ist, und versuchen, sie inkrementell zu einem besseren Modell zu gestalten. Auch hier unterteilen wir in unterschiedliche Vorgehensweisen. Grundlegend können wir beispielsweise Inside-Out oder Outside-In vorgehen. Wenn es ein größerer Prozess ist, können wir über die Domäne vorgehen, sie erst einmal verstehen und dann teilen. Das muss aber gut mit dem Kunden kommuniziert werden, denn wenn es eine wichtige Software ist, die instabil ist, kann das zu Folgeproblemen führen. Wenn zunächst die eine Domäne aufgeräumt wird, in der anderen aber ein Fehler auftritt, können wir klarstellen, dass dort noch nicht aufgeräumt wurde. Meist wächst dann die Verantwortung über die Software inkrementell. Ein weiterer Bereich, an dem man ansetzen kann, sind noch verwendete alte CI/CD-Systeme. Zwar gibt es in der Mitte eine Blackbox, die wir noch nicht verstehen, aber die Pipelines sind dann moderner und Altlasten dort können früh aufgelöst werden. Das geht allerdings nur sehr einfach, wenn wir möglichst wenige Programmiersprachen haben, da diese sonst die Komplexität des Build erhöhen. Das Deployment ist ebenfalls ein Punkt, an dem wir ansetzen, es aufräumen und es auf eine neuere Version aufsetzen können. Meine letzte Vorgehensweise, über den Anwendungskern, ist jedoch ausschließlich möglich, wenn wir die Fachlichkeit verstehen.
Letztlich kommt es auf den Anwendungsfall und die persönlichen Präferenzen an, welche Vorgehensweise gewählt wird, mit der wir die Software wiederbeleben. Es ist ähnlich wie bei Jurassic Park, nachdem sie sich für die Vorgehensweise der Wiederbelebung der DNA entschieden hatten und der Paläontologe ganz überrascht ist, als der Velociraptor aus dem Ei schlüpft. Nur sollten wir eben vom Endergebnis der Software dann nicht überrascht sein.
