Fachkräftemangel - Gründe und Auswege

[NotKnown]

@Errraddicator Ich gehe davon aus, dass du bei deinem alten AG 10 Jahre auf der selben Position warst? Ansonsten verstehe ich die Skepsis nicht.   Man kann durchaus 10+ Jahre bei einem AG verbringen, sofern die "Regel" beachtet wird seine Position entsprechend oft zu wechseln. Dann sehe ich da keine Gefahr der Betriebsblindheit, sondern kontinuierliche Entwicklung. Warum das schlechter sein sollte, wie jemand der ähnlich zwischen AGs hin und herspringt, muss mir der Personaler dann plausibel erklären. Ggf. sieht man andere UN-Organisation und Kulturen - aber wer evtl. stark customer-facing arbeitet, sieht das auch.

[Velicity]

@Errraddicator

Das ist korrekt aber erstmal legt man da drauf. Natürlich kann derjenige erst einmal leichtere Arbeiten ausführen. Dafür könnte man dann aber auch Remote nen Inder für ein paar Dollar am Tag nehmen. Ist natürlich nicht so als dreht man vorher Däumchen oder arbeitet nicht.

Aber so Sachen wie den typischen Kundenanruf ala bei uns steht alles kann man dann eben noch nicht analysieren und sich da groß am System lang hangeln, dafür brauch es viel tiefes Wissen. Und das brauch Zeit und Wiederholung. Ebenso Erweiterungen, wenn man das Rad nicht neu erfinden möchte, immerhin muss man wissen, was es alles schon in der Codebase gibt.

Ergo wird man bei sehr vielen Sachen noch sehr viel Anleitung brauchen. Oder sage ich es mal so, wenn alle Leute die länger dabei sind zeitgleich für zwei Wochen in den Urlaub gehen und nicht erreichbar wären und nur Leute da wären, die 1-2 Jahre da sind, dann würden bei den Kunden vermutlich so gut wie alle Standorte stehen und die Mitarbeiter hätten quasi kaum eine Möglichkeit daran was zu ändern. Wahrscheinlich bräuchte der Rest anschließend auch nicht mehr aus dem Urlaub kommen.

Klar arbeiten die Leute relativ fix mit aber es fängt eben erstmal mit leichten Hilfsarbeiten an. Vollwertige Mitarbeiter sind sie noch lange, lange nicht. Wer nach 2-3 Jahren hier gehen würde, würde so gut wie immer gehen, bevor er das System verstanden hat und alle Kunden betreuen könnte.

[allesweg]

vor 19 Minuten schrieb Errraddicator:

Keine Arbeit und kein Projekt ist so komplex oder kompliziert, dass ein fachkundiger Mensch nicht nach kurzer Zeit produktiven Mehrwert bieten kann.

Sollte, sollte... je nach hysterischem Wachstum und Protektionismus kann das leider doch passieren.

[Gast 100426]

vor 1 Stunde schrieb Errraddicator:

Ein ähnliches Szenario habe ich in meinem direkten Umfeld gehabt. Ich war 10+ Jahre bei einem AG und div. [...]

Long story short: Meine lange Betriebszugehörigkeit war ein waschechtes Handycap.

 

vor 3 Minuten schrieb NotKnown:

@Errraddicator Ich gehe davon aus, dass du bei deinem alten AG 10 Jahre auf der selben Position warst? Ansonsten verstehe ich die Skepsis nicht.   Man kann durchaus 10+ Jahre bei einem AG verbringen, sofern die "Regel" beachtet wird seine Position entsprechend oft zu wechseln. Dann sehe ich da keine Gefahr der Betriebsblindheit, sondern kontinuierliche Entwicklung. Warum das schlechter sein sollte, wie jemand der ähnlich zwischen AGs hin und herspringt, muss mir der Personaler dann plausibel erklären. Ggf. sieht man andere UN-Organisation und Kulturen - aber wer evtl. stark customer-facing arbeitet, sieht das auch.

