Probleme in Uralt Legacy Software (C Programmierung)

Klingt danach als wöllte/sollte man schleunigst das Weite suchen...

UML? Lass mich raten, du kommst frisch von der Uni ...

Schlechter Code ist schlechter Code. Das hat nichts mit Management zu 
tun, sondern liegt an schlechten Programmierern. Wenn ein Koch nur 
stinkende Pampe produziert dann helfen auch die besten Management- und 
Qualitätssicherungssysteme nicht, man braucht einen besseren Koch ...

Deine Verschlimmbesserungsvorschläge würden aber alles noch mehr ins 
Chaos stürzen. C ist eine gute Sprache und wenns für den Linux Kernel 
reicht dann auch für euer Produkt.

Das erste was gemacht werden sollte ist alle Teile so weit wie möglich 
zu modularisieren und klare Zuständigkeiten schaffen. Ein Programmierer 
pro Modul. Dann sieht man auch wer Scheisse baut und wer was kann.

CORBA ist allerdings krank und sollte durch was eigenes ersetzt werden.

> UML? Lass mich raten, du kommst frisch von der Uni ...

Denke ich auch!


> -Tägliche automatisierte Unit Tests, Testmanagement einführen

Tests haben immer zwei Vorteile: Diejenigen, die die Tests designen 
müssen sich nochmal genau mit der Problemstellung befassen: Was soll das 
Ding eigentlich machen und was nicht?
Und wenn sie geschrieben sind können sie Codefehler aufspüren auch nach 
Jahren, jedoch nur für die deklarierten Testfälle.

> -weg von prozeduraler Programmierung C -> hin auf objektorientierte C++

Siehe Antwort von Heisenberg!

> -Qualitätsmanagement, Change Management, Anforderungsmanagement

Sicher nicht verkehrt und doch muss die Praxis flexibel bleiben!

> -Dokumentenmanagement-Tool einführen

Politik der kleinen Schritte, nicht alles gleichzeitig auf den Kopf 
stellen, die Hauptprobleme angehen, keinen noch grösseren Overhead 
aufbauen!

Heisenberg hat Recht. Man kann noch so tolle Tools einsetzen und 
Vorgaben machen, Qualitätssicherung etc. es steht und fällt mit den 
Programmierern. Hast du gute Programmierer, die aus Leidenschaft und 
defensiv programmieren, dann wird das Projekt erfolgreich.

Ich kenn Leute, die verstecken sich hinter so Sachen wie UML und 
verschwenden dort 90% der Zeit, anstatt einfach mal anzufangen, einen 
Prototypen zu programmieren. Wichtig sind automatische Tests, wenn 
möglich, oft gehts ja nicht so einfach.

C++ ist schon im Vorteil gegenüber C, wenn es z.B. um Fehlerbehandlung 
geht. ABER: wer C++ verwendet muß auch die Sprache sehr gut kennen, um 
nicht Mist zu bauen, womit wir wieder bei den guten Programmierern 
wären.

Ich bin's wieder ;-)

Leute, vielen Dank für eure Antworten! Hier mein Input:

D. I. schrieb:
> Klingt danach als wöllte/sollte man schleunigst das Weite suchen...

Ja, denk auch dass das nicht mehr zu retten ist.. hab schon ein neues 
Angebot und werde wechseln (in eine modernere Firma ;-) ). Es wurde 
schon vor einigen Jahren daran gedacht die Software abzulösen was meiner 
M. nach das einzig Richtige ist.. doch man ist nicht dazu gekommen, weil 
man immer wieder weiter realisiert hat, da das ja Geld bringt.

Heisenberg schrieb:
> UML? Lass mich raten, du kommst frisch von der Uni ...
>

Nö, hab danach schon etwas Berufserfahrung gesammelt. Aber ja, hörten 
immer dass das Pflicht sei. Tja Theorie schaut anders aus als Praxis. Da 
hat man keine Zeit für solche überverfrachteten Designsprachen wie UML. 
Da geb ich dir recht. Doch gehört so eine Software in derer Größe 
ordentlich geplant geb ich zu, wenn nicht UML dann halt was anderes, 
bessere genauere Abläufe etc.
> Schlechter Code ist schlechter Code. Das hat nichts mit Management zu
> tun, sondern liegt an schlechten Programmierern. Wenn ein Koch nur
> stinkende Pampe produziert dann helfen auch die besten Management- und
> Qualitätssicherungssysteme nicht, man braucht einen besseren Koch ...

Da kann ich dir nicht rechtgeben. Mgmt: Wenn man als Programmierer nicht 
in Design Workshops eingeladen ist, dann für ein (in dem Fall 
lückhaftes, schlampiges) 60-Seiten Dokument gerade mal 1 Tag Zeit hat 
das durchzulesen und dann gleich loszulegen mit der Programmierung hilft 
der beste Programmierer nichts. Oder Termine annimmt, wo man die 
Qualität gar nicht halten kann, oder immer wieder neuen Features 
zustimmt, die gar nie abgemacht wurden.
>
> Deine Verschlimmbesserungsvorschläge würden aber alles noch mehr ins
> Chaos stürzen. C ist eine gute Sprache und wenns für den Linux Kernel
> reicht dann auch für euer Produkt.
Gut da geb ich dir recht, so hab ich nicht gedacht, doch ist alles halt 
schon so verfrachtet.
>
> Das erste was gemacht werden sollte ist alle Teile so weit wie möglich
> zu modularisieren und klare Zuständigkeiten schaffen. Ein Programmierer
> pro Modul. Dann sieht man auch wer Scheisse baut und wer was kann.
Das denk ich auch. Momentan macht jeder Programmierer irgendwas und ist 
an jedem Modul beteiligt. Grundgedanke des Chefs: Wenn dann einer geht 
ist der Know how Verlust nicht so schlimm.
>
> CORBA ist allerdings krank und sollte durch was eigenes ersetzt werden.
Welche Alternativen gibt es dazu?

