nicht angemeldet
Sup!
Ich weiß ja nicht, welchen persönlichen Hintergrund Du hast, aber meiner Erfahrung nach, ist eine Neukonzeptionierung eine durchaus verbreitete Arbeitsweise in der gesamten Technik, und nicht nur dort.
Ok, vielleicht macht es nicht den besten Eindruck, wenn in relativ rascher Abfolge neue Konzepte eingeführt werden, aber besser ist es allemal, als es nicht zu tun, wenn das alte nicht klappt.
Allerdings kann das Erweitern eines Konzeptes ebenso problematisch sein.
Wie auch immern, es spielen oft so viele Faktoren eine Rolle dabei, daß ich mir nicht anmaßen würde, irgend jemanden deswegen zu verurteilen.
Vielleicht denkst Du einmal daran, wenn Du selbst in der Situation stehst, entscheiden zu müssen, ob es nicht doch klüger wäre, vollkommen von vorne zu beginnen.
Jepp. Ich könnte CK jetzt mit ein paar sehr interessanten Theorien des Software Engineering zuposten... mache ich doch glatt:
Also, es gibt verschiedenen Wege der Softwareentwicklung.
Es gibt interessante s.g. Wasserfall- und Whirlpool-modelle, bei denen zwischen verschiedenen Stufen der Anforderungsanalyse, Konzeption, Teilimplementation und Integration sowie Tests herumgesprungen wird. Beim Wasserfall-Modell jeweils eine Stufe zurück, wenn man merkt, daß man Scheisse gebaut hat. Beim Whirlpool-Modell versucht man schon in den ersten Stufen zu gucken, ob die Anforderungen mit dem aktuellen Konzept möglicherweise gar nicht zu erreichen sind.
Wie auch immer, die Folge von zuviel nachdenken und nachbessern ist oftmals der s.g. "feature creep", also ständig steigende Anforderungen, während noch entwickelt wird.
Ausserdem ist nachbessern schlecht für die Qualität der Software, was zu oft umgebaut und gepatcht ist, hat manchmal nur noch die Qualität von einer Software nach 10 Jahren "Wartung".
Gegen den "feature creep" hilft allerdings der "feature freeze". Wenn man natürlich zuende entwickelt, ohne die neuen Anforderungen zu beachten, riskiert man, wenn man fertig ist technisch schon abgehängt zu sein.
Was oft gemacht wird ist "Quick and Dirty" programmieren - Vorteil: Schnell. Mit etwas Glück kann man das auch als "Rapid Application Development" ausgeben.
Gerade bei nicht ganz so komplexen Projekten wie einem Paketfilter halte ich das Konzept des von-Grund-auf-neu-Programmierens für ziemlich gelungen, weil so Unzulänglichkeiten am besten beseitigt werden können. Bei einer zeitkritischen Anwendung wie einem Paketfilter sind IMHO auch irgendwelche Bemühungen, die bei einem großen Projekt sinnvol wären, das ganze intern zu modularisieren und eventuell objektorientiert mit Schnittstellen zu versehen, fehl am Platze.
Gruesse,
Bio