Vielleicht wenn die Firma eine entsprechende Größe hat und man durch verschiedene Fachabteilungen springt. Ich war auch über 10 Jahre bei derselben Firma. Angefangen als Senior Entwickler und über die Jahre verschiedene zusätzliche Tätigkeiten ausgeführt, Projektleitung, Scrum Master, Product Owner und die letzten Jahre dann Teamleiter. Und ja das ist ein großes Handicap, gerade wenn man mangels Stellen in den anderen Bereichen, wieder in die Entwicklung zurück geht. Da bin ich dann eben betriebsblind und kann mich wahrscheinlich nicht mehr unterordnen oder der vorhandene Teamleiter hat Angst, dass ich gleich an seinem Stuhl säge.

Und was soll ich sagen, gewisse Vorbehalte in die Richtung hätte ich auch gehabt bei so einem Bewerber.

 

[Rabber]

vor 15 Minuten schrieb allesweg:

Sollte, sollte... je nach hysterischem Wachstum und Protektionismus kann das leider doch passieren.

Ich habe nichts von sollte geschrieben. Für meine Empfindung sind das absolute Aussagen, ohne wenn und aber.

Es gibt keine Software, die so komplex, vollständig und fehlerfrei wäre, dass ein gelernter Programmierer nicht auch nach kurzer Zeit schon etwas beitragen könnte. Es gibt immer kleine/einfache Module, einfache Bugs und einfache ToDos, welche im Backlog liegen und bisher nicht bearbeitet wurden. Das sind ideale Einstiegstickets, auch wenn die Software Millionen Zeilen Code, zig Abstraktionen und tausende Klassen beinhaltet.

Wenn ein Betrieb nicht in der Lage ist, neu angestellten Entwicklern nach kurzer Zeit für sie passende Tickets zu geben, ist das in erster Linie das Problem des Betriebs und seiner Organisation. Nicht des Entwicklers oder des zu komplexen Produkts.

[NotKnown]

vor 23 Minuten schrieb Ulfhednar:

 

Vielleicht wenn die Firma eine entsprechende Größe hat und man durch verschiedene Fachabteilungen springt. Ich war auch über 10 Jahre bei derselben Firma. Angefangen als Senior Entwickler und über die Jahre verschiedene zusätzliche Tätigkeiten ausgeführt, Projektleitung, Scrum Master, Product Owner und die letzten Jahre dann Teamleiter. Und ja das ist ein großes Handicap, gerade wenn man mangels Stellen in den anderen Bereichen, wieder in die Entwicklung zurück geht. Da bin ich dann eben betriebsblind und kann mich wahrscheinlich nicht mehr unterordnen oder der vorhandene Teamleiter hat Angst, dass ich gleich an seinem Stuhl säge.

 

Und was soll ich sagen, gewisse Vorbehalte in die Richtung hätte ich auch gehabt bei so einem Bewerber.

 

 

@Ulfhednar Das sind doch zwei völlig verschiedene Sachen.  Logisch ist das erklärungsbedürftig , wenn man von einer Führungsposition auf die Sachbearbeiterposition zurück will. Wer frag da nicht? Und was hat das mit betriebsblind zu tun? Macht keinen Sinn.  Das ein neuer Vorgesetzter "Angst" hätte, dass man am Stuhl sägen würde, halte ich für Blödsinnn. Sonst würde die Ex-TL Person sich nicht auf eine Sachbearbeiter-Stelle bewerben.  Ggf. haben merkwürdige Unternehmen nur Angst, dass die Ex-TL Person nicht mehr "leicht" steuerbar ist, weil sie bereits hinter die Kulissen geschaut hat. Aber bei solchen Unternehmen sollte man da eh nicht arbeiten.

Darüber hinaus hat es nichts mit den 10 Jahren zu tun. Da hast du dich kontinuierlich weiterentwickelt.

[TooMuchCoffeeMan]

vor 35 Minuten schrieb Velicity:

Aber so Sachen wie den typischen Kundenanruf ala bei uns steht alles

Wenn "es steht alles" eure typischen Kundenanrufe sind, dann hat eure Software bzw. das Unternehmen vermutlich viel größere Probleme als Mitarbeiter, die zu lange brauchen um sich einzuarbeiten. Aber nach allem was du immer so schreibst, klingt es ohnehin danach als ob da viel Flickwerk ohne große Dokumentation betrieben wird.