Konrad S. schrieb:
> Herzlich willkommen in der Realität der Softwareentwicklung. ;-)
>
> Ein komplettes Refactoring mag zwar angeraten/notwendig/unumgänglich
> sein, aber unter den Kaufleuten in der Firma - und beim Kunden - wenig
> Freunde finden. Sofern du noch in der Probezeit bist, solltest du - ähem
> - diplomatisch vorgehen. Immerhin läuft die Software offenbar soweit,
> dass diesbezügliche Kundenbeziehungen nicht vor Gericht gepflegt werden,
> ja?
ja leider, Refactoring wäre angebracht - das lernt man auch in jeder 
Software Engineering Vorlesung an der Uni - doch kostet das Zeit und 
Geld und keiner will das investieren.
Ja das stimmt, vor Gericht wird noch nichts gepflegt, aber man darf es 
nicht soweit kommen lassen.

Wieso hören die nicht auf einen jungen, dynamischen, gut ausgebildeten 
Dipl. Ing. aus der Uni? Zugegeben bin Frischfleisch, doch m.M. nach wird 
Berufserfahrung massiv überbewertet (Chef hat zB nicht studiert)...!
>
> Ein bestehendes Projekt in UML quetschen? Kannst du vergessen. Vorher
> gehst du in Rente.
ok ok, ich verstehs ja ;)
>
> Automatisierte Unit-Test sind eine gute Sache.
ja denke auch
>
> Mit C++ hast du gegenüber C auch erweiterte Möglichkeiten, Mist zu bauen
> und unverständlichen Code zu produzieren. Die Sprache ist sicher nicht
> das Problem.
>
birgt natürlich auch Gefahren, klar
> Meine Einschätzung: Der gewünschte Umbau der Software wird "im laufenden
> Betrieb" stattfinden müssen und er wird von - und mit - den Leuten
> gemacht werden müssen, die jetzt auf schon an der Software schreiben.
das wird dann erst ein Chaos werden.. aber ja, wird die einzige 
Möglichkeit sein. Oder das ganze Zeugs übernimmt irgendwann mal eine 
Fremdfirma..

Michael schrieb:
>> UML? Lass mich raten, du kommst frisch von der Uni ...
>
> Denke ich auch!
>
wie gesagt, nicht ganz, hab schon Berufserfahrung ;)
>
>> -Tägliche automatisierte Unit Tests, Testmanagement einführen
>
> Tests haben immer zwei Vorteile: Diejenigen, die die Tests designen
> müssen sich nochmal genau mit der Problemstellung befassen: Was soll das
> Ding eigentlich machen und was nicht?
> Und wenn sie geschrieben sind können sie Codefehler aufspüren auch nach
> Jahren, jedoch nur für die deklarierten Testfälle.
ganz genau, das ist essentiell!
>
>> -weg von prozeduraler Programmierung C -> hin auf objektorientierte C++
>
> Siehe Antwort von Heisenberg!
ja stimmt schon..
>
>> -Qualitätsmanagement, Change Management, Anforderungsmanagement
>
> Sicher nicht verkehrt und doch muss die Praxis flexibel bleiben!
es wird einen zusätzlichen QM Beauftragten geben müssen
>
>> -Dokumentenmanagement-Tool einführen
>
> Politik der kleinen Schritte, nicht alles gleichzeitig auf den Kopf
> stellen, die Hauptprobleme angehen, keinen noch grösseren Overhead
> aufbauen!
ja erst mit der Zeit einführen schon klar, nicht alles aufeinmal.. oder 
etwa doch bspw.mit einem Big Bang nächstes Jahr?!

... schrieb:
> Ich kenn Leute, die verstecken sich hinter so Sachen wie UML und
> verschwenden dort 90% der Zeit, anstatt einfach mal anzufangen, einen
> Prototypen zu programmieren. Wichtig sind automatische Tests, wenn
> möglich, oft gehts ja nicht so einfach.
das wollen wir auch nicht. das wäre dann das andere Negativbeispiel
>
> C++ ist schon im Vorteil gegenüber C, wenn es z.B. um Fehlerbehandlung
> geht. ABER: wer C++ verwendet muß auch die Sprache sehr gut kennen, um
> nicht Mist zu bauen, womit wir wieder bei den guten Programmierern
> wären.
ja natürlich müssen sich die Leute mit C++ auskennen, sonst geht das 
wieder ins Auge

Mark Brandis schrieb:
> Erinnert mich teilweise an meinen Job, die Beschreibung.
>
> Die Vorposter haben zum großen Teil Recht. In einem Punkt muss ich
> allerdings vehement widersprechen:
>
> ... schrieb:
>> es steht und fällt mit den
>> Programmierern. Hast du gute Programmierer, die aus Leidenschaft und
>> defensiv programmieren, dann wird das Projekt erfolgreich.
>
> Die besten Programmierer nützen nichts, wenn die Anforderungen
> unvollständig, unklar oder ganz einfach falsch sind. Am allerbesten
> ändern sie sich noch während der Projektlaufzeit des öfteren.
ganz genau
>
> Mit schlechtem Requirement Management kriegt man jedes
> Software-Projekt kaputt.

100% Zustimmung


Konrad S. schrieb:
> Mark Brandis schrieb:
>> wenn die Anforderungen
>> unvollständig
>
> Die Software ist sicher schon deutlich über zehn Jahre im Einsatz und
> wird laufend an neue Anforderungen angepasst. Also waren die
> Anforderungen zu Projektbeginn zwangsweise unvollständig.
>
> Hmm, irgendwoher kenne ich das, aber woher nur ... ;-)
Ganz genau, ganz genau, du verstehst was ich meine.. anscheinend 
arbeitest du ganz in einem ähnlichen Umfeld...
Ich denke dass so eine Berufserfahrung in diesem Umfeld nicht viel 
nutzt. Ist auch die Meinung einiger anderer Firmen.

Zum Thema...

Konrad S. schrieb:
> schlumpfcoder schrieb:
>> Zugegeben bin Frischfleisch, doch m.M. nach wird
>> Berufserfahrung massiv überbewertet (Chef hat zB nicht studiert)...!
>
> Er hat nicht studiert, mag sein. Aber immerhin hat er eine Firma, die
> mehreren Leuten einen Arbeitsplatz bietet und er hat eine verkorkste
> Software, mit der er sich immer noch am Markt behaupten kann. Das
> müsstest du (mit Studium) erstmal nachmachen - mit einer Software, die
> sich auch so lange auf dem Markt behaupten kann und nach der Zeit immer
> noch nicht verkorkst ist. "Mensch, welcher Volltr... hat denn diesen
> vorsintflutlichen Sch... programmiert? Ach, so ein Zufall, der heißt
> genauso wie mein Chef!" ;-)

