nicht angemeldet
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"