Kaputte Software

[Ich werd noch bekloppt]

Hallo,

ich brauche mal ein paar offene Ohren bzw. Augen, und vielleicht den einen oder anderen Rat.

Ich habe von meinem Vorgänger drei größere Software-Projekte "geerbt". Eine saubere Übergabe hat nicht stattgefunden, stattdessen zog es mein Vorgänger vor, bis zur letzten Sekunde an der Software herumzufrickeln. Eine Kollege, der etwas vor mir angefangen hat, sollte von ihm eingearbeitet werden, auch das ist im Wesentlichen nicht passiert.

Der Vorgänger hat von Softwareentwicklung definitiv keinen Plan, hat nie eine entsprechende Ausbildung gehabt und ist ursprünglich eigentlich Verkäufer mit einem gewissen technischen Hintergrund. Der Kollege hat zwar mal für eine Uni gearbeitet, im naturwissenschaftlichen Bereich, aber auch der hat absolut keinen Plan von SW-Entwicklung.

Für alle drei Projekte existierte bis zur Übernahme weder Dokumentation (mit der Ausnahme eines schnell zusammengestückelten "Benutzerhandbuchs") noch Spezifikation, auch existiert keinerlei Historie der Entwicklung bis zu dem Zeitpunkt. Irgendwo in einer finsteren Ecke steht noch ein Karton voll Schmierpapier mit hingerotzen Notizen, die niemand versteht.

Alle drei Projekte nutzen eine gruselige, propritäre Design- und Entwicklungsumgebung und eine dazugehörende Laufzeitumgebung (zusammen "die Umgebung"), deren Ursprünge ungefähr bis DOS 2.0 zurückreichen. Entsprechend viele Altlasten haben sich angesammelt. Dazu kommt je Projektinstallation eine handelsübliche relationale Datenbank, in der die Nutzdaten ansatzweise strukturiert abgelegt sind. Von Normalform keine Spur, die Daten werden typischerweise durch die Anwendung verwurstet. Code wird 100fach kopiert und modifziert, statt Funktionen zu benutzen. Tonnen globaler Variablen. "Action at a distance." Und so weiter.

Die Umgebung an sich hat schon einige Bugs, um die man herumarbeiten muß, das bekommt man auf den Schulungen des Herstellers bereits vermittelt. Dazu fängt man typischerweise damit an, die DB noch weiter zu denormalisieren. Bislang habe ich zwei neue Bugs in der Umgebung gefunden, einer harmlos, einer führt dazu, das gewisse Befehle schlicht nicht ausgeführt werden. Während der Schulungen habe ich am Rande erfahren, dass es bei der Entwicklung der Umgebung ähnlich finster zugeht. Horden Ahnungsloser frickeln so lange am System herum, bis es ungefähr das macht, was der Kunde erwartet. Sourcecode-Verwaltung gibt es nur auf einer Maschine als Alibi, weil jemand mal gesagt hat, man müsse so etwas haben. Das Geld kommt über Schulungen, Consulting und Customizing herein.

Alle drei Projekte haben eine gemeinsame Vorgeschichte, sie stammen alle aus einem toten, "overengeneered" Projekt, das das gesamte Unternehmen managen sollte, inklusive Kaffee kochen.

Das erste Projekt, mehr oder weniger eine Lagerverwaltung, wird gerade abgelöst, das wird sich zwar noch etwas hinziehen, aber ich erwarte da keine großen Überraschungen mehr. Tot, gestorben und nur noch nicht begraben. Dieses Projekt hat noch am meisten Ähnlichkeit mit dem Vorläuferprojekt, ist aber fürchterlich abgewrackt worden.

Das zweite Projekt steht bei externen Kunden in zwei oder drei Installationen, läuft einigermaßen, bringt uns Geld ins Haus, und hat mehr oder weniger einen "faß das besser nicht an"-Status. In naher Zukunft soll ein vom Hersteller der Umgebung geschulter, externer Dienstleister doch mal dran herumbasteln, aber das kümmert mich gerade nicht wirklich. Dieses Projekt ist als "Fork" des ersten Projekts entstanden, auch wenn es nicht so wirklich das gleiche macht.