Ja das ist wohl war, das hat er aber nicht allein geschafft, Chef ist 
mit Abteilungsleiter gemeint, nicht der CEO..

Früher hat man wahrlich so programmiert, da mag das noch Standard 
gewesen sein, ist aber heute überholt. Früher war es noch sehr kleine 
Softwareklitsche, da konnte man sich das Basteln leisten und noch kleine 
Gewinne erwirtschaften.

Naja, die Software von der wir reden wird bei einem Grosskunden 
eingesetzt. Aber auch nur (!) weil die davon abhängig sind. Das alles 
durch Fremdsoftware abzulösen würde Jahre dauern und der Aufwand und die 
Kosten wären immens. So sind sie an die Firma gebunden. Denen bleibt gar 
nix anderes übrig. Verstehste? Das Ding ist immer größer geworden im 
Laufe der Jahre.


>
>> Oder das ganze Zeugs übernimmt irgendwann mal eine
>> Fremdfirma..
>
> ... die dann erstmal überhaupt keine Ahnung von der Materie hat und
> "unbefangen" an die Sache herangehen kann. Ja, nee, is' klar. ;-)

Sicher ists nicht einfach, aber wäre evtl mit modernen 
Softwareentwicklungsmethoden und tiefes Prozesswissen in vielen 
Bereichen möglich.
>

>> Ich denke dass so eine Berufserfahrung in diesem Umfeld nicht viel
>> nutzt.
>
> Der Berufserfahrene sagt: "Uiuiui, da haben wir ne Menge zu tun. Gibt's
> schon einen Plan?"
> Der Andere sagt: "Bloß weg hier!" <wink>Zaunpfahl</wink> ;-)
Tja, so könnte ich schon denken . Aber zu welchen Preis? Diese Firma 
bietet mir keine Aufstiegsmöglichkeiten oder gutes Gehalt mehr.. Anders 
meine neue Firma, da mache ich einen ordentlichen Sprung, werde 
gefördert usw. Habe in 4 Jahren keine einzige Weiterbildung machen 
können!
>
>> Ist auch die Meinung einiger anderer Firmen.
> Meinst du die Firmen, die diese 50-jährigen Gruftis entsorgen oder die
> Entlassungen im Tausender-Pack aussprechen? Prima Idee, da anzufangen.
> Da ist Schwung drin, das hat Zukunft!
> (Hier bitte ein Emoticon nach persönlichem Geschmack einfügen.)
Nö, innovative, größere und erfolgreiche Firmen
>
> Ein ausgewogenes Verhältnis zwischen "alten Hasen" und "Frischlingen" -
> und was dazwischen liegt - ist langfristig überlebensfähig. Beim einen
> Extrem stirbt das Know-How aus, beim anderen Extrem ist erstmal gar
> keines vorhanden. Das Studium bringt Wissen, die Berufserfahrung bringt
> Können - eben Know-How.
>
Ja natürlich, auch die alten Hasen können von der frischen Ausbildung 
von Jungen Absolventen auch noch einiges lernen, und die Jungen lernen 
wiederum von der jahrelangen "Erfahrung". Wäre eigentlich das 
anzustrebende Ideal.

@Tilo Renz sehr gute Erklärung & Definition - Technical Debt - 
beschreibt das Ganze sehr genau! Danke

schlumpfcoder schrieb:
> -striktes UML Design ist Pflicht (ist aber nicht immer möglich bei
> unrealistischen Terminvorgaben, deswg müsste das Management ein Projekt,
> bei dem die Firma die Qualität nicht sicherstellen kann, absagen.)

UML kannst du knicken. Das ist wie Selbstbefriedigung. Du bewegst dich 
zwar viel, aber im Endeffekt hast du am Ende vom Tag noch immer nichts 
programmiert. Jegliche Agilität bei Anpassungen geht verloren.

Nichts spricht gegen einfache Skizzen die verwaltet werden, aber UML in 
voller Blüte würde euch den Betrieb lahmlegen.

> -Eine Softwareanpassung muss zunächst immer eine UML Anpassung
> vorausgehen

Jo, am besten noch formale Spezifikation mit Z und Object-Z.

Hat so viel mit der Realität zu tun wie die kalte Fusion: Wird viel 
drüber geredet, jeder sagt er beherrsche es, im Endeffekt kriegt es eh 
keiner hin.

> -Tägliche automatisierte Unit Tests, Testmanagement einführen

Zentrales Buildmanagment.. wer verwendet das heute noch nicht?

> -weg von prozeduraler Programmierung C -> hin auf objektorientierte C++
> Programmierung um möglichst zu abstrahieren und keine elendslangen C
> Files zu produzieren, die keiner mehr lesen kann, mehr modularisieren

C++ in voller Blüte ist, aufgrund der komplexen Semantik und Syntax, 
extrem schwierig zu verstehen. Du brauchst langjährige Erfahrung um sie 
zu beherrschen, Entwickler lassen sich das gut bezahlen.

C ist da relativ übersichtlich.

> -Qualitätsmanagement, Change Management, Anforderungsmanagement
> einführen

Klar. Elementar für eine produktive Teamarbeit.

> -Dokumentenmanagement-Tool einführen (gibts auch nicht, die Files liegen
> alle in word oder pdf auf irgendwelchen Laufwerken rum)

Eher Versionsmanagement mit SVN oder GIT.


Ok, meine ganz persönliche Empfehlung:

Heute noch nach einem neuen Job umschauen. Man möchte dich in einem 
grauenvollen Legacy-Projekt verheizen.

atm schrieb:

> UML kannst du knicken. Das ist wie Selbstbefriedigung. Du bewegst dich
> zwar viel, aber im Endeffekt hast du am Ende vom Tag noch immer nichts
> programmiert. Jegliche Agilität bei Anpassungen geht verloren.
>
> Nichts spricht gegen einfache Skizzen die verwaltet werden, aber UML in
> voller Blüte würde euch den Betrieb lahmlegen.
Hast recht.. in der Praxis sieht's wieder anders aus.. Man lernt das 
halt so auf der Uni..
>
>> -Eine Softwareanpassung muss zunächst immer eine UML Anpassung
>> vorausgehen
>
> Jo, am besten noch formale Spezifikation mit Z und Object-Z.
;-)
>
> Hat so viel mit der Realität zu tun wie die kalte Fusion: Wird viel
> drüber geredet, jeder sagt er beherrsche es, im Endeffekt kriegt es eh
> keiner hin.
Leider ja.
>
>> -Tägliche automatisierte Unit Tests, Testmanagement einführen
>
> Zentrales Buildmanagment.. wer verwendet das heute noch nicht?
Bei uns gibts noch kein richtiges Testmanagement. Getestet wird nebenbei 
vom Entwickler ,wenns die Zeit zulässt, am Ende des entwickelten 
Arbeitspakets. Wenn nicht macht man halt nachher Bugfixes in der kurzen 
Kundentestphase vorm Release.
>
>> -weg von prozeduraler Programmierung C -> hin auf objektorientierte C++
>> Programmierung um möglichst zu abstrahieren und keine elendslangen C
>> Files zu produzieren, die keiner mehr lesen kann, mehr modularisieren
>
> C++ in voller Blüte ist, aufgrund der komplexen Semantik und Syntax,
> extrem schwierig zu verstehen. Du brauchst langjährige Erfahrung um sie
> zu beherrschen, Entwickler lassen sich das gut bezahlen.
>
> C ist da relativ übersichtlich.
ok gib dir recht
>
>> -Qualitätsmanagement, Change Management, Anforderungsmanagement
>> einführen
>
> Klar. Elementar für eine produktive Teamarbeit.
das wird erst jetzt (!!) nach 10 jahren mal richtig eingeführt 
(unabhängige Testabteilung)
>
>> -Dokumentenmanagement-Tool einführen (gibts auch nicht, die Files liegen
>> alle in word oder pdf auf irgendwelchen Laufwerken rum)
>
> Eher Versionsmanagement mit SVN oder GIT.
mom. wird dort CVS verwendet, was nicht atomar und sehr veraltet ist


> Ok, meine ganz persönliche Empfehlung:
>
> Heute noch nach einem neuen Job umschauen. Man möchte dich in einem
> grauenvollen Legacy-Projekt verheizen.

Ganz genau war auch mein Gedanke. Ich habe tatsächlich schon einen neuen 
Job! Bin froh dass ich dort wegbin :)

Das beschreibt es sehr exakt:

http://de.wikipedia.org/wiki/Big_Ball_of_Mud

Wäre auch ein alternativer Titel gewesen für diesen Thread.

Auszug:
„Ein Big Ball of Mud ist ein planlos strukturierter, weitläufiger, 
schlampiger, mit Klebeband fixierter und Ballenpressdraht 
zusammengeschnürter Spaghetti-Code Dschungel. Derartige Systeme 
tendieren zu ungehemmtem Wachstum und benötigen laufende Betreuung. Die 
in diesen Systemen enthaltenen Informationen sind wahllos über die 
entferntesten Elemente verteilt, oft bis zu dem Punkt, wo fast alle 
wichtigen Informationen global oder dupliziert sind. Die Architektur 
derartiger Systeme wurde vielleicht nie richtig definiert, und wenn doch 
ist sie bis zur Unkenntlichkeit erodiert. Programmierer mit einem Fetzen 
architektonischer Sensibilität meiden derartige Sümpfe. Nur diejenigen, 
die sich nicht um Architektur scheren und vielleicht sogar gerne Tag für 
Tag mühsam Löcher in undichten Deichen stopfen, arbeiten gerne mit 
solchen Systemen.“
– Brian Foote, Joseph Yoder: Big Ball of Mud. Fourth Conference on 
Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, 
Illinois, September 1997[1]

Ist heute auch noch 100% gültig für das Projekt und überhaupt allgemein 
auch. Zudem hat die Software auch ihre Anfänge in den 90ern und es wurde 
bis heute so weiterdahin im Sumpf programmiert und gebugfixt..

Mark Brandis schrieb:
> Die besten Programmierer nützen nichts, wenn die Anforderungen
> unvollständig, unklar oder ganz einfach falsch sind. Am allerbesten
> ändern sie sich noch während der Projektlaufzeit des öfteren.

Man sollte bestrebt sein, vollständig zu verstehen und innerlich 
zusammenzufügen, was der Kunde will, bevor man loslegt. Wenn es 
Unvollständige oder unklare Anforderungen oder Widersprüche gibt, so 
werden die dadurch offenbar. Dafür muss man fragen, fragen und fragen 
und immer wieder nachhaken, solange irgendetwas nicht vollständig 
beschrieben ist.

schlumpfcoder schrieb:
> Wenn man als Programmierer nicht
> in Design Workshops eingeladen ist, dann für ein (in dem Fall
> lückhaftes, schlampiges) 60-Seiten Dokument gerade mal 1 Tag Zeit hat
> das durchzulesen und dann gleich loszulegen mit der Programmierung hilft
> der beste Programmierer nichts.

Ein erfahrener Programmierer nimmt sich den Tag (im Schnitt 8 
min/Seite), notiert alle Fragen, die durch das Dokument aufgeworfen 
werden, und löchert damit den Kunden/Chef. Dass man nicht sinnvoll 
anfangen kann, solange die Fragen nicht geklärt sind, muss der einsehen. 
Der wird einen dann an Leute verweisen, die das System/die Anforderungen 
kennen. Solche sind (meiner Erfahrung nach) oft unkooperativ und zögern 
die Herausgabe von Wissen gerne heraus, indem sie einen die Zusendung 
von Unterlagen per Mail zusagen. Damit ist der schwarze Peter erst mal 
woanders und man hat Zeit, sich schon mal in die weniger problematische 
Teilgebiete einzuarbeiten.
"Herr Schlumpfcoder, haben sie jetzt endlich angefangen?"
"Ich warte noch auf Unterlagen von Herrn Mustermann und nutze die Zeit, 
die Umsetzung der geklärten Teile zu planen."

Die einzig sinnvolle Vorgehensweise ist eine Umstellung auf SAP.

Entscheider schrieb:
> Die einzig sinnvolle Vorgehensweise ist eine Umstellung auf SAP.


