Ihre Entwickler arbeiten in unserer Niederlassung in Indien

Sollte man bestehende Software von Grund auf neu schreiben?

Sollte man bestehende Software von Grund auf neu schreiben?

Wer in der Softwareentwicklung tätig ist, kennt die Aussage: “Die Software ist zu langsam und nicht skalierbar. Es wäre besser das Ganze von Grund auf neu zu programmieren. Damit haben wir dann eine bessere Ausgangsbasis.”

Viele Projekte werden von Grund auf neu geschrieben, um für die “Zukunft” gewappnet zu sein.

Die Frage ist jedoch, ob es Sinn mach, alles neu zu machen, und bestehende Programierungen wegzuwerfen.

Meiner Meinung ist das keine ideale Lösung. Die Gründe dafür sind im weiteren beschrieben.

Bug Fixes enthalten

Alte Software hat immer den Vorteil, dass es bereits durch mehrere Personen, getestet wurde. Sei es von internen, externen Testers oder von Nutzern, Projektmanagern und vielen weiteren Personen.

Mit den Wochen, Monaten und Jahren sind dann sehr viele Bug Fixes, von den Entwicklern, enigebaut worrden. Wobei Bug Fixes, Behebungen von Fehlern sind, welche bereits im System vorhanden waren.

Zum Beispiel fällt der Testerin/ Tester auf, dass die Webanwendung auf bestimmten Browsern sehr langsam läuft. Hier wird sie mit ihrem zugeordneten Tester sprechen und schauen, welche Massnahmen getroffen werden können.

Üblicherweise wird der Entwickler sich nun an die Aufgabe setzen und eine Fehlerbehebung (Bug fix) programmieren.

Im Laufe der Jahre werden den Nutzern der Software viele kleinere Fehler auffallen. Zum Beispiel, dass wenn eine bestimmte Tastenkombination genutzt wird, das Program abstürzt. Diese Schwachstellen können nur im Zeitverlauf gefunden werden. Meistens werden diese Schwachstellen, dem Entwickler oder den Testern (auf Entwickler- und auf Kundenseite) nicht auffallen.

Daher sieht man auch immer wieder Updates, welche bei Microsoft Windows, die beim Neustart eingespielt werden. Meistens handelt es sich um Fehlerbehebungen im Code.

Über die Jahre hinweg entsteht somit eine robuste Anwendung.

Unlesbarkeit durch neue Entwickler

Die grosse Problematik entsteht meistens, wenn sich neue Entwickler mit dem existierenden Code, welcher von anderen Programmierern erstellt wurde, beschäftigen müssen.

Für diese erscheint der alte Code, wie der reinste Spagetti Code. Meistens wird es lange Funktionen geben oder Schnittstellen, welche sinnlos erscheinen.

Doch in den meisten Fällen handelt es sich hierbei um die im ersten Abschnitt umschriebenen Bug Fixes, welche über die Jahre hinweg hinzugefügt wurden.

Diese Erkenntnis wird dem Entwickler in den meisten Fällen nicht kommen und er oder sie wird eine komplette Neuprogrammierung vorschlagen. Argumente wie “Der derzeitige Code ist ein komplettes Durcheinander”, “Der Code ist viel zu ineffizient und nicht zukunftsgerecht”, “Das System ist viel zu langsam”, und noch viele mehr werden genannt.

Auch für die Budgetverantwortlichen werden diese Argumente plausibel erscheinen. In den meisten Fällen war man dann doch nicht zu Hundert Prozent zufrieden mit den Leistungen des vorherigen Programmierers und “hat sich das ja schon gedacht, dass die Arbeiten des früheren Entwicklers, dann doch nicht so top waren”.

Was jedoch übersehen wird, ist, wie schon vorher angesprochen, dass die Software über die Jahre hinweg von den Nutzern und anderen Gruppen genutzt, Fehler gefunden und behoben wurden.

Beispiel Netscape

Netscape war über Jahre hinweg der Nummer eins Browser-Anbieter. Zu Bestzeiten hatte die Browserapplikation mehr als 80 Prozent Marktanteil.

Zirka im Jahr 1997 entschied man sich, die komplette Code-Basis von Grund auf neu zu programmieren. Der alte Code wurde daher komplett vernachlässigt und es wurde an diesem nicht mehr weitergearbeitet. Ungefähr im Jahr 2000 kam dann die neue Version auf den Markt. Im Jahr 2003 hatte Netscape dann nur noch wenige Prozent Marktanteil und hatte das Wettrennen mit dem Internet Explorer von Windows komplett verloren.

Eine grosse Fehlentscheidung von Netscape, welche auch von vielen anderen Softwareunternehmen gemacht wurde.

Manche Unternehmen waren jedoch so schlau, die alte Code-Basis nicht komplett aufzugeben, sondern haben auch daran parallel weiterentwickeln. Dadurch konnten sie, falls es mit der neuen Version nicht klappte, mit dem alten Code weiter arbeiten.

Wie Joel Spolsky in seinem Blog richtig schreibt 
“It’s harder to read code than to write it.” 
Dies bedeutet im Grund genommen, dass es für einen Entwickler 
immer einfacher ist, seinen eigenen Code zu lesen, als den 
von jemandem anders.

Eigene Erfahrungen

