Verwaister und undokumentierter Bestandscode - was tun?

[Xzeer]

Hallo zusammen,

ich wende mich an euch, da mich die Meinung von anderen Entwicklern interessiert.

Ich bin Anfang des Jahres in eine neue Firma gewechselt, um dort an der Weiterentwicklung der vorhandenen Lösung mitzuarbeiten. Zu dem Zeitpunkt waren wir primär zu zweit in der .NET Entwicklung. Der vorhandene Entwickler hat das Frontend über ~10 Jahre mehr oder weniger in Einzelarbeit entwickelt.

Die Firma ist zur Jahresmitte von einer anderen Firma übernommen worden und in diesem Zug ist dieser Entwickler kurz darauf und ziemlich kurzfristig zu einer anderen Firma gewechselt.

Ich habe also den kompletten Bestandscode geerbt. Dieser Code ist ein wilder Mix aus verschiedenen Ansätzen und Konstrukten: Code-behind, MVVM, Databinding, Events, Commands... Nichts ist wirklich einheitlich durchgezogen worden. Hinzu kommen natürlich eigene Strukturen, die irgendeinen Sinn erfüllen, aber nirgends dokumentiert wurden. Zum Frontend gehört auch noch ein Sammelsurium aus Exe-Datei Tools und PowerShell Scripts, die an verschiedenen Stellen aufgerufen werden. Insgesamt also eine recht hohe Komplexität. Ich habe überhaupt keine Dokumentation und es gibt eigentlich keine Person im Unternehmen, die Details zur Architektur wirklich kennt.

Ich rede übrigens nur vom Frontend. Im Backend sieht die Situation besser aus.

Jetzt sollen neue Funktionen in das Produkt eingebaut werden. In mir sträubt sich aber alles, weiter an diesem fremden Durcheinander weiterzuentwickeln. Es geht so viel Zeit für Reverse-Engineering drauf und teilweise weiß ich gar nicht, wo ich anfangen soll, etwas hinzuzufügen oder zu verbessern. Insgesamt frustrierend.

Noch kurz zu meiner Person. Ich bin noch relativ jung im Geschäft. Seit fast 2 Jahren aus der Ausbildung. Ich würde aber behaupten, dass ich als Entwickler grundlegend vernünftige Ergebnisse abliefern kann und nicht auf den Kopf gefallen bin.

In dieser Sache bin ich mir aber echt unsicher, auf welches Vorgehen ich in Meetings mit Kollegen plädieren soll. Ich würde ja am liebsten meine Energie in etwas neues, solides und besseres investieren, als in das alte Zeug. Langjährige Kollegen hängen aber natürlich an genau diesem Konstrukt, so wie es funktioniert und aussieht. (Die müssen die neuen Funktionen aber auch nicht einbauen) Erneuern würde natürlich einen Haufen Arbeit bedeuten. Jedoch glaube ich, dass es mindestens genauso viel Arbeit ist, den vorhanden Code zu verbessern (wenn das überhaupt vernünftig funktioniert) ...

Ich verstehe natürlich, dass man aus der Ferne schwierig eine fachliche Einschätzung vornehmen kann, aber was würdet ihr machen? Hat jemand schon mal eine ähnliche Situation gehabt?

Ich würde mich über Reaktionen sehr freuen. :)

[TiGü]

Nur um sicher zu gehen und die Option abzuhaken:
Du willst dort bleiben oder wäre eine neue Arbeitsstelle eine mögliche Lösung?

Bist du jetzt der einzige Softwareentwickler im Unternehmen?

[stahli]

Mit welchen Sprachen und Frameworks sind denn Frontend und Backend erstellt? Desktopanwendung oder Client/Server?

[Stevie]

Besorg dir und studier dieses Buch: Working Effectively with Legacy Code

[Xzeer]

Also eigentlich würde ich schon gerne bleiben. Weil das Produkt an sich und die Branche spannend ist.
Ich bin neben einem weiteren iOS Entwickler aktuell der einzige Kern-Entwickler im Team.

Das Frontend ist eine .NET WPF Applikation in Teilen auf Basis von Prism. Das Backend ist ein .NET WCF SOAP Service. Sowohl im Frontend, als auch im Backend gibt es noch diverese EXE-Tools und PowerShell Scripte, die immer dann verwendet wurden, wenn Teile der Logik beim/für den Kunden angepasst werden soll/sollte. Die primäre Sprache ist C#.

EDIT:
Danke für die Buchempfehlung. Das sieht echt gut aus.

[Uwe Raabe]

Zitat:

Zitat von Xzeer (Beitrag 1387904)

Ich habe also den kompletten Bestandscode geerbt.
...
Ich habe überhaupt keine Dokumentation und es gibt eigentlich keine Person im Unternehmen, die Details zur Architektur wirklich kennt.

Willkommen im Club!

Zitat:

Zitat von Xzeer (Beitrag 1387904)

In mir sträubt sich aber alles, weiter an diesem fremden Durcheinander weiterzuentwickeln.
...
Jedoch glaube ich, dass es mindestens genauso viel Arbeit ist, den vorhanden Code zu verbessern (wenn das überhaupt vernünftig funktioniert)

Das ist häufig der Standardreflex eines Entwicklers in dieser Situation.

Unterschätze den Aufwand einer Neuentwicklung nicht! In den meisten Fällen ist die einzige Dokumentation für die erforderliche Funktionalität das bestehende Programm selbst und damit auch der vorhandene Source-Code. Willst du diese Funktionalität vollständig neu entwickeln, kommst du um ein tiefes Verständnis des Programms und dessen Sourcen vermutlich nicht herum.

Solltest du nicht auch den Weg des gegangenen Entwicklers einschlagen wollen, dann empfehle ich dir dringend dich mit dem Source-Code und der Architektur auseinanderzusetzen. Nur dann hast du überhaupt die Chance abzuschätzen, wie hoch der Aufwand für eine Neuentwicklung wohl sein könnte, und nur dann hast du auch die nötige Argumentationsgrundlage deinen diesbezüglichen Vorschlag bei der Geschäftsleitung zu unterstützen. Die Erfahrung zeigt allerdings, daß ein schrittweises Erweitern und Refactoring leichter und effizienter umzusetzen ist als eine komplette Neuentwicklung.

Aus Sicht der Geschäftsleitung bedeutet deine Forderung nach einer Neuentwicklung doch nichts anderes als daß das bestehende System mit dir als Entwickler wertlos ist und die gesamten bisherigen Entwicklungskosten verloren sind (und womöglich nochmal vergleichbar hohe auf sie zukommen). Welcher Entwickler hätte demnach für die Firma einen höheren Wert: derjenige, der den alten Code wegwirft oder derjenige, der den alten Code weiterentwickelt?

