Zustandsforschung

Ich habe hier zwei Artikel gefunden, die sich mit dem Problem beschäftigen, ein komplexes Softwaresystem sozusagen “nachzubauen”. Der Artikel “To rewrite or not to rewrite, that is the question” führt ein paar Fragen an, anhand denen man entscheiden können soll, ob es machbar ist, das System neu zu schreiben.

Chad Fowler schreibt in seiner Artikelserie “The Big Rewrite” darüber, welche Probleme während eines solchen Projektes dieses zum Scheitern bringen können:

Beware. This is a longer, harder, more failure-prone path than you expect.

Bei Joel on Software heißt der Artikel zu dem Thema bezeichnenderweise “Things You Should Never Do“. Er nimmt dabei unter anderem Netscape und deren Browser als Beispiel dafür, was passieren kann, wenn man sich für den “Big Rewrite” entscheidet. Wo das damals hingeführt hat, weiß man ja. Die sind jetzt zwar bei Version 9 ihres Browsers, den will aber keiner mehr haben.

Als Resumee geht aus allen Artikeln eines hervor: Wenn man es irgendwie vermeiden kann, dann sollte man nicht versuchen, ein bestehendes Softwaresystem neu zu schreiben.

Nachdem ich im Moment ja selber in einem solchen Projekt drinstecke, das sich “Technische Migration” nennt – ein Euphemismus für “wir schreiben’s nochmal neu” – kann ich den in den Artikeln angeführten Argumenten ausnahmslos zustimmen. Mir ist natürlich klar, dass es oft nicht so einfach ist, zu Entscheiden beim alten System zu bleiben. Allerdings sollte man sich vorher auf jeden Fall im klaren darüber sein, was es bedeutet ein über Jahre gewachsenes System nachzubauen.