vor 42 Minuten schrieb NotKnown:

Man kann durchaus 10+ Jahre bei einem AG verbringen, sofern die "Regel" beachtet wird seine Position entsprechend oft zu wechseln.

Mir ist hier nicht ganz klar wie du "Position" definierst. Sind damit neue Aufgaben gemeint? Eine höhere Position in der bestehenden Hierarchie? Da du einen internen Wechsel offenbar mit einem externen Wechsel in der Außenwirkung gleichsetzt, gehe ich hier mal von einer komplett anderen Arbeitsumgebung mit neuen Aufgaben und anderen Kollegen aus?

 

Bearbeitet 6. August 2019 von TooMuchCoffeeMan

[Velicity]

vor 6 Minuten schrieb TooMuchCoffeeMan:

Wenn "es steht alles" eure typischen Kundenanrufe sind

Das bedeutet nicht, das alles steht, sondern liegt eben am Kunden, der das Ganze nicht analysieren kann. In der Regel werden eben die Keyuser bei der Inbetriebnahme Vorort geschult. Der Kunde stellt aber auch neues Personal ein, dann gibt es stille Post und eine neue Schulung will er nicht zahlen, da ruft er lieber 24/7 hier an. Problem liegt i.d.R. komplett woanders aber genau darum geht es, dass der Mitarbeiter die Kenntnisse brauch um das zu verstehen und diese logische Kette verfolgen kann.

Geht dann bis hin zu Firmenpolitik der Kunden und Leute, die an unser System gar nicht bei dürfen, wo du dann in bestimmten Schichten schlicht niemanden beim Kunden Vorort hast usw.

vor 7 Minuten schrieb TooMuchCoffeeMan:

Aber nach allem was du immer so schreibst, klingt es ohnehin danach als ob da viel Flickwerk ohne große Dokumentation betrieben wird.

Dem widerspreche ich nicht. Bei uns läuft eine Menge falsch, würde mir hier auch vieles anders wünschen aber das will auch keiner bezahlen. Die Kunden gehen ja selbst so noch mit den Rotstift bei. Sparen wollen am Ende alle, der Kunde, das Unternehmen etc. pp.

Raus kommt komplexer verfuschter Core, der über 20-30 Jahre gewachsen ist in einer imperativen Sprache und zusätzlich drauf eben immer stark kundenindividuelle Anpassungen und viele, viele verschiedene Schnittstellen zu anderen Anbietern.

Die Gründe sind aber auch egal. Groß was ändern kannste nicht, außer alles neu, dann darfst du mehre Welten pflegen und betreuen. Davon ab, dass du erstmal Jahre bräuchtest um dem Funktionsumfang zu implementieren und irgendwo das Geld herkommen muss.

Es ändert nix daran, dass es Firmen gibt die einfach Systeme haben, die ein paar Jährchen erfordern, bis du einen größeren Überblick hast.

[Crash2001]

 

vor 22 Stunden schrieb Systemlord:

Es scheint sich das zu bestätigen, was schon vor Jahren gesagt wurde:

Gäbe es den Fachkräftemangel in dem Ausmaß, wie immer behauptet, müssten die Gehälter für ITler durch die Decke gehen.

Spoiler: Tun sie aber nicht ?

https://www.golem.de/news/softwareentwickler-der-fachkraeftemangel-zeigt-sich-nicht-an-den-gehaeltern-1908-142796.html

Alleine schon, dass IT-Experten und Softwareentwickler gleichgestellt werden, ist da schon ein Fehler. Dazu noch die Annahme, dass nur Softwareentwickler gesucht würden. Nur weil man Softwareentwickler ist, ist man nicht zwingend ein IT-Experte. Echte "IT-Experten", also Experten auf ihrem Gebiet, haben wohl eher keine Probleme, irgendwo unterzukommen und bekommen auch gute Gehälter gezahlt.
Aktuell boomt die Security-Branchen - einerseits im Netzwerkbereich und anderseits aber auch bei der Programmierung

 

vor 2 Stunden schrieb Errraddicator:

[...] Der These, dass Mitarbeiter erst nach 1-3 Jahren wirklich zu gebrauchen wären, widerspreche ich immer wieder gerne. Natürlich findet auch nach x Jahren noch eine Entwicklung oder Lernkurve statt, aber wenn ein zuvor bereits berufserfahrener Mitarbeiter nach einigen Wochen/Monaten noch keinen produktiven Mehrwert bringt, sollte man sich fragen, ob wahlweise Mitarbeiter oder Betrieb sich ausreichend Mühe gegeben und das nötige Potenzial haben.

Keine Arbeit und kein Projekt ist so komplex oder kompliziert, dass ein fachkundiger Mensch nicht nach kurzer Zeit produktiven Mehrwert bieten kann. Auch die größte Software hat einfachere Module, Bugs und ToDos, welche ein Otto-Normalo entwickeln kann, ohne die übrigen Untiefen der Software zu kennen.

Sehe ich auch so.

vor 2 Stunden schrieb Velicity:

[...]Aber so Sachen wie den typischen Kundenanruf ala bei uns steht alles kann man dann eben noch nicht analysieren und sich da groß am System lang hangeln, dafür brauch es viel tiefes Wissen. Und das brauch Zeit und Wiederholung. [...]

Natürlich mag das jetzt bei der Softwareentwicklung noch einmal etwas spezieller sein, aber bei sinnvollen Kommentaren in Programmen, vorhandenen Dokumentationen, einer sinnvollen Einweisung des neuen Mitarbeiters in die Entwicklung und bei jemandem, der schon etwas Erfahrung damit hat, sollte es doch durchaus möglich sein, dass er sich da zurecht findet.
Unterschätze die neuen Mitarbeiter nicht - sie bräuchten zwar vermutlich länger - hinbekommen würden sie es aber eventuell dennoch.

Ich kenne das aus einem anderen Bereich (Netzwerk) z.B. auch, dass wenn man ins kalte Wasser geworfen wird, man noch am schnellsten die großen Zusammenhänge erkennt und das Problem auch behoben bekommt.
Ich war z.B. auch schon einmal neu in einem Betrieb und ab dem zweiten Tag war ich dann (ohne dass ich es vorher wusste) erst einmal für 2 Wochen komplett alleine da und durfte den Laden schmeißen. So schnell hatte ich noch nie Zugänge wie da... und irgendwie ging es auch da... ich musste mich halt bei bestimmten Sachen durchfragen und in bestimmten Programmen erst einmal einarbeiten und habe natürlich auch mal was länger gebraucht, aber das ist halt auch der Unterschied zwischen einem Junior und einem Senior. Ein Junior ist von der Situation erschlagen und ein Senior versucht sein bestes, um ein Problem dennoch zu beseitigen, auch wenn er sich in einem für ihn komplett neuen System erst einmal zurecht finden muss.

 

Bearbeitet 6. August 2019 von Crash2001

[Crash2001]

Nachtrag:
Sprechende Variablennamen und so Sachen sind natürlich auch hilfreich.
Im umgekehrten Fall kann man durch unsinnige Benamung der Variablen auch ein Programm absichtlich unübersichtlich machen.

[Velicity]

Wie es schön aussehen sollte ist keine Frage. In der Realität ist es das aber nicht. Ein Leitprojekt, das schon mit etlichen Sonderlocken, was immer als Clone für neue Projekte genutzt wird. In Summe 30 verschiedene Services, nochmal gut 20 Background Jobs drauf, Nutzereingaben von zig Geräten, hunderte Dialogmasken, verschiedene andere Gewerke die bei jeden Kunden über andere Schnittstellen direkt angesprochen sind, natürlich ohne abstrahierende Schicht dazwischen usw. Und am Ende hängen eben mehre Standorte und zig Leute dran und der Kunde kann ggf. nicht arbeiten wenn es steht.

Es ist wirklich ein verdammt riesiger komplizierter Haufen und ja das ist zum großen Teil Schuld des Unternehmens. Ist eben über 20-30 Jahre gewachsen. Wirklich fit sind hier in Summe auch nur 2-3 Leute. Richtig in allen kommt kaum wer rein, so stemmen wir 2-3 den Laden und der Rest kriegt schon sehr leichte Aufgaben und starke Anleitung, auch noch nach vielen Jahren.