[hoika]

Hallo,
die richtige Buchempfehlung hast Du ja bereits ;)

Ich würde das Problem bei den Sitzungen genau so ansprechen (keine anständige Doku, undurchsichtige Workflows)

Ist das Projekt wenigstens in einem Versions-Management-System eingecheckt?

Ach ja:
Willkommen im Club.
Wobei es bei mir nicht so schlimm war.

[mensch72]

sicher nicht schön, aber sieh es positiv:
"Ich rede übrigens nur vom Frontend. Im Backend sieht die Situation besser aus."... das ist doch super, also ist Backend doch dut dokumentiert... Also sind Schnittstellen,Daten und Funktionen auf dieser Seite klar, und somit ist indirekt ja auch klar, was das Frontend bekommt/liefert(egal "wie" es das macht)

Letzendlich willst du ein neues Frontend anfangen, wenn du da nur Argumente ala "der aktuelle Code ist Mist und nicht dokumentiert" bringst, kommt das nicht gut wenn du es 2Jahre ausgelernt hast, denn du kannst aktuell ja nicht beweisen das du nach eigenem Konzept und soviele Jahre es "besser" kannst.

Also biete an, einen Teilbereich des Frontends mit was aktuellem sauber neu zu machen, was optimaler Weise trotz zunächst gleicher Funktion einen für Dritte erkennbaren Mehrwert hat... also z.B. realisiere das Frontend als WebInterface, oder realisiere das Frontend auf anderer Platform (z.B. für Mobile oder Mac).

Wenn das gut ankommt, dann bekommst du im Optimalfall StepByStep die Zeit weitere Frontendfunktionen so umzusetzen und auch die passenden Tools zu erstellen.
Sieh die Tatsache das alter Quellcode weil/trotz nicht Standardkonform ist und vieles da undokumentiert mehr für dich als Möglichkeit da an Erfahrung zu gewinnen, sich in fremden Code auch im Blackbox Verfahren funktional einzuarbeiten... sowas lernst du in keiner Schule, aber es wird dir in der Realität oft weiter helfen, denn "irgendwelchen" fremden Code mit "irgendwie" mit eigenen zu verbinden sollte man "auch können", das Gefühl was sich zeitlich lohnt entwickelt sich da nur durch Versuch und Irrtum:)

[himitsu]

Zitat:

und nicht dokumentiert

Nja, du wirst bestimmt auch nicht alles perfekt dokumentieren, wenn du es neu machst und in paar Jahren dann jemand anderes deinen Code sieht und das Selbe sagt. :zwinker:

Altcode dokumentieren (kürzer)
Neucode scheiben, vorher perfekt planen und alles dokumentieren (länger)

[Xzeer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1387910)

Die Erfahrung zeigt allerdings, daß ein schrittweises Erweitern und Refactoring leichter und effizienter umzusetzen ist als eine komplette Neuentwicklung.
...
Welcher Entwickler hätte demnach für die Firma einen höheren Wert: derjenige, der den alten Code wegwirft oder derjenige, der den alten Code weiterentwickelt?

Danke für die ausführliche Antwort.
Das klingt auf jeden Fall nachvollziehbar und logisch.

Mir fehlen nur aktuell gute Ansätze einen solchen schrittweisen Umbau vorzunehmen, weil vieles voneinader abhängt. Wenn ich versuche nur einen bestimmten Teil zu erneuern, passiert es schnell, dass ich viele abhängige Stellen im Code ebenfalls anfassen muss. Das grenzt dann ja fast an Neuentwicklung.

Mir fehlt da natürlich auch einfach Erfahrung. Ich habe noch kein Programm einfach mal von links nach rechts gekrempelt.

Ich werde mir auf jeden Fall mal das Buch zulegen. Ein paar der im Inhaltsverzeichnis erwähnten Problematiken habe ich eindeutig.

Zitat:

Zitat von mensch72 (Beitrag 1387915)

Also biete an, einen Teilbereich des Frontends mit was aktuellem sauber neu zu machen, was optimaler Weise trotz zunächst gleicher Funktion einen für Dritte erkennbaren Mehrwert hat... also z.B. realisiere das Frontend als WebInterface, oder realisiere das Frontend auf anderer Platform (z.B. für Mobile oder Mac).

Da wäre ich sofort Feuer und Flamme. :wink:
Das Problem ist ja nicht, dass man mich nicht lassen machen möchte oder es mir nicht zutraut.
Das Problem ist, dass es ein daily business gibt und wie erwähnt, nur meine Ressource.
Es geht mehr um die Entscheidung was sinnvoller/schneller/wirtschaftlicher ist. Eine Neuentwicklung beginnen oder die bestehenden Struckturen anpassen.

Zitat:

Zitat von mensch72 (Beitrag 1387915)

[...] aber es wird dir in der Realität oft weiter helfen, denn "irgendwelchen" fremden Code mit "irgendwie" mit eigenen zu verbinden sollte man "auch können", das Gefühl was sich zeitlich lohnt entwickelt sich da nur durch Versuch und Irrtum:)

Das finde ich persönlich etwas kurz gedacht. Natürlich kann ich irgendwie und auf Biegen und Brechen neue Funktionen in den Bestandscode bringen. Aber genau das möchte ich ja nicht. Ich möchte ja nicht unsauber weiterarbeiten und alles noch schlimmer machen, sondern etwas verbessern.

[4dk2]

zum einen, will das jetzt nicht auf dich beziehen, aber was ich damals 2 Jahre nach Ausbildung also Optimalen Code empfunden habe, hat sich zum Stand heute auch noch stark verändert ;)

Dann zu legacy Code.
Hab schon so manche Adaptierungen von früheren Kollegen gesehen die so aussahen:

Delphi-Quellcode:

...
begin
  ...
  //Ab hier startet das Chaos, viel Spass beim debuggen ;)
  FormX.Start();
  ....
end;

[mensch72]

..."Das Problem ist, dass es ein daily business gibt und wie erwähnt, nur meine Ressource.
Es geht mehr um die Entscheidung was sinnvoller/schneller/wirtschaftlicher ist. Eine Neuentwicklung beginnen oder die bestehenden Struckturen anpassen."...