Bleibt das dritte Projekt, mit dem ich mich jetzt schon über ein Jahr herumschlage, und das "nur" bei internen Kunden innerhalb des Unternehmensverbunds läuft. Die Hauptarbeit ist, Proben zu vermessen und zu überwachen, ob genügend Proben vermessen wurden. Dabei wird teils manuell, teils automatisch gemessen. Anbinden der Meßautomaten ist Bestandteil des Projekts. Auch dieses Projekt ist ein "Fork" der Lagerverwaltung.

Das Projekt hat jede Menge Fehler, die sich unter anderem mit Workarounds für die Umgebung, mangelndem Datenbank-Verständnis meines Vorgängers, manelnder Kenntnis von Software-Entwicklung, mangelnder Kontrolle, mangelnden Prüfungen erklären lassen. An einigen Stellen im Programmcode werde ich allerdings den Eindruck nicht los, dass mein Vorgänger unter Drogeneinfluß gestanden haben muß. Das meine ich durchaus nicht witzig, und deswegen schreibe ich auch nicht unter meinem Realnamen und nicht mit allen Details. Selbst wenn ich chronische Übermüdung, wahnsinnigen Termindruck, Dummheit und mangelndes Wissen zusammennehme, gibt es für diese Stellen nur zwei mögliche Erklärungen: Bosheit und Drogen.

Insgesamt ist das Projekt (oder eigentlich alle) in einem Zustand, der Mr. Burns aus den Simpsons mal attestiert wurde: Es hat alle Krankheiten gleichzeitig, und nur deswegen läuft es noch. Es gibt jede Menge Fehler, und die meisten davon kompensieren sich teilweise. Faßt man eine Stelle an, um eine Krankheit zu kurieren, bricht alles auseinander.

In diese drei Projekte sind allein von meinem Vorgänger so runde 10 Jahre Arbeit investiert worden, wie viel Zeit und Geld davor in das nie vollendete Monsterprojekt investiert wurde, weiß ich nicht, man munkelt von fünf Leuten und mehreren Jahren.

Die meiste Zeit dürfte fehlenden Plänen, fehlenden Spezifikationen, Workarounds, Workarounds um Workarounds, Workarounds um Workarounds um Workarounds, und nicht zuletzt Unfähigkeit geschuldet sein. Es wurde wohl auch viel gebaut, nur um gleich anschließend wieder eingestampft zu werden.

Ich habe schon einmal angeregt, das dritte Projekt komplett einzustampfen und von Grund auf sauber neu zu entwickeln und zu programmieren, aber das Problem war und ist der Aufwand dafür. Ich schätze aus dem Bauch heraus so ungefähr zwei Jahre, bis ungefähr der aktuelle Funktionsstand erreicht ist. Mindestens ein halbes Jahr wird dafür draufgehen, zu erfassen und zu dokumentieren, was das Projekt kann, was es können muß, und wie es die Daten zu verarbeiten hat -- bei allen internen Kunden.

Die bestende Software muß weiter laufen, und die Fehler müssen zügig verschwinden. Dafür haben wir vor einer Weile mal zwei oder drei Jahre angesetzt, von denen ist jetzt ein Jahr fast rum.

Für den aktuell bearbeiteten Fehler habe ich wochenlang nachgeforscht und analysiert, wie ich mit möglichst wenig Schäden das Kernproblem beseitige, aber während der Reparatur merke ich mehr und mehr, dass vermeintliche Kernproblem wieder nur ein Symptom ist. Diese Software ist bis auf das letzte Bit kaputt.

Das kann ich meinen Geschäftsführern allerdings nur schlecht erklären. "Code smell" sagt ihnen nicht viel, und selbst wenn ich mir Statistiken aus den Fingern sauge (1 Fehler in 150 Zeilen bei 100.000 Zeilen), hilft das nicht viel. Und damit das alles nicht zu einfach wird, treiben diverse Kollegen im Verbund jede Menge Politik rund um das dritte Projekt.

"Ich werd noch beloppt"

[Cheatah]

Hi,

ich brauche mal ein paar offene Ohren bzw. Augen, und vielleicht den einen oder anderen Rat.

ich kann Dir mein Mitleid anbieten - und vielleicht ein wenig Trost durch Humor:

Rat habe ich nur wenig für Dich. Sofern Du mit speziellen Problemen beauftragt wirst und abschätzen musst, wie hoch der Aufwand dazu ist, solltest Du dem Wert einen Puffer aufschlagen, den Du mit der mangelhaften Code-Qualität und der Erfahrung begründest, dass immer Folgeprobleme auftreten, die mit behoben werden müssen. Sehr wichtig ist dies:

Arbeite so, dass es angenehm für Dich ist. Lasse Dich nicht unter (Zeit-)Druck setzen. Nutze Dein Recht (und Deine Pflicht!) auf Pausen, analysiere das Problem sorgfältig und in Ruhe. Löse das Problem sorgfältig und mit einer Qualität, die mindestens Du selbst akzeptieren kannst. Es bringt weder Dir noch Deinem Arbeitgeber etwas, wenn Du Dich kaputt schindest, nur um schneller halbfertig zu sein. Mache Deinem Arbeitgeber klar, dass der Zeitaufwand aus der Code-Qualität resultiert. Eventuell kannst Du ihm, da es sich offenbar um ein langfristiges Projekt handelt, vorrechnen, dass er mit einem Refactoring der Software Zeit und Geld spart - nicht zuletzt wenn neue Features hinzugefügt werden sollen, was meiner Erfahrung nach bei dem von Dir beschriebenen Projekt tendenziell unmöglich sein dürfte. Unterstütze die letzte Idee durch mögliche Features, die Dein Arbeitgeber wünsche würde, wenn er es in Erwägung zöge.

Cheatah

[Ich werd noch bekloppt]

ich kann Dir mein Mitleid anbieten

Das brauche ich grade, danke! *schnief* ;-)

• und vielleicht ein wenig Trost durch Humor:

Das beschreibt die Situation ziemlich exakt.

Rat habe ich nur wenig für Dich. Sofern Du mit speziellen Problemen beauftragt wirst und abschätzen musst, wie hoch der Aufwand dazu ist, solltest Du dem Wert einen Puffer aufschlagen, den Du mit der mangelhaften Code-Qualität und der Erfahrung begründest, dass immer Folgeprobleme auftreten, die mit behoben werden müssen.

Richtig. Das mache ich schon.

Sehr wichtig ist dies:

Arbeite so, dass es angenehm für Dich ist. Lasse Dich nicht unter (Zeit-)Druck setzen. Nutze Dein Recht (und Deine Pflicht!) auf Pausen, analysiere das Problem sorgfältig und in Ruhe.

Das ist hier kein großes Problem, Arbeitnehmerrechte werden hier sehr wichtig genommen.

Löse das Problem sorgfältig und mit einer Qualität, die mindestens Du selbst akzeptieren kannst. Es bringt weder Dir noch Deinem Arbeitgeber etwas, wenn Du Dich kaputt schindest, nur um schneller halbfertig zu sein.

Auch das mache ich schon, ich bin zum Glück kein Frischling mehr.

Mache Deinem Arbeitgeber klar, dass der Zeitaufwand aus der Code-Qualität resultiert. Eventuell kannst Du ihm, da es sich offenbar um ein langfristiges Projekt handelt, vorrechnen, dass er mit einem Refactoring der Software Zeit und Geld spart - nicht zuletzt wenn neue Features hinzugefügt werden sollen, was meiner Erfahrung nach bei dem von Dir beschriebenen Projekt tendenziell unmöglich sein dürfte. Unterstütze die letzte Idee durch mögliche Features, die Dein Arbeitgeber wünsche würde, wenn er es in Erwägung zöge.

Gute Punkte, werde ich auf jeden Fall berücksichtigen.

Danke

[Gary]

Hi "Ich werd noch bekloppt" :-)

Wenn es der Realität entspricht, das die Software sich in einem so desolaten Zustand befindet, ist ein "Neubau" wahrscheinlich am sinnvollsten. Es ist wie mit einem Haus, das du haben möchtest. Kaufst du ein bestehendes Altes und mußt es "renovieren", legst du unterm Strich immer mehr scheinchen auf den Tisch, als bei einem Neubau, wo die Kosten überschaubar/kalkulierbar sind. Und diu weist bei einem Neubau, das alles in Ordnung ist (kommt darauf an wer baut!).

