This post originated from an RSS feed registered with .NET Buzz
by -.
Original Post: "Alles Neu" ist besser!
Feed Title: Norbert Eder - Living .NET
Feed URL: http://feeds.feedburner.com/NorbertEder-Livingnet
Feed Description: Copyright (c)2005, 2006 by Norbert Eder
Nicht nur kleine Unternehmen oder einzelne Softwareentwickler erwischt es. Nein, auch große Konzerne wie Microsoft. So geistert die Meldung durch das Internet, dass Microsoft die Workflow Foundation von Grund auf neu entwickeln wird. Oder zumindest einen Großteil, so genau kann das wohl niemand mit absoluter Sicherheit sagen. Aber ist das grundsätzlich schlecht?
Die wichtige Frage dabei ist wohl, aus welchem Grund eine Neuentwicklung passiert. Gründe hierfür lassen sich einige finden:
Technologie-Wechsel
Performance-Probleme
Mangelnde Erweiterbarkt
Design-Fehler
Sich veränderte Anforderungen
Dies ist nur als kleiner Auszug aus möglichen Gründen für eine komplette Neuentwicklung einer Software oder eines Frameworks zu sehen. Aber kommen wir zur Frage, wann denn eine neue Implementierung tatsächlich gerechtfertigt ist.
Der Ursprung dieses Gedankens liegt meist darin, dass gewünschte Anforderungen nicht mehr den Wünschen entsprechend umgesetzt werden können, oder aber laufend Probleme auftreten, die nicht in den Griff zu bekommen sind. An dieser Stelle muss nun gegenübergestellt werden, wie es um den Aufwand aussieht, der notwendig ist, diese Probleme in den Griff zu bekommen. In manchen Fällen rechnet es sich durchaus, einen Schritt zurück auf das "Startfeld" zu machen und die Implementierung der gesamten Software, oder der relevanten Teile neu zu beginnen.
Bei einem anstehenden Technologie-Wechsel werden sich einige Fragen nicht stellen. Hier steht der Wunsch (oder der Zwang) im Vordergrund, auf eine neue Technologie zu wechseln. Die Gründe können unterschiedlicher Art sein:
Fehlende Möglichkeiten
Effizienz-Einbußen
usw.
Treten tatsächlich Probleme auf (Performance, mangelnde Erweiterbarkeit), dann ist grundsätzlich Handlungsbedarf immer als dringend anzusehen. Können die Ursachen lokalisiert und dauerhaft gelöst werden (und das mit vertretbarem Aufwand) sollte darin investiert werden. Ist dies nicht der Fall, oder treten zusätzlich eigenartige Verhaltensweisen auf, dann kann durchaus an eine Neuentwicklung gedacht werden.
Auch eine Neuentwicklung bringt so ihre Probleme mit sich. Vor allem, wenn bereits Releases in Umlauf sind. Idealerweise sollten sich Schnittstellen nicht ändern. Bei einem Redesign bzw. einer Neuimplementierung ist dies allerdings nicht immer möglich. Um den neuen Anforderungen gerecht zu werden muss auch die API Neuerungen erfahren. Dies bringt sehr oft eine Inkompatibilität zu vorhergehenden Versionen mit sich. So in einigen Bereichen auch bei der geplanten Workflow Foundation. Damit gewisse Anforderungen erfüllt werden können, muss ein Bruch zur "alten" Version stattfinden. Er ist unvermeidbar. Schlecht für all diejenigen, welche die aktuelle Version einsetzen. Gut für diejenigen, die es schaffen, erfolgreich auf die künftige Version zu migrieren bzw. überhaupt erst mit der neuen Version einsteigen.
Was ich ingesamt damit sagen möchte: Ist von einer Neuentwicklung der eigenen Anwendung die Rede, verfallen die meisten sofort in Panik. Bisheriges kann doch nicht so schlecht sein. Bis jetzt wurden alle Anforderungen erfüllt. Reine Abwehrhaltung. Die Anforderungen ändern sich. Auch die zugrunde liegende Technologie. Irgendwann kommt jedes Produkt an seine Grenze. Idealerweise wird bereits frühzeitig erkannt, wann dies der Fall sein wird. Erhöht sich der Erweiterungsaufwand, wird die Anwendung oder das Framework instabil sollte man auch in diese Richtung denken. Nicht jede Neueentwicklung bedeutet, dass das bisher Geleistete schlecht ist. Man muss agieren um auch zukünftig konkurrenzfähig zu sein/bleiben. Eine Kosten/Nutzen-Rechnung sollte jedoch nicht ausser Augen gelassen werden.
Previous Topic