Solange altes aktuell "noch richtig" funktioniert, ist es wirtschaftlich sinnvoll das zunächst weiter zu nutzen und zu verkaufen, denn davon lebt ihr.
Wenn ihr im altem echte BreakingErrors habt, und die nicht in Zeit X im Altsource gefunden&behoben werden, dann muss da intern oder extern ein Ersatz her.
Wenn man nich alles selbst neu machen kann, baut man Schnittstellen zu anderen fast imer irgendwie findbaren Zukaufmodulen, welche man im Hintergrund als Ersatz einbindet.

..."neue Funktionen in den Bestandscode bringen. Aber genau das möchte ich ja nicht. Ich möchte ja nicht unsauber weiterarbeiten und alles noch schlimmer machen, sondern etwas verbessern."...
- wenn eure Kunden und dein Chef dich fürs "will verbessern" bezahlt, dann ist das toll... Die meisten Kunden und Chefs verlangen und zahlen aber nach realisierter Funktionalität, und das in Zeit X.
Ich würde oft auch gerne alles aus einem Guß mit einheitlicher CodeStruktur haben, aber die Zeit gibt es zumeist nicht her. Mein einziger Vorteil mit 25 Arbeitsjahren in dem Gebiet... ich habe erstens schon viel gesehen, zweitens selbst schon viel gemacht und drittens mittlerweile Erfahrung wie Copy&Paste "sinnvoll" eingestezt zwar keinen einheitlichen Code ergbit, aber doch oft recht fix zumindest gut modularisierten Quelltext... den Ergeiz alles wie man es selbst mag zu verändern(also z.B. Variablen & Methoden Namen) habe ich bald sein lassen, denn wenn meine Copy&Paste Quelle der Basissource nach altem Namensschema weitergemacht hat, musste ich bei Übernahme der neunen Variante stets wieder alles umbenennen.(es gibt unter Kollegem böses Blut, wenn einer meint "seine" Variante ist die "schönste/beste")

Wenn etwas für mich garnicht geht, dann schreibe ich mir einen Funktionalen oder Objektorientierten Wrapper, da kann ich alles benennen und vor/nach Prüfen wie ich es für nötig halte.

Aber trotzdem ganz pragmatisch:
- im "daily business" für Geld programmiere ich nach Vorgabe auf Ziel mit dazu nötigter Funktions und Code Dokumentation
- wenn man Glück hat, wird ein vorheriges umfassendes Konzept als wichtig erkannt, und man bekommt das Datenmodel, Softwarestrukturmodel, sowie Software+Testkonzept ausgearbeitet zur Verfügung gestellt, oder man bekommt diese Arbeit vorab bezahlt
- "privat" oder als "bezahlten Forschungs-/Optimierungsauftrag" mache ich mit bei zunächst "ziellosen" Grundlagenentwicklungen durchaus die Arbeit, da man etwas so elegant und schön wie möglich, bzw. auch mal was so schnell&effektiv zu realisieren... das wandert dann erstmal NiceToHave in meinen Copy&Paste Source Fundus


Wenn du (aktuell) der einzige Entwickler bist, hast du im "daily business" incl. Support für so ne Fallanalyse kaum die Zeit und dir fehlt der Abstand.
Sag im Meating, das du in die Firma gekommen bist, um im Team(und sei es nur zu zweit) bestehendes zu pflegen und neues zu schaffen, du als OneManShow da aber aktuell an die Grenzen des zeitlich machbaren stößt. Schlage also vor die einen neuen internen oder sei es auch externen Partner/Berater zur Bestandsanalyse zu beschaffen.

Es heiß ja nicht das du es nicht kannst oder willst, aber es ist einfach besser wenn du bei solch perspektivischen Entscheidungen dich absicherst!... Klar bist du der neue "OneManKing" wenn es klappt, aber wenn du auf deinem Fachgebiet die einzige Person mit Kernkompetenz bist und es geht was schief, ist das immer doof weil niemand anderes fachlich weiß, wie gut/schlecht das ist was du da gemacht hast...

[jobo]

Es ist schon mehrfach gesagt worden, das Alte pflegen, Erweiterungen nach Möglichkeit neu. Alles andere ist schwer zu finanzieren und umzusetzen.
Wenn Backend / SOA nicht so chaotisch ist wie der Client, dann hast Du doch eigentlich auch ganz gute Karten, glaube ich.

Ich würde sowieso sagen, dass Systeme mit der Zeit dazu neigen, heterogen zu werden, wenn nicht schon so angelegt. Ein zentrales Backend, wo die Fäden zusammenlaufen, ist der Punkt, an dem ich mich orientieren würde.
Erweiterungen modular auf/anbauen, Interfacing wo es nur geht, Pflegemaßnahmen ggF. darauf abklopfen, ob die Pflege mit wenig Mehraufwand durch eine Neuentwicklung erledigt werden kann.

Pflege kann auch bedeuten, zentrale Dienste oder Funktionen durch (zuschaltbares) Logging anzureichern. Das kann Fehlersuche und Verständnis der Abläufe gerade in Streßsituationen ungemein erleichtern. Bei komplexen Systemen kann es sogar helfen, Dinge zu "entdecken", deren protokollierter Ablauf zwar bekannt, aber unverstanden ist. Irgendwelche Datenläufe die keinen Sinn ergeben, außer es ist Geschäftsjahresabschluss, usw. usf.

Interfacing scheint mir sehr wichtig, bezüglich Namensgebung, Rechteabgrenzung, Verantwortungsabgrenzung. Das sollte man auf jeden Fall mit Neuentwicklungen machen und nach Möglichkeit auch irgendwo einschleichen, wo man sowieso gerade etwas gerade ziehen muss.

Wenn Du die Möglichkeit hast, eine autarke (Client)Anwendung zu "ergattern", also einen Arbeitsauftrag unter Deinem Namen, (mit neuer Technologie) neue Themen umzusetzen, würde ich das natürlich auch nicht ablehnen.

[p80286]

Zum einen, alle anderen sind nicht so gut wie ich 8-) und damals hab ich einen Mist verzapft...
In der Praxis hieß das für mich Finger weg von dem Code der das getan hat was er sollte, da wurde nur Doku ergänzt. Bei allen anderen Teilen wurden die Renovierungen von unten herauf ausgeführt, und in einer stillen Stunde wurde dann auch irgendwelcher Zaubercode durch etwas sauberes ersetzt. Und natürlich auch die Doku aktualisiert!

Ach ja , nichts ist selbstverständlich! Das ist ganz klar ein Irrtum.

Gruß
K-H

[TigerLilly]

Das ist eine unbefriedigende Situation + man bekommt rasch den schwarzen Peter, wenn was nicht oder nicht rasch genug funktioniert. Was ich aus meiner Erfahrung beitragen kann:

- Der Aufwand, etwas "neu" zu machen wird meistens dramatisch unterschätzt
- Bevor man auch nur überlegen kann, ob man etwas neu macht, muss man den Legacy Code + die Infrastruktur rundherum in seinen Abfolgen+Zusammenhängen verstanden haben. Das braucht Zeit, in der man für das Management scheinbar unproduktiv ist.
- Bevor so etwas - egal ob neu machen oder anpassen - angegangen werden kann, braucht es das Commitment und das Verständnis des Managements, dafür, was das Problem ist + dass die fehlende Doku ihr Problem ist und nicht deines.
- Legacy Code heißt immer, dass Probleme gelöst werden, die es gar nicht mehr gibt. Es geht also nicht nur darum, zu verstehen, was der Code tut, sondern auch darum, zu verstehen, ob das noch sinnvoll ist.

Deine vordringlichen Aufgaben sind also, egal ob neu machen oder nicht:
- verstehen, was der Code tut
- verstehen, was er noch/neu tun sollte
- jede Zusage auf Technologie oder Modell oder wie oder was bis auf weiteres verweigern

Wenn möglich hol dir eine/n ExpertIn dazu, als Freelancer, der dich in der Anfangsphase unterstützt. Da kannst du viel lernen + ein/e Externe/r tut sich leichter so richtig dumme Fragen zu stellen.

[Der schöne Günther]

Ich kann nichts mehr beitragen außer dem was schon gesagt wurde. Nur folgendes würde ich noch einmal unterstreichen:

Zitat:

Zitat von TigerLilly (Beitrag 1387949)

- Der Aufwand, etwas "neu" zu machen wird meistens dramatisch unterschätzt

Vor allem wenn sich die Anforderungen mittendrin dergestalt ändern dass Features die seit Jahren niemanden mehr interessiert haben und auch nicht mehr vorgesehen waren nun doch wieder plötzlich verkauft werden. Schlechte Projektplanung und Kommunikation im Unternehmen macht so eine Neuentwicklung von Grund auf nicht einfacher wenn sich nur ein Bruchteil der Betroffenen (also außerhalb der Softwareentwicklung) damit wirklich auseinandersetzt.

[bernau]

Zitat:

Zitat von Xzeer (Beitrag 1387904)

Dieser Code ist ein wilder Mix aus verschiedenen Ansätzen und Konstrukten: Code-behind, MVVM, Databinding, Events, Commands... Nichts ist wirklich einheitlich durchgezogen worden.

Handelt es sich etwa um meinen Code. :shock:

Nein im Ernst. Man entwickelt sich weiter. Dem entsprechend sieht ein Code aus, der über 10 und mehr Jahre gewachsen ist.

Wenn ich mir meinen "alten" Code anschaue, dann stechen mir sämtliche "Ansätzen und Konstrukten" ins Auge, die mich im ersten Augenblick begeistert haben und später mich zur Weisglut gebracht haben. So ist das, wenn man sich weiter entwickelt.

Ich bin zu 1/3 meiner Zeit mit refactoring meines alten Codes beschäftigt. Das ist nicht nur bei fremden legacy-code so.

Ich habe auch schon mal meine Software komplett neu geschrieben, weil ich mit der Alten an die Grenze der Erweiterbarkeit gestoßen bin. Die veranschlagte Zeit hat sich leider vervierfacht (oder war es noch mehr?). Und dass, obwohl ich das Hintergrundwissen zur Anwendung dann nicht erst aufbauen musste sondern bereits seit Jahren angeeignet hatte.

[Codehunter]

Hallo!

Ich finde, das ist einer der interessantesten Threads der letzten Zeit. Vielleicht kann ich noch eine andere Sichtweise beisteuern.

Ich habe über Jahre eine Software aufgebaut und gepflegt als sie fertig war. Der Grundstein wurde zu Delphi-7-Zeiten gelegt. Der Anforderungskatalog war recht klar definiert. Hin und wieder kam mal ne Kleinigkeit dazu, manchmal musste was angepasst werden um das neueste Windows zu unterstützen, aber im großen und ganzen eine kleine heile Welt.

Dann kam plötzlich jemand in der Geschäftsleitung auf die Idee, wir expandieren jetzt auf den russischen Markt! Außerdem war das bisherige Warenwirtschaftssystem nicht mehr genehm, es musste unbedingt ein anderes her. Da wurde einerseits die Front beim Thema Unicode geöffnet, andererseits auch noch bei den Schnittstellen zum Wawi.

Also stand ich vor der Entscheidung, das bestehende Programm anzupassen oder von Grund auf neu zu bauen. Nun war es schon 2013 und ich immer noch mit D7 unterwegs, da war ein Upgrade sehr verlockend - aus meiner egoistischen Sicht ;-) Außerdem war ich an vielen Stellen mit dem vorhandenen Code unzufrieden. Wie es immer so ist bei gewachsenen Projekten: Man probiert mal was aus (auch aus Richtung Geschäftsleitung) und überlegt es sich wieder anders. Es bleiben halbfertige Altlasten zurück.

Es wurde also neu entwickelt. Zwei Jahre gingen dafür drauf. Pflege der alten Anwendung nahezu unmöglich, weil Mannstunden begrenzt. Zwischendurch kam Windows 7 mit etwas Verspätung in "mein" Ökosystem, die alte Anwendung lief darauf nicht mehr, also wurde der halbfertige Neubau ausgerollt. Mit dem entsprechenden Stress und Frust auf Seiten der Anwender. Derweil war es Ende 2015.

Der doofe Programmierer war natürlich schuld, weil der hatte ja in drei Jahren nix brauchbares zustande gebracht. Derweil hat sich das Projekt Russland-Expansion in blassen Dunst aufgelöst, weil der Wladimir gern Krimsekt trinkt und auf den Flaschen eine andere Flagge sehen wollte ;-) Sich verändernde Rahmenbedingungen, die nicht vorhersehbar waren.

Irgendwann hab ich mir dann die Frage gestellt: Was wäre gewesen, ich hätte die ganze Unicode-Baustelle sein lassen und mich ausschließlich auf die Wawi-Schnittstellen (die lustigerweise auch nur 128-Byte-ANSI beherrschen) und die Windows-Kompatibilität beschränkt. Vereinfacht gesagt, wir hätten summa summarum keine halbe Million Euro in den Wind geschossen und dafür eine ziemlich angestaubte Softwarelösung. Stattdessen haben wir jetzt eine sündhaft teure Neuentwicklung mit sauberer Codebasis.