Bei so einem alten Prog, kannst du unmöglich wissen, was da noch zu Tage tritt, wenn du weiter hinein buddelst.

Lange Rede kurzer Sinn:
Wenn du dieser Überzeugung bist, solltest du mal vorsichtig beim CEO die Katze aus dem Sack lassen. Und auch wenn ich noch nicht so alt bin, habe ich doch die Erfahrung gemacht, daß du "solchen" Persönlichkeiten nur über den Geldbeutel bekommst - will heisen: Wenn es sich unterm Strich rechnet, sind die CEO's meist dafür... Wer läßt sich eine Gewinnmaximierung schon entgehen? *g*

Fakt ist:
Eine Reparatur wird mit einer nicht überschaubaren Reparaturzeit verbunden sein, weil keiner weis was noch kommt.

Eine Reparatur kann auch zu einem Faß ohne Boden werden.

Es ist nicht sichergestellt, ob die Software überhaupt zum gewünschten Erfolg führt.

Die Gefahr, das wärend der Reparatur was ausfällt, oder das ganze System zusammenbricht besteht ebenfalls.

Sollte alles gut gehen, habt ihr dann immer noch ein veraltetes System, das euch vielleicht bei zukünftigen Projekten ein Strich durch die Rechnung macht, weil so nicht kompatibel mit neuen Techniken.

Also Ohne wenn und aber - eher nicht empfehlenswert.

Wenn neu aufgezogen wird, muß der heutige und der zukünftige Bedarf berücksichtigt werden - und zwar in alle Richtungen/Bereiche des Unternemens.

Solch eine Aktion läuft meist parallel zum bestehenden System. Ist alles umgestellt, klack- Schalter um!

Dies alles, was ich erwähnte, ist wahnsinnig umfangreich. Man bildet üblicherweise Arbeitsgruppen, die die Probleme und Wünsche zusammentragen (Zahnräderprinzip). Das zusammenpfriemeln all jener Informationen ist die Aufgabe eines ordentlichen Consutings-Unternehmen. Die klären auch in wie weit "Versimplifizierungen" zu machen sind, und an welchen ecken und Enden noch Einsparungen zu realisieren wären.

Meine 50 cent...

Gruß

Gary

[Ich werd noch bekloppt]

Wenn es der Realität entspricht, das die Software sich in einem so desolaten Zustand befindet, ist ein "Neubau" wahrscheinlich am sinnvollsten. Es ist wie mit einem Haus [...]

Sehe ich mittlerweile auch so, und genau deswegen werde ich mal ein ernstes Wort mit meinem Chef reden, wie wir das der Geschäftsleitung verkaufen.

Wenn du dieser Überzeugung bist, solltest du mal vorsichtig beim CEO die Katze aus dem Sack lassen. [...] Wenn es sich unterm Strich rechnet, sind die CEO's meist dafür... [...]

Gewinnmaximierung ist bei meinem Arbeitgeber ausnahmsweise nicht Ziel des Wirtschaftens.

Ein großes Problem dieses Projekts ist, dass es ein Prestigeprojekt sein soll. Oder sagen wir besser, es war ein Prestigeprojekt bis mein Vorgänger gekündigt hat, und es muß weiterhin ein Prestigeprojekt sein.

Das hab ich im ersten Posting nicht erwähnt.

Fakt ist:
Eine Reparatur wird mit einer nicht überschaubaren Reparaturzeit verbunden sein, weil keiner weis was noch kommt. [...]

Denke ich auch.

Wenn neu aufgezogen wird, muß der heutige und der zukünftige Bedarf berücksichtigt werden - und zwar in alle Richtungen/Bereiche des Unternemens.

Natürlich.

Solch eine Aktion läuft meist parallel zum bestehenden System. Ist alles umgestellt, klack- Schalter um!

Richtig, das ist hier aber an einigen Stellen nicht ganz so einfach, wegen der anzubindenden Meßautomaten. Nicht unmöglich, nur schwierig und aufwendig.

Dies alles, was ich erwähnte, ist wahnsinnig umfangreich. Man bildet üblicherweise Arbeitsgruppen [...]