Aus meiner eigenen Erfahrung sind Neu-Programmierungen in den meisten Fällen nicht notwendig. Im Idealfall besteht eine ausführliche Dokumentation zu der Software. Dann sind die meisten Funktionen in diesem Dokument beschrieben.

Fehlt solch ein Dokument, dann wird es schon um ein vielfaches schwerer. Denn die Entwickler werden mehr Zeit benötigen, um auch einfache Dinge im Programm zu verstehen.

Besonders auf Projektbasis, wird die Rechnung mit der kompletten Neu-Programmierung nicht aufgehen. Bei solchen Vorhaben braucht es einiges an Flexibilität des Auftraggebers (sei es ein externer Auftraggeber oder die interne IT Abteilung).

Der bessere Weg

Die bessere Lösung ist es, an dem alten Code weiterzuarbeiten. Wenn man merkt, dass einige Stellen, nicht performant sind, dann kann man diese studieren und dann peu a peu ausbessern.

Fazit

Durch eine Neuprogrammierung von bestehendem Code, kann man seine, über die Jahre hinweg, gewonnen Erkenntnisse verlieren und gibt so seinen Wettbewerbsvorteil auf.

“Jahre” sind besonders in der Softwareentwicklung eine Ewigkeit, wenn man bedenkt, wie schnell sich die ganze IT Landschaft in den letzten Jahren verändert hat.

Wenn ganz neue Plattformen, wie zum Beispiel die Mobilen Betriebssysteme (Android, iOS) entstehen, dann kommt man wahrscheinlich nicht drum herum, die Software für diese Plattformen neu zu schreiben. Anders sollte es jedoch für Plattformen sein, welche sich nicht grundlegend geändert haben.

Besonders in der Softwareentwicklung gibt es immer Wege und Mittel bestehende Lösungen, umzubauen, so dass sie den aktuellen Anforderungen gerecht werden.

Welche Erfahrungen habt Ihr gemacht? Wie würdet Ihr Euch entscheiden?

Bilder: Flickr.com/ Whitehouse/ Regan/ Tait


Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.

2 Kommentare
  1. Ich arbeite für grosse Projekte und schreibe meines Teile neu, so wird der Code mit der Zeit mit neuen Ideen erneuert ohne den alten Teil zu gefährden.

  2. 2014 haben wir unser Konzept der Softwareentwicklung geändert. Grund war, dass wir einfach nicht mehr wirtschaftlich die bestehende Software-Lösung (Rechnungsplattform) an die ständigen Änderungen anpassen konnten. Wir wollten natürlich die reiche Erfahrung aus der bisherigen Software weiter nutzen aber in Zukunft schneller und mit bester Qualität an Vorgaben unsere Anwender anpassen können. Unsere Anforderungen waren:
    – Die Anwender sollten Änderungen weitestgehend selbst, ohne Programmierkenntnisse, durchführen können
    – Notwendige Programmierung sollte outgesourct werden können, ohne dem externen Programmierer immer das gesamte Modul erklären zu müssen
    – Softwarefunktionen und Änderungen sollten dem Wirtschaftsprüfer verständlich dokumentiert werden
    – Funktionen sollten einfach in anderen Modulen wiederverwendbar sein

    Für die Wirtschaftsprüfer unserer Kunden haben wir sowieso die Funktionen unserer Rechnungsplattform als BPMN 2.0 Modell zur Verfügung gestellt. Wir mussten eigentlich „nur“ das betriebswirtschaftliche Modell technisch in einer Business Process Engine ausführen lassen. Einen Prozess haben wir als Piloten ausgesucht. Die alten Programme und ihre Algorithmen technisch in Aufgaben (Tasks) modelliert und in Java neu programmiert. Sobald der Prozess umgeschrieben war haben wir ihn parallel zu der bisherigen Lösung getestet und optimiert. Der Pilot hat unsere Erwartungen weit übertroffen. Aus den dabei gewonnen Erfahrungen haben wir noch einmal unser Softwareentwicklungsparadigma geändert. Unsere neuen Anforderungen waren diesmal konkreter:
    – Bereits programmierten Task sollten für die weitere Nutzung in einem Repository gefunden werden
    – Bewährte, von Wirtschaftsprüfern geprüfte Geschäftsprozesse, sollten für Jedermann in einem Repository gefunden werden und einfach im eigenen Unternehmen eingesetzt werden können
    – Die Task sollten sich selbst in neue Prozesse integrieren können. Sodass Prozessverantwortliche ihre Prozesse aus dem Repository weitestgehend selbst zusammenstellen können
    – Jeder Task erhält Komponenten für KPI und Leistungsabrechnung

    Was ich sagen wollte, mit diesem System stellt sich nicht mehr die Frage: „Sollte man bestehende Software von Grund auf neu schreiben?“ Das inkrementelle Vorgehensmodell auf Basis einer BP-Engine erspart uns den klassischen Aufwand für die Fehlerbehebung, Anpassung und Verbesserung unserer Softwarelösung.

Schreibe einen Kommentar

Adresse

YUHIRO Entwicklungszentrum
Thattil Nadakalan Complex
(Opp. Church) Kuriachira
Thrissur, Kerala - 680006, Indien
Phone: +91 9846861166
Webseite: www.yuhiro.de
Email: info@yuhiro.de

YUHIRO

Wir arbeiten eng mit Ihnen zusammen um Ihre Anforderungen zu verstehen und daraufhin den richtigen Softwareentwickler für Sie zu finden und bereitzustellen.