Was davon wäre nun besser rückblickend besser gewesen? Für mich Stand heute ganz klar die Variante mit D7 und Altcode. Ich hätte weniger Stress gehabt und in kürzerer Zeit flexibler auf die ein oder andere veränderte Rahmenbedingung reagieren können. Aber wie das für die Zukunft aussieht ist schwer zu beurteilen. Microsoft kann sich irgendwelche Dummheiten beim Windows ausdenken, wo sich unser neuer Code einmal bezahlt macht. Oder statt Kyrillisch wird auf einmal Chinesisch interessant. Niemand weiß es heute.

Das zwischenzeitlich neu ausgerollte Wawi entpuppte sich übrigens nach nur einem Jahr als grandioser Schuss in den Ofen. Unterm Strich 10x teurer als die vorherige Lösung, instabil und mit lausigem Anwendersupport. Letztlich auch nicht durchgehend Unicode-fähig. Das auch noch zum Gesamtfazit hinzu gerechnet, schlägt das Pendel endgültig zur Pflege von Altanwendungen aus. Das mag aber durchaus fallspezifisch sein. Für eine umfassende frühzeitige Einschätzung fehlt einem als Entwickler nicht selten die nötige Weitsicht und fachübergreifendes Knowhow. Dafür gibt es, IMHO sogar hier im Forum, Leute die das als Dienstleistung anbieten. Dies ist auf jeden Fall günstiger als wenn man wie in unserem Fall eine teure Fehlentscheidung trifft. Die ist zum Glück nicht allein auf meinem Mist gewachsen...

Wenn ich jetzt den Altcode von jemand anderem übernehmen müsste: Ich kann mir schon vorstellen, dass die Einarbeitung eine elende Sisyphus-Arbeit sein kann. Aber A) lernt man was dabei, B) kann man die durchgearbeiteten Teile gleich Stück für Stück dokumentieren und C) dabei gleich ein Ranking der zu überarbeitenden Teile aufstellen. Man schaue sich auf jeden Fall auch gründlich auf dem Markt für Zuliefer-Komponenten um. Wann immer es für bestimmte Probleme fertige Lösungen gibt, sollte man die einkaufen statt selbst das Rad nocheinmal zu erfinden. Das ist stets langfristig teurer. Man muss aber genau schauen, Pflichtenheft aufstellen, damit man sich nicht eine Krücke einkauft.

Grüße
Cody

PS: Im vorliegenden Fall scheint den größten Fehler eure Geschäftsleitung schon gemacht zu haben: Den alten Entwickler gehen zu lassen. Ohne die genauen Umstände zu kennen: Vielleicht hätte er sich seinen Verbleib vergolden lassen. Aber unterm Strich hat man da auf die "In-Brain-Dokumentation" dessen verzichtet, das man in Form eines Firmenaufkaufs teuer ins Haus geholt hat und das jetzt durch euch mit entsprechenden Reibungsverlusten nachgeholt werden muss.

[Xzeer]

Schon mal vielen Dank für alle eure Antworten. :)

Es hilft, die Meinung und Erfahrungen von Entwicklern zu hören, die schon lange im Berufsleben stehen. Gegen min. einen weiteren Kollegen hätte ich auch überhaupt nichts einzuwenden. Ganz im Gegenteil. Gerade den Austausch untereinander finde ich eine gute Sache, die mir aktuell fehlt.

Was ich aus vielen Beiträgen so raushöre, ist die Erfahrung, dass neu entwickeln zwar schön ist, aber oftmals aufwendiger und stressiger sein kann, als den Bestandscode nach und nach zu verbessern. Außer der Projektleiter trägt die Entscheidung einer Neuentwicklung zu 100% mit und kennt die damit verbundenen Risiken.

Bei mir ist es zusätzlich auch so, dass mir der wirklich komplette Überblick über die Lösung aktuell auch noch fehlt, da ich ja erst seit Anfang des Jahres frisch dabei bin. Die Zeit, um den Bestandcode zu analysieren und aufzuarbeiten ist also wahrscheinlich tatsächlich nicht verschwendet.
Auch wenn bei mir da so ein bisschen der Beigeschmack bleibt, etwicklungstechnisch im Leerlauf zu laufen. Sprich es gibt so viele interessante und neue Möglichkeiten (Technologien, Frameworks, Patterns) die dann erstmal nicht eingesetzt werden und an mir vorbeigehen.
Zusätzlich ist das Programm leider eben keine kleine und heile Welt, die es weiterzupflegen gilt. Sondern es stehen zum Teil große, neue Features auf dem Plan, die es so unter iOS schon gibt und über kurz oder lang in das Windows Frontend müssen, aber damals logischerweise natürlich noch nicht bedacht wurden. Daher rühren meine persönlichen Überlegungen, ob es wirklich Sinn macht, in eine metaphorisch alte Rostlaube noch zu investieren.

Aber eure Argumente gegen eine Neuentwicklung sind natürlich nicht wegzudiskutieren und sind für mich absolut nachvollziehbar.

Ich denke, ich werde also eher vorsichtig mit Vorschlägen zu einer Neuentwicklung sein. :wink:


EDIT:

Zitat:

Zitat von Codehunter (Beitrag 1387963)

PS: Im vorliegenden Fall scheint den größten Fehler eure Geschäftsleitung schon gemacht zu haben: Den alten Entwickler gehen zu lassen. Ohne die genauen Umstände zu kennen: Vielleicht hätte er sich seinen Verbleib vergolden lassen. Aber unterm Strich hat man da auf die "In-Brain-Dokumentation" dessen verzichtet, das man in Form eines Firmenaufkaufs teuer ins Haus geholt hat und das jetzt durch euch mit entsprechenden Reibungsverlusten nachgeholt werden muss.

Genau das denke ich auch. Die "In-Brain-Dokumentation" würde an manchen Stellen extrem helfen und fehlt jetzt.

[sh17]

Es spricht natürlich nichts dagegen, an den alten Entwickler noch einmal heranzutreten, aber vielleicht gibt es auch andere Differenzen oder verletzte Befindlichkeiten. Als Entwickler einer riesigen Lösung über einen langen Zeitraum baut man auch eine gewisse Bindung dazu auf. Es muss schon einiges geschehen, um sich persönlich davon zu verabschieden.

[OlafSt]

Vielleicht kann ich auch noch etwas beitragen. Ich mache schon 3 Jahrzehnte in Software-Entwicklung und habe schon eine Reihe großer bis sehr großer Programme "unter den Fingern" gehabt. Groß beginnt bei mir ab ner Million Codezeilen, ohne Fremdkomponenten.