Acho? Nach den Schilderungen von schlumpfcoder dachte ich, er arbeitet 
für SAP? ;-)

Jan schrieb:
> Entscheider schrieb:
>> Die einzig sinnvolle Vorgehensweise ist eine Umstellung auf SAP.
>
>
> Acho? Nach den Schilderungen von schlumpfcoder dachte ich, er arbeitet
> für SAP? ;-)

Nein, nein, nein, falsch verstanden ;) Die "Software" wo ich 
mitentwickle, ist Lichtjahre entfernt von SAP, der Modularisierung und 
dem ganzen Customizing.

Der Kunde verwendet schon SAP, aber diese Software agiert einen Level 
darunter und über eine Schnittstelle senden wir die Daten zu dem Kunden 
ERP/SAP.

Wär aber ein guter Vorschlag, gleich alles in SAP zu realisieren und zu 
integrieren! Wer weiss, viell. wird es einmal auch dazu kommen.

@schlumpfkoder

Ein Punkt ist in der Diskussion noch nicht angesprochen
worden: Wie denken denn die Kollegen/Chefs selbst über ihre
Entwicklungstechnik?

> keiner mehr lesen kann, weil einfach alles reingeknallt wird.

> Nur ab und zu bei komplizierteren Programmen wird mal
> ein Ablaufdiagramm erstellt.

> Es wurde sogar (!!) eine externe Beraterfirma (Drittfirma)
> vom Kunden beauftragt,

Werden deren Ratschläge denn umgesetzt?

Und:

> Habe in 4 Jahren keine einzige Weiterbildung machen können!

Du allein oder überhaupt keiner? Bei mir bildet sich der
Eindruck, als ob die Leute mit ihrer Vorgehensweise sogar
ganz gut leben können und auf Verbesserungen nicht wirklich
neugierig sind. Solche Leute habe ich auch schon kennengelernt,
sie werden mitunter auch "Cowboy coders" genannt.
Mit Deinen Änderungsvorschlägen kannst Du Dich da sogar eher
unbeliebt machen.

Falls das zutreffen sollte... und:

> Momentan macht jeder Programmierer irgendwas und ist an
> jedem Modul beteiligt.

dann wird das mit dem schrittweise Sanieren nichts. Und
Neuentwickeln sehe ich auch als praktisch unmöglich an, ich
vermute nämlich, dass die einzige Spezifikation für die
Software die Software selbst ist. Und die ändert sich nach
Deinen Worten ja ständig...

Meine Antwort auf die Frage, was Du tun kannst, hast Du Dir ja
schon selbst gegeben.

KeinLichtAufGing schrieb:
> @schlumpfkoder
>
> Ein Punkt ist in der Diskussion noch nicht angesprochen
> worden: Wie denken denn die Kollegen/Chefs selbst über ihre
> Entwicklungstechnik?
>

Also.. der IT-Manager selbst kann nicht programmieren, und versteht auch 
nicht, was eine gut funktionierende Softwareentwicklung braucht. Er 
selbst hat in seinem Leben noch nie einen Strich programmiert , sondern 
er meint sogar, er braucht davon nix wissen, denn das wissen schon seine 
Teamleiter. Er macht einen typischen Fehler im Controlling - nach dem 
Leitsatz "Management by Numbers" - betrifft auch das sogenannte 
Antipattern: siehe alles hier: http://de.wikipedia.org/wiki/Anti-Pattern

Auch gibt es einige Projektleiter, die dann in der IBN tätig sind (gibt 
zuviele Chefs in der Firma) und typisches Crocodile Management 
betreiben: "Der Projektleiter ist nur teilweise im Projekt anwesend und 
kümmert sich nur um Details die der Projektmitarbeiter nicht erledigt 
hat: auftauchen, Maul aufreißen, abtauchen" :-D

Die meisten Kollegen sind eh schon weg, die paar 2-3 älteren die es noch 
ausgehalten haben, oder sonst nix gefunden haben , sind halt zu 
Teamleitern "befördert" worden. Sie sind die einzigen die sich noch 
irgendwie in dem Chaos auskennen, da schon ca. 10 Jahre von denen jeder 
dabei ist. Die anderen (so ca. 6-7 Leute) sind ca. maximal 2 Jahre in 
der Firma (zähl mich da dazu, bin aber bald weg). Wir sprechen hier nur 
von der Abteilung die die Software für das bestimmte Projekt macht (ist 
ein langjähriger Kunde, eben schon seit über 10 Jahren). Der ist nämlich 
auch sehr leidensfähig, aber bei denen herrscht auch nicht minderes 
Chaos)

Die kriegen halt soviel Druck von der Geschäftsleitung, dass sie es 
teilweise einfach machen, und zusätzlich haben die keinerlei Gespür für 
Softwaretesting und Design. Absprachen mit den Kunden werden nur 
halbherzig geführt, für Design bleibt keine Zeit, man "hackt" am besten 
gleich los, so sieht man gleich Ergebnisse, was wiederum ein grosser 
Fehler ist.

Weiterbildung wird als unnötiger Luxus gesehen. Hab mich sogar blöd 
anglotzen lassen müssen für meine Einführungsschulungen und blöde 
Kommentare "a la und, jetzt bist du aber gut geschult oder?" Zusätzlich 
existiert irgendwie eine Selbstverständlichkeit, dass man sich sofort in 
X Prozesse einarbeiten kann und wenn Fehler auftreten , die so bald wie 
möglich beheben kann, und am besten gleich einen Bugfix einspielen. 
Jedoch existiert nahezu keine Doku, dafür aber ein schrecklich 
geschriebener Code. Wer da reingreift, greift sprichwörtlich in die 
K...cke , wenn man was anpasst, kann man sicher sein, dass es irgendwo 
anders wieder aufschlägt.
Irgendwie ist das denen bis jetzt nicht ins Hirn gegangen. A la "Das ist 
halt so" "Heute ist es überall nicht mehr leicht, der Druck usw.. ". 
Durch mich sind diese Leute draufgekommen, dass es nix bringt, sofort 
irgendwas zu entwickeln und schnell zu hacken. Bin sogar kritisiert 
worden deswegen. Das haben sie aber bald wieder zurückgenommen, da sie 
gesehen haben, wie effizient und genau meine Arbeitsweise (in diesem 
Saufhaufen dazu!) war.
Sicher, ich hab halt länger gebraucht zum Testen, Entwicklen, 
Dokumentieren aber der Kunde war zufrieden.
Von den Teamleitern hat noch keiner eine Uni von innen gesehen.. Es ist 
traurig.. Könnte Bücher schreiben was da alles vorfällt..