Wäre ja nicht das erste neue Projekt. Ich schätze, dass ich ungefähr ein halbes Jahr Vollzeit brauche, um eine grobe Spezifikation zusammenzusammeln, hier vor Ort und bei den "Geschwister"-Unternehmen im Verbund. Mindestens doppelt so lange, wenn ich zulasse, dass jeder Betroffene bis hin zur Putzfrau sich in die Arbeitsgruppe(n) einmischt.

Danke

[Gary]

Hi

Dies alles, was ich erwähnte, ist wahnsinnig umfangreich. Man bildet üblicherweise Arbeitsgruppen [...]

[...] Mindestens doppelt so lange, wenn ich zulasse, dass jeder Betroffene bis hin zur Putzfrau sich in die Arbeitsgruppe(n) einmischt.

Ja, die will dann womöglich eine "rosafarbene" Stempelkarte *lol*

Danke

Keine Ursache...

Gruß

Gary

[hotti]

hi,

[..]

Das kann ich meinen Geschäftsführern allerdings nur schlecht erklären.

Das da oben? Das wissen die selber. Die haben hier auch versagt, aber das werden die niemals zugeben.

Ein guter Bekannter hat auf die Frage "Gibt es in Ihrem Team jemand, auf den sie nicht verzichten können?" geantwortet: "Wenn es so jemanden geben würde, wäre ich ein schlechter Team Leader."

Ein solcher Fall jedoch liegt hier offensichtlich vor. Eine Empfehlung verkneife ich mir ;-)

Hotti

[Jeromy]

Die haben hier auch versagt, aber das werden die niemals zugeben.

Wieso auch?

Ich finde dieses Heul-post zwar ziemlich sinnbefreit, aber es zeigt mir, dass das Management komplett versagt hat.

Und es erneut macht, wenn der TO sich mit dem Wunsch nach Neuprogrammierung nicht durchsetzenm kann (vorausgesetzt, dass 1:1 korrekt ist, was er schreibt)

Gruß

[hotti]

hi,

Ich finde dieses Heul-post [..]

Tja, manchmal braucht es einen solchen erlösenden Schrei ;-)

Nurmalso nebenbei, stell Dir mal vor, es gäbe überhaupt keinen, der mit Dir redet. Irgendwann fängste an mit Selfgesprächen. Erst leise, dann lauter...

Hotti

[Ich werd noch bekloppt]

Ich finde dieses Heul-post [..]

Tja, manchmal braucht es einen solchen erlösenden Schrei ;-)

Richtig. Und nicht immer gibt es in erreichbarer Nähe jemanden, der zuhört UND versteht, warum "alles Scheiße" ist.

Nurmalso nebenbei, stell Dir mal vor, es gäbe überhaupt keinen, der mit Dir redet. Irgendwann fängste an mit Selfgesprächen. Erst leise, dann lauter...

Und irgendwann ist die Persönlichkeit so weit gespalten, das man unter zwei Namen postet und sich dabei auch noch verheddert. ;-)

Sollte einer der Forums-Moderatoren die Möglichkeit haben, den Poster-Namen in ?t=201009&m=1355785 zu ändern, bitte ich darum. Ich hab zwar hier meinen Arbeitgeber nicht genannt, aber wer sich mit der Archivsuche Mühe macht, könnte schon ziemlich gut raten.

Danke

[Alexander (HH)]

Das kann ich meinen Geschäftsführern allerdings nur schlecht erklären.

Das da oben? Das wissen die selber. Die haben hier auch versagt, aber das werden die niemals zugeben.

Die Erkenntnis stellt sich allerdings so langsam ein, jetzt wo die ganzen "Leichen" an die Oberfläche treiben ...

Ein guter Bekannter hat auf die Frage "Gibt es in Ihrem Team jemand, auf den sie nicht verzichten können?" geantwortet: "Wenn es so jemanden geben würde, wäre ich ein schlechter Team Leader."

Ein solcher Fall jedoch liegt hier offensichtlich vor. Eine Empfehlung verkneife ich mir ;-)

Wie schon gerade eben gepostet: Arbeitnehmerrechte sind hier sehr wichtig. Hier jemanden zu "beseitigen", sei es durch einen neuen Arbeitsplatz oder durch Kündigung ist extrem schwierig. Die meisten Leute hier haben mittlerweile eine Inventarnummer auf dem Hinterteil kleben. ;-)

Danke