Zwei dieser Projekte sind deutlich über 20 Jahre alt, eines davon noch mit Delphi 5. Dieses ist nur noch mit Mühe unter Windows 10 zum laufen zu bringen. Es ist absehbar, wann der Compiler einfach nicht mehr funktionieren wird.

Hier wurde erwähnt, das man für alles am besten Fremdkomponenten nehmen sollte. Dem widerspreche ich in aller Form :-D Denn hier, in diesem Projekt, sind das inzwischen an die hundert solcher Komponenten geworden, von denen ich vier (!) auf ein neues Delphi bringen konnte. Die restlichen Komponenten sind nicht austauschbar, es gibt auch keine neuen Versionen davon - sie müssen also hart refaktoriert werden.

Der restliche Code ist der übliche Alptraum, hier haben sich an die 20 Entwickler versucht, in den unterschiedlichsten Kompetenzgraden. Aber eines ist klar: Neu schreiben kommt nicht in Frage. Wir portieren Fenster für Fenster in DX10, ziehen Unicode nach, tauschen die Datenbankkomponenten von "keine Ahnung, was das ist" auf FireDAC etc. Das wird auf lange Sicht deutlich billiger werden, als es neu zu implementieren. Die Software ist in der Werbebranche zu Hause, da wird so oft ne neue Sau durchs Dorf getrieben... Da macht das schrittweise Umschreiben mehr Sinn.

[Bernhard Geyer]

Zitat:

Zitat von OlafSt (Beitrag 1387976)

Hier wurde erwähnt, das man für alles am besten Fremdkomponenten nehmen sollte. Dem widerspreche ich in aller Form :-D Denn hier, in diesem Projekt, sind das inzwischen an die hundert solcher Komponenten geworden, von denen ich vier (!) auf ein neues Delphi bringen konnte. Die restlichen Komponenten sind nicht austauschbar, es gibt auch keine neuen Versionen davon - sie müssen also hart refaktoriert werden.

Das mit den "überall Fremdkomponenten nehmen" ist aber keine allgemeine Meinung.
Und vor allem nicht soll man nicht für jede Funktion eine andere Komponenten nehmen.

Wir hatten auch schon so einen Wildwuchs den ich mittlerweile halbwegs "eingestampft habe".
Ein Komponente für DB (Unidac von Devart), 1-2 für die GUI (LMD wegen Unicode), eine Komponenten für Kommunikation, und natürlich (gibt ein paar Stellen wo es nötig ist) JCL ...
RX, TNTWare, VCLZip sind über die Jahre rausgeflogen.

Zitat:

Zitat von OlafSt (Beitrag 1387976)

... tauschen die Datenbankkomponenten von "keine Ahnung, was das ist" auf FireDAC

Schau dir mal die Unidacs an. Ist günstiger und 1a Qualität. Bei Delphi musst du sonst immer die IDE hochziehen wenn du neu DB-Unterstützen willst.

[himitsu]

Gerade bei Fremdkomponenten versuchen wir für Alles nur noch Welche inkl. Quellcode zu verwenden, weil man da theoretisch wenigstens noch die Möglichkeit hätte das mal auf ein neues Delphi zu portieren, selbst wenn der Hersteller verschwunden ist.
Und auch kleinere Bugfixes sind so noch möglich, auch wenn der Hersteller nicht schnell genug das beheben kann/mag.

Da hat man dann oftmals noch mehr undokumentierten Fremdcode im Programm, aber alles selber machen ist auch keine Lösung.

[Der schöne Günther]

Deine Situation ist ja doch recht ähnlich wie bei mir. Ich war auch neu (2013) und langfristig sollte dann eine bestehende Software "neu gemacht" werden, hauptsächlich durch mich.

Die Wahl fiel hier auf eine komplette, saubere Neuentwicklung von Anfang an. Es hat gedauert und gedauert und irgendwann haben wir den Stecker gezogen und eingesehen dass man nicht eine Software die über 15 Jahre gewachsen ist, innerhalb von 18 Monaten von Grund auf neu schreiben kann, vor allem hauptsächlich von jemandem der neu ist. Und besonders dann nicht, wenn die Anforderungen so "agil" sind dass Features die seit 10 Jahren keinen mehr interessiert haben jetzt doch plötzlich wieder rein müssen und bitte bis nächste Woche.

Innerhalb von 1-2 Wochen haben wir in einer Gewaltaktion dann die bestehende Software genommen (die ja auch weiterhin supported werden muss), eine neue Oberfläche gemacht, im Backend ein paar Dinge neu gemacht (z.B. Teile Persistierung) oder aufgebohrt und was dann heraus kam war echt schon fast besser als das woran monatelang gearbeitet wurde.

Klar lag der Fehlschlag beim "Neumachen" wohl hauptsächlich an nicht vorhandenem Projektmanagement und dem festen Glauben an das Chinesen-Prinzip. Trotzdem war die Entscheidung die bestehende Software zu nehmen, auseinanderzupflücken, Tests zu schreiben und Schritt für Schritt zu erneuern die vielleicht beste Entscheidung die ich hier bislang durchbringen konnte 8-)

[Sherlock]

Gegen eine Neuentwicklung spricht vor allem eines: Es werden garantiert Funktionen fehlen, die von den Anwendern schmerzlich vermißt werden. Sowas kann einem dann ganz schnell und ganz rabiat den Hals brechen.

Hab das schon zweimal gesehen, als eine Firma ihr bewährtes Produkt, daß auf einer recht angestaubten Codebasis und reichlich individuellen Anpassungen baute mal so eben nach .net wuppen wollte. Hinterher sah alles Supi aus, und war bestens dokumentiert, aber es konnte die Anwender schlicht nicht zufrieden stellen, weil eben viele der nützlichen aber undokumentierten Funktionen fehlten. Das brach beiden Firmen das Genick. Ich würde lieber versuchen, die Dokumentation nachzuziehen. Es gibt heutzutage ja viele Tools, die dabei helfen.

Sherlock

[OlafSt]

Gerade bei meinem Projekt hier ist das nicht ganz so einfach ;) Die Umstellung auf [irgendein]DAC allein wird schon ne Weile dauern. Denn [irgendein]DAC gibt es nicht für Delphi 5. Die im Projekt verwendeten DB-Komponenten existieren nur noch hier, Hersteller und Websites sind längst im Nirvana verschwunden. Bedingt durch Delphi 5 ist die Portierung auf Tokyo nahezu aussichtslos, das geht bereits bei nicht existenter Unicode-Unterstützung los...