Und das war noch nicht alles .. Das fing dann auch noch an mit IBN die 
sich über 1 Jahr hinziehen, Doppelschichten übernehmen, wegen so vielen 
Fehlern, wenigen Leuten, so schnell wie möglich produktiven Source vor 
Ort beim Kunden reinhacken und kompilieren, dass das System 
weiterläuft.. Das Ergebnis ist dann ein System mit Baustellencode, wo 
Qualität nicht mal im entferntesten zählt, es soll einfach irgendwie 
funktionieren, denn Feuer ist am Dach..

Und das ist nur die Software.. Wenn ich mal bei den automatisierten 
Geräten anfange .. könnte ich noch weiter erzählen.. Unfälle, einen 
Brand hats gegeben, jeden Tag 80 HW-Fehler und mehr..


>
>> Es wurde sogar (!!) eine externe Beraterfirma (Drittfirma)
>> vom Kunden beauftragt,
>
> Werden deren Ratschläge denn umgesetzt?

Ich weiß es nicht, wahrscheinlich zukünftig schon.. der Kunde hat die 
eingeschaltet und die Firma will jetzt natürlich auch nicht blöd 
dastehen.. Zumindest wird ab nächstes Jahr mal die schon bestehende 
Qualitätsabteilung auch für unseren Kunden eingesetzt, zuletzt haben die 
Entwickler immer nur selbst ein bisschen getestet, wenn es die Zeit 
zugelassen hat (für Doku bleibt ja sowieso keine Zeit)
>
> Und:
>
>> Habe in 4 Jahren keine einzige Weiterbildung machen können!
>
> Du allein oder überhaupt keiner? Bei mir bildet sich der
> Eindruck, als ob die Leute mit ihrer Vorgehensweise sogar
> ganz gut leben können und auf Verbesserungen nicht wirklich
> neugierig sind. Solche Leute habe ich auch schon kennengelernt,
> sie werden mitunter auch "Cowboy coders" genannt.
> Mit Deinen Änderungsvorschlägen kannst Du Dich da sogar eher
> unbeliebt machen.
>
Die Teamleiter machen schon ab und zu eine Weiterbildung. Die Entwickler 
nicht, da man Angst hat, in sie zu investieren, da der IT Manager 
annimmt, sie hauen ja eh bald wieder aus der Firma ab. Was genau wieder 
auf das sogenannte Antipattern "Management by Numbers" zutrifft:

"Management nach Zahlen (engl. Management by numbers)
Übermäßiger Schwerpunkt auf quantitativem Management, also Fokus auf 
Kosten und vernachlässigen anderer Faktoren wie Qualität. Hier werden 
Programmierer gerne als „Gebrauchsgut“ (engl. commodity) gesehen und als 
austauschbar betrachtet. Sehr kurzfristige Denkweise, die außen vor 
lässt, dass fehlende Mitarbeitermotivation und/oder 
Mitarbeiterfluktuation dem Unternehmen mittel- bis langfristig 
wesentlich teurer kommen als eine kurzfristige Investition in diese"

Ganz genau! Das hast du gut gesagt - das sind richtige "Cowboy coders". 
Habe mich in der Tat mit Änderungswünschen unbeliebt gemacht. A la " zu 
teuer, nein das hilft nichts, das hat keinen Sinn, für das bleibt keine 
Zeit, das ist unnötig" usw.

> Falls das zutreffen sollte... und:
>
>> Momentan macht jeder Programmierer irgendwas und ist an
>> jedem Modul beteiligt.
>
> dann wird das mit dem schrittweise Sanieren nichts. Und
> Neuentwickeln sehe ich auch als praktisch unmöglich an, ich
> vermute nämlich, dass die einzige Spezifikation für die
> Software die Software selbst ist. Und die ändert sich nach
> Deinen Worten ja ständig...

Ja, ganz genau. Das wird nichts. Neuentwicklung sowieso nicht. Ja , 
genau das ist die einzige Spezifikation. Und laut denen heisst es auch 
der Code ist die beste Dokumentation. (Auch auskommentierter , toter 
Code wird gerne eingecheckt, man hat Angst, man könnte es ja irgendwann 
nochmal brauchen, es ist wie ein Wespennest, wo man reinsticht, wenn man 
da was entwickelt)
>
> Meine Antwort auf die Frage, was Du tun kannst, hast Du Dir ja
> schon selbst gegeben.

100% richtig. Die Gesichter waren schön anzusehen, wie ich denen das 
gesagt hab, hat ja laut Chef "keiner damit rechnen können" . Ha, das ich 
nicht lache. Jetzt müssen sie wieder 3 neue Leute einlernen, es gehen 
neben mir noch 2 Leute.

Aber wisst ihr was ich wirklich gerne tun würde? Denen eine schöne Liste 
vorlegen, wie man richtig vorgehen kann. Ich war ja auch in anderen 
Firmen vorher.

Dann würd ich dem Chef und Teamleitern so gerne meine Meinung sagen.

-Wie richtige Softwareentwicklungsmethoden aussehen
-Wie man richtig solche Projekte in den Griff kriegt und managt.
Hab mir da nämlich schon ein paar schöne Seiten zu dem Thema 
zusammengeschrieben..

Ob ich mir da Ärger einhandle? Besserwisserei , Klugsch...erei und evtl 
sogar ein schlechtes Dienstzeugnis?
Hab klugerweise schon ein Zwischenzeugnis verlangt damals. Jetzt können 
sie mir gar kein schlechtes mehr geben, da das dann auch für die Firma 
wiederum blöd aussieht :-D Die sind angewiesen auf mich. Einer hat mir 
sogar gesagt, ich soll bitte dann später nicht über die Firma schimpfen, 
wenn ich weg bin. Ok es gibt ja auch ein paar nette Leute auch dort ;-)

Ok jetzt hör ich auf, war schon ein bisschen zu lang. Falls du es ganz 
durchgelesen und geschafft hast bis hierher, danke fürs Interesse und 
ich bin gespannt auf deine Meinung ;-)