Was hier falsch läuft dazu habe ich bei uns schon intern in Besprechungen mal ne 30 Seiten Ausarbeitung fertig gemacht. Mal drüber gesprochen, geändert wird aber nix, klappt auch so und ist eben alles zu zeitaufwendig. Denke zwar in Summe würde es sich lohnen, sowohl um neue Leute fixer einzuarbeiten, als auch neue Projekte schneller umzusetzen usw. Aber man denkt eben ans jetzt und da kostet es Geld, schlägt in den Umsatz rein, bedeutet keine Jahresboni usw. Sind eben alles große Baustellen.

Aber wie gesagt unabhängig was bei mir im Unternehmen abgeht, es gibt denke ich viele Unternehmen, wo es viel unwartbaren Code gibt. Wenn es dann größere Projekte sind und nicht viele kleine Produkte, dann kommt es eben zu so Problemen.

[NotKnown]

vor 3 Stunden schrieb TooMuchCoffeeMan:

Mir ist hier nicht ganz klar wie du "Position" definierst. Sind damit neue Aufgaben gemeint? Eine höhere Position in der bestehenden Hierarchie? Da du einen internen Wechsel offenbar mit einem externen Wechsel in der Außenwirkung gleichsetzt, gehe ich hier mal von einer komplett anderen Arbeitsumgebung mit neuen Aufgaben und anderen Kollegen aus?

 

Bezogen auf internen Aufstieg - bei Business Units mit eben mehrheitlich externen (Kunden)aufgaben, hast du, egal welche Ebene, ständig mit neuen Kunden/Kollegen zu tun. Beständig bleibt nur teilweise das interne Netzwerk. Aber sowas wächst erst mit der Zeit - das hat für mich aber nichts mit Erfahrung zu tun. Das muss man sich bei jedem neuen Job neu erarbeiten. Blödes durchfragen halt....dafür brauchts kein Talent.

Bearbeitet 6. August 2019 von NotKnown

[Systemlord]

vor einer Stunde schrieb Crash2001:

Nachtrag:
Sprechende Variablennamen und so Sachen sind natürlich auch hilfreich.
Im umgekehrten Fall kann man durch unsinnige Benamung der Variablen auch ein Programm absichtlich unübersichtlich machen.

Hint: Es gibt Tools wie z.B. SonarQube, die man in seine CI/CD Pipeline einbinden kann, und die einem solche Dinge gnadenlos um die Ohren hauen. Ich habe SonarQube erst vor kurzem bei uns implementiert und wurde zur Begrüßung von den gefundenen Bugs, Security Issues und Code smells erst einmal förmlich erschlagen

Und nein, UnitTests gibt es bei uns nicht, weil das historisch gewachsene Anwendungen sind, die erst einmal dafür angepasst werden müssten, wofür - überraschung - keine Zeit ist.

Bearbeitet 6. August 2019 von Systemlord

[TooMuchCoffeeMan]

vor 46 Minuten schrieb NotKnown:

Bezogen auf internen Aufstieg - bei Business Units mit eben mehrheitlich externen (Kunden)aufgaben, hast du, egal welche Ebene, ständig mit neuen Kunden/Kollegen zu tun. Beständig bleibt nur teilweise das interne Netzwerk. Aber sowas wächst erst mit der Zeit - das hat für mich aber nichts mit Erfahrung zu tun. Das muss man sich bei jedem neuen Job neu erarbeiten. Blödes durchfragen halt....dafür brauchts kein Talent.

Den Wechsel zu einer anderen Business Unit innerhalb des gleichen Konzerns würde ich jetzt nicht direkt als internen Wechsel bezeichnen, da diese i.d.R. unter eigener Bezeichnung firmieren und evtl. sogar räumlich getrennt sind.

[Systemlord]

vor 1 Minute schrieb TooMuchCoffeeMan:

Den Wechsel zu einer anderen Business Unit innerhalb des gleichen Konzerns würde ich jetzt nicht direkt als internen Wechsel bezeichnen, da diese i.d.R. unter eigener Bezeichnung firmieren und evtl. sogar räumlich getrennt sind.

Sehe ich auch so. Wenn man von Abteilung A nach Abteilung C wechselt, dann ja. Wenn aber von Tochter-Gesellschaft A zu Tochtergesellschaft C wechselt, ist das IMHO ein ganz normaler Arbeitgeberwechsel.

[NotKnown]

vor 27 Minuten schrieb TooMuchCoffeeMan:

Den Wechsel zu einer anderen Business Unit innerhalb des gleichen Konzerns würde ich jetzt nicht direkt als internen Wechsel bezeichnen, da diese i.d.R. unter eigener Bezeichnung firmieren und evtl. sogar räumlich getrennt sind.

ich meinte den Aufstieg innerhalb derselben BU.

[TooMuchCoffeeMan]

vor 1 Stunde schrieb NotKnown:

ich meinte den Aufstieg innerhalb derselben BU.

Dann kann ich dir, bezogen auf unsere Thematik, ehrlich gesagt nicht folgen.

[NotKnown]

Dann weiß ich auch nicht weiter und wir brechen hier ab ;-).

[Crash2001]

vor 21 Stunden schrieb Velicity:

[...]Was hier falsch läuft dazu habe ich bei uns schon intern in Besprechungen mal ne 30 Seiten Ausarbeitung fertig gemacht. Mal drüber gesprochen, geändert wird aber nix, klappt auch so und ist eben alles zu zeitaufwendig. Denke zwar in Summe würde es sich lohnen, sowohl um neue Leute fixer einzuarbeiten, als auch neue Projekte schneller umzusetzen usw. Aber man denkt eben ans jetzt und da kostet es Geld, schlägt in den Umsatz rein, bedeutet keine Jahresboni usw. Sind eben alles große Baustellen.[...]

Und genau das sind vermutlich auch die Firmen, die dann meckern, dass sie keine vernünftigen Fachkräfte finden für ihre unwartbaren Programme.

Lieber einmal alles komplett neu und strukturiert aufsetzen, so dass es problemlos wartbar ist, auf dem aktuellen Stand der Technik umgesetzt wird,  und die Arbeit investieren, als Jahre oder Jahrzehntelang weiter unter diesen Programmen zu leiden und keine Mitarbeiter zu finden, die sich in so etwas einarbeiten können und wollen.

[JustALurker]

vor 10 Minuten schrieb Crash2001:

Lieber einmal alles komplett neu und strukturiert aufsetzen, so dass es problemlos wartbar ist, auf dem aktuellen Stand der Technik umgesetzt wird,  und die Arbeit investieren, als Jahre oder Jahrzehntelang weiter unter diesen Programmen zu leiden

Je nachdem wie umfangreich ein Projekt ist, kann das komplette Neuschreiben fatale Folgen für das Unternehmen haben. Joel Spolsky hat das mal in einem Blogeintrag meiner Meinung nach sehr gut zusammengefasst: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[Maniska]

vor 16 Minuten schrieb JustALurker:

Je nachdem wie umfangreich ein Projekt ist, kann das komplette Neuschreiben fatale Folgen für das Unternehmen haben. Joel Spolsky hat das mal in einem Blogeintrag meiner Meinung nach sehr gut zusammengefasst: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

Und deswegen laufen bei einigen Versicherungen und Banken noch die alten Mainframes mit dem unwartbaren Cobol-Geraffel von vor dem Krieg und die Verantwortlichen sitzen eine Umstellung noch bis zur Rente aus.

Dass es irgendwann niemanden mehr gibt der 1. Cobol kann, 2. es schafft das unkommentierte Zeugs zu übersetzen und 3. kein Vermögen, das Erstgeborene vom Chef und mindestens eine Niere kostet wird gekonnt ausgeblendet.

Selbst in diesem Blogartikel schreibt er weiter unten dass man Code weiterentwickeln soll, warten soll (order wartbar machen) und nicht einfach nur weiter anbauen und draufschaufeln.