Den Wildwuchs an Komponenten konnte ich soweit eindämmen. Hier lief ein Subset von TMS, LMD, RXLib, drei veschiedene PDF-Generatoren, Fastreports, QuickReports, FastNet, vier verschiedene Excel-Komponenten, diverse DBGrids und Treecontrols usw... Alles in allem ein riesengroßer Haufen Mist ;)

Nachdem wir uns eine Weile im Code umgeschaut haben, kamen wir dann zu dem Entschluß, erstmal die allerheftigsten Bugs zu beseitigen. Nach 6 Monaten gibt es nun eine Version, die nicht nach dem dritten Mausklick mit ner Schutzverletzung zum Desktop rausbombt :-D Nun können wir langsam die Controls für die GUI gegen Standards tauschen und irgendwann Q3 2018 gehts an die DB-Geschichten.

Am Anfang war ich auch der Ansicht: Wegwerfen, neu machen. Aber das Projekt hier ist einfach zu komplex, zu verworren, zu undokumentiert und zu unstrukturiert. Hier geht es nur über ein langsames Refactoring, sonst geht das Projekt direkt an die Wand.

[sh17]

Nochmal was aus der Sicht des Anwenders, wie auch schon oben angesprochen. Angenommen, es soll eine Neuentwicklung werden, dann läuft die alte Anwendung während der Entwicklung nebenbei weiter. Wenn man dann mal in 3-4 Jahren "fertig" ist, hat man definitiv 2 verschiedene Produkte mit ggf. noch fehlender Funktionalität in einem von beiden. Jetzt geht der Spass mit dem Support erst los. "Alles neu, alles doof, früher ging das doch, wieso ist das jetzt so?, ich will das alte Programm wieder haben".

[OlafSt]

Zumindest mein Boss ist da eisenhart: "Dieses Programm gibt es nicht mehr". Basta.

Dann erklärt er, wie es in der neuen Software geht (meist dann viel einfacher) und alle sind glücklich.

[Towmuz]

Zitat:

Zitat von sh17 (Beitrag 1388027)

"Alles neu, alles doof, früher ging das doch, wieso ist das jetzt so?, ich will das alte Programm wieder haben".

Diese bornierte Haltung ist später das größte, wenn nicht einzige, Problem, wenn man alles richtig gemacht hat.
Angefangen mit einem: "Warum ist der Knopf jetzt 2cm weiter rechts und wieso ist der nicht mehr in clAqu...clVergewaltigung eingefärbt, ich hab jetzt 10 Jahre immer an der Stelle auf den Knopf gedrückt...und wieso ist das Fenster jetzt so groß? Ich will die Liste erst durch die horizontale Scrollbar sichtbar machen...".

Bis hin zu: "Boah muss das so kompliziert sein? 3 Werte eintragen? Echt jetz? Ihr könnt doch die Programme nicht einfach an die Geschäftsprozesse anpassen, verdammt. Wer macht denn sowas?".

[sh17]

kommt sicher auch darauf an, wie die Zielgruppe aussieht. Aber generell möchten die arbeiten und sich nicht ständig in neue Arbeitsabläufe der Software reindenken. Aber ok, war nur ein Gedanke.

[p80286]

Zitat:

Zitat von sh17 (Beitrag 1388033)

kommt sicher auch darauf an, wie die Zielgruppe aussieht. Aber generell möchten die arbeiten und sich nicht ständig in neue Arbeitsabläufe der Software reindenken. Aber ok, war nur ein Gedanke.

:thumb:

Und die Logik eines Programmierers/Entwicklers unterscheidet sich doch manchmal enorm von der eines Benutzers.

Gruß
K-H

[Sherlock]

Zitat:

Zitat von p80286 (Beitrag 1388035)

Und die Logik eines Programmierers/Entwicklers unterscheidet sich doch manchmal enorm von der eines Benutzers.

Sollte jeder Entwickler als Tapete im Büro haben.

Sherlock

[jobo]

Ich persönlich würde ja sagen, der Kraftakt einer (schnellen) Neuentwicklung kann ja wohl kaum an nur 1 bis 2 Entwicklern hängen bleiben.
Wie sollen die allein bei bloßer Entwicklungstätigkeit bspw. feststellen bzw. entscheiden, was (überhaupt)noch von der alten Funktionalität (sofern sie entdeckt wurde) weiter benötigt wird.
Die einfache Antwort ist natürlich "Alles!". Aber wir lernen ja gerade überall, einfache Antworten gibt es eigentlich gar nicht.

Es gehört also der unbedingter Zuspruch der Verantwortlichen dazu, zusammen mit der Anforderung an die Kollegen, nach Möglichkeit konstruktiv zu unterstützen.
Anfangen könnte man mit Priorisierungen.

Letztlich hilft es niemand, wenn der Kraftakt ein Unternehmen (nahezu nutzlos) ruiniert -wie hier im Thread auch beschrieben- und alle gefeuert werden und heulen, ich wollte ja nur meine Arbeit machen.

Für eine sinnvolle Weiterentwicklung und Umbau der bestehenden Systeme gilt letztlich das gleiche, wenn es auch weniger Wahnsinn birgt und für alle vermutlich gesünder verläuft.

Nur weil mit Software in der Theorie alles möglich ist, bedeutet es in der Praxis erst mal so gut wie gar nichts. Die Möglichkeiten und Verlockungen sind verführerisch, aber (ein paar oder viele Zeilen) zu programmieren ist etwas anderes als (erfolgreiche) Softwareentwicklung.

[bytecook]

Zitat:

Zitat von Sherlock (Beitrag 1388050)

Zitat:

Zitat von p80286 (Beitrag 1388035)

Und die Logik eines Programmierers/Entwicklers unterscheidet sich doch manchmal enorm von der eines Benutzers.

Sollte jeder Entwickler als Tapete im Büro haben.

Sherlock

Dem Manne kann geholfen werden... :P

http://www.bimago.de/motive-fototape...w31291670.html

[Codehunter]

Ich denke wir rutschen hier in eine Problematik hinein, die viele Softwareschmieden betrifft: Zu niedriges Entwicklungsbudget. Warum bleiben viele Projekte ewig auf einem Delphi 5 oder 7 hängen? Weil weder die Manpower noch die Upgrades auf neuere Delphiversionen vorhanden sind. Eigentlich muss man ja immer wenigstens zwei Projektzweige gleichzeitig pflegen: Die LTS-Version die nur Bugfixes bekommt und Jahre auf dem selben Compiler bleiben darf und die Feature-Version, die stets mit dem neuesten Stoff versorgt wird. Dafür brauchts aber auch die Manpower.