schlumpfcoder schrieb:
> Dann würd ich dem Chef und Teamleitern so gerne meine Meinung sagen.
>
> -Wie richtige Softwareentwicklungsmethoden aussehen
> -Wie man richtig solche Projekte in den Griff kriegt und managt.
> Hab mir da nämlich schon ein paar schöne Seiten zu dem Thema
> zusammengeschrieben..

Nachtrag. bei der Codebasis ist wahrsch. eh nicht mehr viel zu retten.
Aber ein paar Management und SW Tipps hätte ich schon ;)

schlumpfcoder schrieb:
> KeinLichtAufGing schrieb:
>> @schlumpfkoder
>>
>> Ein Punkt ist in der Diskussion noch nicht angesprochen
>> worden: Wie denken denn die Kollegen/Chefs selbst über ihre
>> Entwicklungstechnik?

Gut dass du das angesprochen hast, hab mir mal den Frust wegschreiben 
können, obwohls mich jetzt eh nicht mehr tangieren sollte ! ;)

schlumpfcoder schrieb:
>>> Momentan macht jeder Programmierer irgendwas und ist an
>>> jedem Modul beteiligt.
>>
>> dann wird das mit dem schrittweise Sanieren nichts. Und
>> Neuentwickeln sehe ich auch als praktisch unmöglich an, ich
>> vermute nämlich, dass die einzige Spezifikation für die
>> Software die Software selbst ist. Und die ändert sich nach
>> Deinen Worten ja ständig...



Putzen, Putzen, Putzen.
Auch wenn mehrere Programmierer am gleichen Projekt arbeiten kann man 
man
Strukturen vereinheitlichen, sich auf Pattern einigen, Wildwuchs 
ausräumen, Automaten aufräumen.....
Ich kenne das nur zu gut - ist ein steiniger Weg, kann aber auch viel 
Spass und Erfolgerlebnisse bringen. Egal ob C C++ was auch immer, 
putzen, ausmisten und aufräumen geht immer - und es bringt was für die 
Softwarequalität.

Und ehrlich - ob das jetzt cvs oder svn oder git ist - daran soll es 
nicht liegen, wenn die Sourcen schlecht sind. Sicher - alles moderne ist 
besser ;-), aber wir haben Jahrlang mit CVS gelebt - auch damit kann man 
sauberen Code verwalten.

Ich überlege mir ob schlumpfcoder hier nur herumtrollt (seine
Beiträge sind dafür allerdings untypisch lang). Bei
Vorkommnissen wie

> Geräten anfange .. könnte ich noch weiter erzählen.. Unfälle, einen
> Brand hats gegeben, jeden Tag 80 HW-Fehler und mehr..

müsste eigentlich jedem - auch unstudiertem - Vorgesetzten klar
sein, wie ernst die Lage ist. Den Kunden zu verlieren wäre da noch
ein "harmloses" Ende.

@schlumpfkoder:
Du vermittelst - zumindest mir - das Bild einer Belegschaft aus
möglicherweise unfreiwilligen Seiteneinsteigern, die sich im
Selbststudium bis auf das Niveau eines "einfachen Programmierers"
gebracht haben. Das reiche für die tägliche Arbeit so aus, an
mehr hätten die Leute kein Interesse - und die Chefs anscheinend
auch nicht.

>  A la "Das ist halt so"

Desinteresse/Resignation.

> Die meisten Kollegen sind eh schon weg, die paar 2-3 älteren die es noch
> ausgehalten haben, oder sonst nix gefunden haben ,

Und nach Deiner Beschreibung scheint die Geschäftsleitung auch
keine besseren Leute bekommen zu können (wollen?). Die machen die
beschriebenen Verhältnisse nämlich nicht unbedingt mit. Dann
stabilisiert sich diese Praxis selbst.

> Dann würd ich dem Chef und Teamleitern so gerne meine Meinung sagen.

Ich fürchte, dass die niemand hören will. Wenn das Zeugnis nicht nach
dem Motto entsteht "Schreiben Sie sichs selbst, wir unterzeichnen
alles" halte ich die diesbezügliche Sorge auch für berechtigt. Auch
ohne viele Worte hast Du Dich durch die Kündigung unmissverständlich
ausgedrückt - vermutlich mehr als wenn Du eine lange Rede gehalten
hättest.
Kurz gesagt: Ich würde es lassen.

NurEInGast schrieb:
>
> Putzen, Putzen, Putzen.
> Auch wenn mehrere Programmierer am gleichen Projekt arbeiten kann man
> man
> Strukturen vereinheitlichen, sich auf Pattern einigen, Wildwuchs
> ausräumen, Automaten aufräumen.....
Yep, das ist wahrscheinlich das einzige was hier noch hilft. Am besten 
mal ein komplett eigener Release der nur Bereingungen (alten, toten Code 
weg, Refactoring, etc) enthält. Und da drauf das ganze Team stürzen.


> Und ehrlich - ob das jetzt cvs oder svn oder git ist - daran soll es
> nicht liegen, wenn die Sourcen schlecht sind. Sicher - alles moderne ist
> besser ;-), aber wir haben Jahrlang mit CVS gelebt - auch damit kann man
> sauberen Code verwalten.
Yep, kann man, wenn man auch fähige Mitarbeiter und nicht ein komplettes 
Chaos hat. Nichtsdestotrotz ist CVS veraltet und nicht atomar.



Keinlichtaufging schrieb:
> Ich überlege mir ob schlumpfcoder hier nur herumtrollt (seine
> Beiträge sind dafür allerdings untypisch lang). Bei
> Vorkommnissen wie
>
>> Geräten anfange .. könnte ich noch weiter erzählen.. Unfälle, einen
>> Brand hats gegeben, jeden Tag 80 HW-Fehler und mehr..
>
> müsste eigentlich jedem - auch unstudiertem - Vorgesetzten klar
> sein, wie ernst die Lage ist. Den Kunden zu verlieren wäre da noch
> ein "harmloses" Ende.

Hallo lieber "Keinlichtaufgang" !!

Nein, du hast es erfasst, ich trolle nicht! Das hab ich tatsächlich so 
erlebt, und ja, deswg. meine langen Beiträge, um mir den Frust von der 
Seele zu schreiben.