Und ja, manchmal müssen alte Zöpfe einfach fallen, niemand benötigt mehr einen Bugfix für einen Bug der nur bei Vollmond auftritt wenn Bill Gates Durchfall hat und man in Niederösterreich ein isländisches Win95 in einem nach NNW ausgerichteten 5qm Raum benutzt.

 

[Velicity]

Gibt sicher immer Risiken und ich verstehe auch meinen Chef, immerhin würde das bedeuten keine Boni usw. will auch keiner bei ohnehin schon niedrigen Gehalt drauf verzichten und eben die auch dort erwähnten Risiken.

Fängt aber bei uns schon bei der Sprache an. Starr, imperativ, langsam, sehr langsam. Überhaupt nicht testbar und von 15 Leuten trauen sich ggf. 2-3 an die komplexeren Sachen ran und selbst für uns ist das kritisch, weil ausschließen, dass am Ende gar nix mehr geht kann man schlecht.

Gerne riesige Methoden mit mehren Modi, die dann komplett andere Sachen machen usw. Alles auch immer abhängig von aktuellen State der Datenbank, was intern in den Funktionen ermittelt wird.

Fehlendes Logging oder an anderen Stellen Exzessives und Unsinniges. Viele Fehler lassen sich kaum erfassen und man darf quasi beim Debuggen 30 Minuten lang zig Variablen rauskopieren um den Fehler nachzuvollziehen. Da steht dann auch gerne mal was anderes, während man debugged.

Um viele Probleme wird nen Rucksack drum rum gemacht, weil man sich nicht traut die eigentlichen Problemstellen anzufassen. Macht das System auch immer verteilter, schlechter wartbar und langsamer. Quasi Jobs, die dann die Problemfälle finden und die kaputten Daten hinterher korrigieren..

Benutzerfreundlichkeit, Optik und Geschwindigkeit der UI ist auch kaum funktional. Kryptische Bezeichnungen aus dem Code und Stati gehen teilweise in die UI über, sprich der Benutzer muss was von Stati und Modi verschiedener Funktionen wissen.

Und das ganze Datenbankmodel ist auch wenig konsistent, was immer wieder für Fehler sorgt und weit, weit, weit mehr Verantwortung in die Hand des Entwicklers als nötig. Und das sind nur einige Probleme. Datenschutz, Backupkonzept und viele andere Sachen sind auch mäh.

Das läuft dann auch alles mit einem Leitprojekt, das den größten Funktionsumfang hat und am meisten Erweiterungen kriegt. Beim neuen Kunden wird das kopiert und angepasst. Natürlich sind da noch 10000 Sonderlocken vom letzten Kunden drin und das fliegt ein jedes mal wieder um die Ohren.

Ganz ehrlich, wäre es meine Entscheidung. Rewrite und zwar in einer anderen Sprache, alle hier an einen Tisch holen und langsam mit ein paar kleineren Projekten starten. Gucken welche Sprachen und Technologien Sinn machen. Meiner Meinung nach könnte man leichter Leute einarbeiten, leichter neue Features implementieren, leichter neue Projekte umsetzen und hätte eine deutlich höhere Kundenzufriedenheit.

Sind aber vermutlich mittlerweile Millionen von Zeilen an Code, gut 40-50 Prozesse, 20-30 Jobs, nen paar Webanwendungen, ne Android Anwendung und ne C# Anwendung und nen paar alte C Sachen.

Aber eh alles Entscheidungen über meiner Gehaltsstufe und leider nicht in meiner Hand. Vielleicht stelle ich mir das auch zu einfach vor, wobei einfach ist es jetzt auch nicht ?

Bearbeitet 7. August 2019 von Velicity

[JimTheLion]

vor 11 Minuten schrieb Velicity:

Aber eh alles Entscheidungen über meiner Gehaltsstufe und leider nicht in meiner Hand.

Macht n U-Boot draus.

Immer wenn es mal eine ruhige Stunde gibt einfach ein paar Sachen refactoren oder die verschiedenen Workflows der großen Methoden aufschreiben. Macht das ein Jahr lang, dann habt ihr irgendwann eine Grundlage bei der man sagen kann: "So, jetzt würde es sich schon lohnen wenn man ab und zu offiziell einen Tag pro Woche investiert um den Neubau voran zu treiben".

