Ein Rewrite, also das völlige Neu-Schreiben eines Software-Systems sind immer eine heikle Angelegenheit. Über den Newsletter von Holger Frohloff bin ich auf einige faszinierende Beispiele dazu gestoßen. Holger war bei zwei Rewrites selbst dabei, und er verweist auf einen längeren sehr lesenswerten Artikel

Herb Caudill: Lessons from 6 software rewrite stories

Holger Frohloff schreibt darüber, wie man Software-Qualität verbessern kann, da ist das komplette Neu-Schreiben natürlich eine sehr radikale Maßnahme. Wie die zitierten Beispiele zeigen, ist das Risiko erheblich. Es dauert immer länger als man denkt–unter anderem weil die alte Version parallel weiterentwickelt wird, so dass der Neubau manchmal nie aufholt. Außerdem ist der Business Value vordergründig Null, wenn man nicht noch parallel neue Features einbaut. Weil diese Rewrites immer Großprojekte sind, sind sie schwer zu schätzen–da hilft es leider auch nicht, dass wir genau wissen, was der Neubau können soll. Auch macht man sie so selten (wenn überhaupt, vielleicht alle 7 Jahre?), dass man kaum Erfahrungen aus erster Hand sammeln kann.

Teil unserer Philosophie bei SoftwareLiefern.de ist es, große Sprünge in’s Ungewisse zu vermeiden bzw. durch viele kleine Schritte zu ersetzen. Wie wäre es also, wenn wir Systeme so bauen, dass ein kompletter Rewrite nicht nötig ist? Oder so, dass das Neu-Schreiben keine große Sache ist, weil es stückweise erfolgen kann?

Wenn ein System hinreichend modular ist, kann es auch modulweise modernisiert werden. Ich denke da etwa an das Betriebssystem Linux (Unix). Die einzelnen Kommandos sind kleine Programme, die überschaubare Aufgaben lösen (sort: eine Datei zeilenweise sortieren, more: eine Datei anzeigen usw.). Wenn eines dieser Kommandos neu geschrieben werden müsste, wäre das mit relativ wenig Aufwand verbunden, und der Rest des Systems bliebe davon unberührt. Das Verhalten der Kommandos ist im Unix Manual dokumentiert, so dass eine gute Spezifikation vorhanden wäre.

Ähnlich ist es für ein System, das in Microservice-Architektur gebaut ist. Ein einzelner Microservice ist so klein, dass er relativ schnell z.B. in einer anderen Programmiersprache neu geschrieben werden könnte. Microservices haben eine gut definierte Schnittstelle zum Rest der Welt, so dass es keine bösen Überraschungen beim Neu-Implementieren geben dürfte.

Und zu guter Letzt: das Internet muss nicht neu geschrieben werden. Die Schnittstellen (Protokolle) sind klar definiert, man könnte sogar sagen, dass die Schnittstellen den stabilen Kern des Internets ausmachen. Zum Beispiel regeln die TCP/IP Protokolle, wie Datenpakete von A nach B geschickt werden. Solange ein Internet-Knoten sich an die Protokolle hält, spielt es keine Rolle, ob er ein Linux-Server, ein Android-Handy oder ein Windows NT PC von 1996 ist. Die “Modernisierung” kann also kontinuierlich passieren, ohne dass es größere Störungen gibt.

Matthias Berth