Ja genau, dass die Lage ernst ist, wissen die hoffentlich. Diese sogen. 
Projektleiter betreiben aber weiterhin "Crocodile Management": 
auftauchen, Maul aufreissen, abtauchen :-D

Sie versuchen es auch, aber sie sind völlig überfordert, diese für diese 
Projektverhältnisse viel zu kleine Firma ist als Generalunternehmer für 
ein zu großes, komplexes Projekt aufgetreten, alles muss schnell gehen, 
jeder ist überfordert.

>
> @schlumpfkoder:
> Du vermittelst - zumindest mir - das Bild einer Belegschaft aus
> möglicherweise unfreiwilligen Seiteneinsteigern, die sich im
> Selbststudium bis auf das Niveau eines "einfachen Programmierers"
> gebracht haben. Das reiche für die tägliche Arbeit so aus, an
> mehr hätten die Leute kein Interesse - und die Chefs anscheinend
> auch nicht.
Ja, einer war mal Dachdecker vorher, der hat dann halt ein 
Informatiklehrgang besucht usw. - ist aber von allen noch der Beste.
Der andere, ein Teamleiter, ist so sozial inkompentent, das es kracht. 
Dem hauen alle Leute ab, aber von den Chefs
wird nichts unternommen (da er eigentlich einer der wenigen ist, der 
sich in dem Code Chaos noch auskennt)

Genauso wie du sagst - für mehr haben auch die Chefs kein Interesse.
Es gibt auch Leute, die das Programmieren regulär auf einer Schule 
gelernt haben (Abi), jedoch auch nur hacken und bugfixen (i.d.R. die 
technische "Schuld" die sich die Jahre angesammelt hat in dem Code, 
zurückzahlen)

>
>>  A la "Das ist halt so"
>
> Desinteresse/Resignation.
genau
>
>> Die meisten Kollegen sind eh schon weg, die paar 2-3 älteren die es noch
>> ausgehalten haben, oder sonst nix gefunden haben ,
>
> Und nach Deiner Beschreibung scheint die Geschäftsleitung auch
> keine besseren Leute bekommen zu können (wollen?). Die machen die
> beschriebenen Verhältnisse nämlich nicht unbedingt mit. Dann
> stabilisiert sich diese Praxis selbst.
Sie versuchen es ab jetzt schon , gute Leute mit Studium zu finden, aber 
die hauen nach max. 1-3 Jahren auch wieder ab.
>
>> Dann würd ich dem Chef und Teamleitern so gerne meine Meinung sagen.
>
> Ich fürchte, dass die niemand hören will. Wenn das Zeugnis nicht nach
> dem Motto entsteht "Schreiben Sie sichs selbst, wir unterzeichnen
> alles" halte ich die diesbezügliche Sorge auch für berechtigt. Auch
> ohne viele Worte hast Du Dich durch die Kündigung unmissverständlich
> ausgedrückt - vermutlich mehr als wenn Du eine lange Rede gehalten
> hättest.
> Kurz gesagt: Ich würde es lassen.
Guter Tipp, das wollte ich wissen.  Danke

Du hast recht, mit der Kündigung hab ich mich bereits klar ausgedrückt.

Es ist ein sehr gutes, berauschendes Gefühl dort endlich mal weg zu 
sein. :-)

Ich gehe jetzt in die Professionelle Softwareentwicklung/Consulting, wo 
man als Einstieg zumindest ein Diplom und 2-3 J. Berufserfahrung 
mitbringen muss.
Zusätzlich wird dort mit modernen Sprachen und Tools gearbeitet.

So long,
schlumpfcoder

Winfried J. schrieb:
> Hallo Schlumpfcoder,

Hallo Lieber Winfried (Namaste)
>
> hehe, deine Story habe ich sinngemäß in 30 Arbeitsjahren bestimmt schon
> in mehr als einem halben Dutzend Firmen erlebt.

Oje, d.h. das ist nicht einer der wenigen Firmen die so arbeitet, 
sondern es gibt ziemlich viele da draussen in dieser Arbeitsweise? Das 
schockt mich. Na gut, viell. ist auch einfach der Druck heutzutage so 
hoch, dass es sich nur wenige leisten können, länger zu brauchen und 
gute, qualitative SW entwickeln zu können..

Die bräuchten mal einen guten Softwarearchitekten, der frisch von der 
Uni kommt, 2-3 J. Berufserfahrung hat und die Prozesse designt und denen 
zeigt, wie eine gute Entwicklung auszusehen hat - also sollen sie mal 
genauso wen wie mich nehmen !! :-)

Die letze Firma hat
> alles Vorherige getoppt. Ein Chef der keine Ahnung vom Inhalt seines
> Geschäfts hat, ein Seniorchef der vom Balkon aus reinregiert,
> haufenweise stehts wechselndes unterqualifiziertes Personal. Wer sich
> freigeschwommen hat verlässt den Laden mit Kondenstreifen. Das  war der
> letzte Anstoß zukünftig meine Rechnungen selbst zu stellen. im Abgang
> wurde ich noch gefragt ob ich mehr Geld wolle oder was geändert werden
> müsse mich zum bleiben zu bewegen. Meine Antwort lautete: >"Du und ich
> wissen, dass das was geändertwerden müsse, nicht passieren würde. Der
> Drops war gelutscht.
Yep, ich hab auch das Gefühl, die Chefs wollen auch oft gar nicht 
hören.Zumindest nicht auf Leute die direkt dort in der SW Entwicklung 
beschäftigt sind, so wie du und ich, die aber am meisten davon Ahnung 
haben.

 Ist zwar mehr Aufwand, führt aber zu mehr
> Zufriedenheit mit der eigenen Arbeit, auch wenns mal nicht immer so
> läuft wie gwünscht. Klar gibt es systemische Ursachen für soetwas aber,
> es lohnt nicht sich mit solchen Zuständen auseinanderzusetzen, wenn man
> nicht überstrukturelle Kompetenz verfügt.
>
> Neuer Spielplatz, neuer Spass, das ist was zählt.
>
> Namaste
Viel Spass und Erfolg in deiner Selbständigkeit, guter Schritt!

Ich bin auch froh , den Schritt getan zu haben..