Komplexer Legacycode mags ja sein, aber steter Tropfen höhlt den Stein und irgendwann hat man die einzelnen Zustände des Systems auch dokumentiert.

[Velicity]

Klingt schön aber wie gesagt schon die Limitierungen der Sprache sind ein großes Problem. Dann der Code der nachkommt, da bräuchte es erstmal Richtlinien und Systeme, das neue Sachen anders gelöst werden, Leute müssten entsprechend erzogen werden. An die großen APIs kann man nicht ran, da darauf zig Anwendungen zugreifen und verschiedenste Leute ihre Anwendungen ändern müssen.

Davon ab kommt es da sicher auch zu Fehlern, die auch ihren Weg ins Produktivsystem finden würden. Ist der Kunde natürlich auch nicht amused, wenn ne Stelle kaputt geht, wo eigentlich nix geändert werden soll, weil man es sich wartbarer strickt.

Verbessere schon soweit ich kann aber an die Stellen, die wirklich wichtig wären, kann ich so nicht nach eigenen ermessen ran. Und sofern das keiner zahlt, ist eben Finger weg angesagt und da das alles so schon 30 Jahre klappt, geht es so auch weiter.

Ist in Summe einfach was, das man größer aufziehen müsste und wie gesagt ich sehe da auch nicht unbedingt den Wert in der aktuellen Codebase/Sprache, kannst eben nur hart verdrahten. Schon alleine weil man bei Projekten sehr unflexibel ist und nur mit Überstunden gegen an kommt und nicht einfach weitere Kollegen dazu nehmen kann, weil die mit anderen Sprachen, IDEs usw. arbeiten.

[Rabber]

@Velicity

Das Problem ist, dass Du immer das große Fass aufmachst. Kein Mensch erwartet, dass eine 20 Jahre lang weiterentwickelte Software in einem halben Jahr auf Vordermann gebracht wird. Kein Mensch kann eine 30 Seiten umfassende Ausarbeitung gebrauchen, in der steht, was alles schlecht und dass man das Unternehmen am liebsten einstampfen und neu gründen sollte. Das mag für Dich konstruktiv wirken, ist es aber nicht, weil unrealistisch. Das ist destruktiv, nicht konstruktiv.

Konstruktiv ist, in so einem Szenario, z. B. eine kanbanorientierte Herangehensweise. Sich stets 1-2 Aspekte raussuchen, welche man besser machen kann (Prozesse, Code refactoring, bestimmte Tools, Technologien, etc. konkrete Maßnahmen eben) und diese bearbeiten. Das dauert dann im Zweifel Wochen, aber dann danach habt Ihr eine greifbare Verbesserung, weil Prozess X nun um Teilschritt Y verschlankt wurde oder Fehler Z nicht mehr auftreten kann. Das Ganze macht Ihr, wie von @PVoss beschrieben, stetig und nach einem Jahr werdet Ihr sehen, dass Eure Software zwar keine neue ist, aber in so vielen Belangen besser geworden ist, dass ein deutlicher Fortschritt erzielt wurde. Nur so, mit kleinen, aber kontinuierlichen, Verbesserung kommt man solchen Monolithen und "historisch gewachsenen" Projekten bei.

Das was Du machst - das große Fass aufmachen und alles auf den Tisch knallen - provoziert Diskussionen, Streit sowie schlechte Laune und bringt das Produkt keinen Deut nach vorne. Das braucht kein Mensch. Eine kontinuierliche Verbesserung im kleinen hingegen bringt konkrete Ergebnisse, ist immer machbar und steigert Produktqualität sowie Zufriedenheit, weil die Kollegen sehen, dass es nach vorne geht.

Übrigens, nicht nur Du kennst nicht wartbaren Legacy Code. Das kennen wir wohl alle und solchen hat jede Firma zu bieten. Deshalb ist das nichts, was bei Euch nun besonders einzigartig und nicht änderbar wäre. Man muss es nur wollen. Und konstruktiv angehen.