Ich bzw. mein Brötchengeber machen auch nicht jedes neue Release von Delphi mit. Es streiten sich regelmäßig die Geister, ob Subscription sich nun rechnet oder nicht. Fakt ist, bei allen wichtigen Neuerungen (z.B. als Unicode kam, als 64 Bit kam usw.) habe ich den Laden hochgezogen und die Projekte migriert. Zumindest bei denen wo das sinnvoll und möglich war.

Wenn man als Softwarefirma am Markt sein will, muss man in leitender Funktion auch die Fähigkeit besitzen, in Mannstunden zu rechnen. Man muss wissen, welche Projekte sind wie dringend und wo liegen die Prioritäten. Wenn es so läuft wie bei uns allzu häufig, alles hat 1+++ Priorität, alles muss am besten vorgestern fertig sein und wenn man brav bettelt bekommt man alle drei, vier Jahre mal sowas wie Unidac oder ein Upgrade auf die Enterprise wegen dem Linux-Compi, dann läuft schlicht was nicht rund im Management. Punkt aus.

Und da werd ich ziemlich galle wenn ich so junge Talente wie Xzeer hier auftauchen und verzweifeln seh. Den nehm ich hiermit in aller Form in Schutz. Das wollt ich einfach mal gesagt haben.

[Ghostwalker]

Aus eigener Erfahrung kenn ich die Problematik mit "Alt-Lasten" nur zu gut. Du wirst nicht umhin kommen, den alten Code zu verstehen, ansonsten ist eine Abschätzung von Aufwendungen (egal ob jetzt reingefrikel in den alten Code oder eine Neuschreibung) schlicht unmöglich.

Wenn du das hast, kommt (i.d.R) das nächste Problem: Wie sag ichs dem Chef ?

Was die Chefs meistens wirklich interresiert ist: Was kostet es mich ? Was erwirtschafte ich damit ? (also Kosten/Nutzen-Verhältnis)

Wenn du das deinem Chef richtig verkaufen kannst, hast gewonnen :)

Bedenke dabei aber auch die Folgekosten bei einer Neuschreibung (so sachen wie Anwenderschulung, Anschaffung neuer Hardware/Software usw.). Denn das wird mit Sicherheit zu Sprache kommen.

@Codehunter

Da kann ich dir nur zustimmen. Ergänzend muss ich da noch sagen, das die Problematik in einem Konzern, dessen Kerngeschäft nicht die Softwareentwicklung ist, noch viel schlimmer ist. Da musst du das ganze nämlich in der Regel mit Leuten klären, die keinerlei Ahnung von der IT im Allgemeinen und der Softwareentwicklung im speziellen haben.

[Bernhard Geyer]

Zitat:

Zitat von Sherlock (Beitrag 1387984)

Hab das schon zweimal gesehen, als eine Firma ihr bewährtes Produkt, daß auf einer recht angestaubten Codebasis und reichlich individuellen Anpassungen baute mal so eben nach .net wuppen wollte. Hinterher sah alles Supi aus, und war bestens dokumentiert, aber es konnte die Anwender schlicht nicht zufrieden stellen, weil eben viele der nützlichen aber undokumentierten Funktionen fehlten.

Ein sehr bekanntes Beispiel ist die Telekom bei der es nach dem Motto "Machen wir es neu" ging. Dort wurden in 20 Jahren 10 mal versucht das alte Zentrale Management/Verwaltungstools durch eine Neuimplementierung abzulösen.
Nach 20 Jahren hatte die Telekom 11 System und die armen Techniker mussten alles mehrmals Eingeben. Einmal in einen der neuen Tools und einmal im uralten Zentralen System das immer noch für alles letztendlich zuständig ist.

[TigerLilly]

Zitat:

Bedenke dabei aber auch die Folgekosten bei einer Neuschreibung (so sachen wie Anwenderschulung, Anschaffung neuer Hardware/Software usw.). Denn das wird mit Sicherheit zu Sprache kommen.

Das ist ein guter Punkt, der oft sträflich unterschätzt wird. Diese "Folge- und Nebenkosten" machen nämlich auch gern mal 2x so viel wie die Entwicklung aus. Wir planen zB diese Verhältnisse bei Neuprogrammierungen:
- Entwicklung 30%
- Unterlagen/HP/Hilfe 30%
- Interne Schulung/Support 10%
- Externes (Marketing, Händler, Koops etc) 20%

Das heißt auch, dass ein Aufwand von 10.000.- Entwicklung der Firma weitere 20.000.- kostet.

[bytecook]

Zitat:

Zitat von TigerLilly (Beitrag 1388159)

Zitat:

Bedenke dabei aber auch die Folgekosten bei einer Neuschreibung (so sachen wie Anwenderschulung, Anschaffung neuer Hardware/Software usw.). Denn das wird mit Sicherheit zu Sprache kommen.

Das ist ein guter Punkt, der oft sträflich unterschätzt wird. Diese "Folge- und Nebenkosten" machen nämlich auch gern mal 2x so viel wie die Entwicklung aus. Wir planen zB diese Verhältnisse bei Neuprogrammierungen:
- Entwicklung 30%
- Unterlagen/HP/Hilfe 30%
- Interne Schulung/Support 10%
- Externes (Marketing, Händler, Koops etc) 20%

Das heißt auch, dass ein Aufwand von 10.000.- Entwicklung der Firma weitere 20.000.- kostet.

Aber nur im "Best Case", sonst ca. x5, insbesonders, wenn nicht alle Kunden gleich auf das neue System "umsteigen" mögen, dann heißt es, daß der Support zweigleisig fahren muß...

[jobo]

Einige Dinge gehen hier aber doch etwas am Anliegen eines Berufseinsteigers vorbei.
Ich denke, der Ratschlag, sich mit dem Altsystem auseinanderzusetzen und primär eine Pflege zu bevorzugen ist sicher angekommen.
Er muss aber nicht für seine Chefs mitdenken, geschweige entscheiden.

Kalkulation von Folgekosten, egal welche Richtung usw. sind sicher nicht die Anforderung an der Stelle, jedenfalls nicht proaktiv durch einen Berufseinsteiger. Er dürfte mit der Pflege und / oder Neuentwicklung gut ausgelastet sein.

Natürlich muss man auch über den Tellerrand schauen, spätestens wenn man dazu den Auftrag erhält, ansonsten auch mal die Kirche im Dorf lassen. Im Einkauf muss sich schließlich auch niemand darüber den Kopf zerbrechen, welche Implikationen bestimmte Änderung einer SAP R3 API im bevorstehenden Releasewechsel für die Integration mit den firmeninternen Eigenentwicklungen hat.