Verwaister und undokumentierter Bestandscode - was tun?

[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.