Hallo Leute, bin jetzt in Deutschland bei einer Firma, die Software für industrielle Anwendungen programmiert. Das betrifft GUI Programmierung und Prozessprogrammierung. Die Software ist in C programmiert und existiert schon seit den 90ern mit angeblich 1-2 Millionen LOC (Lines of Code). Die Software wird in Verteilzentren genutzt (Terminals etc.) und steuert auch den Prozessablauf im Lager. Nur ist die Entwicklung schon lange Steinzeit und nicht mehr State of the Art. Versionsverwaltungssystem ist noch CVS (Head und Branch), und es gibt teilweise C Files mit >20.000 Zeilen Code und Strukturen die keiner mehr lesen kann, weil einfach alles reingeknallt wird. Zusätzlich gibt es Inbetriebnahmen wo diese Software angepasst wird (Editiert und entwickelt wird in VIM über eine Shell) und wenn man einen Bugfix macht, wird das oft sogleich kompiliert und produktiv eingespielt, wenn der Bugfix sofort gebraucht wird (Extrem/Notfallsituation). Die C-Prozesse laufen in Corba (zB um Materialflussbewegungen anzutriggern und Werte an einer darunter liegende Schnittstelle zu senden). Softwaredesign: UML wird nicht eingesetzt in der Firma. Nur ab und zu bei komplizierteren Programmen wird mal ein Ablaufdiagramm erstellt. Oft rühren 5 oder mehr Leute ins gleiche File was zu Konflikten führt. Auch muss manches sehr schnell gehen und es wird losprogrammiert bevor eigentlich das übliche Design fertigstellt wurde (was einer der häufigsten Fehler ist in der Softwareentwicklung). Natürlich geht jeden Tag etwas schief. Es wird jeden Tag von zig Leuten debuggt, kompiliert und gebugfixt. Grausam. Es wurde sogar (!!) eine externe Beraterfirma (Drittfirma) vom Kunden beauftragt, um die Softwarequalität in unserer Firma voranzubringen und Verbesserungsmöglichkeiten aufzuzeigen, weil der Kunde mit der Software nicht zufrieden ist. Meiner Meinung nach müsste der Schritt eigentlich von unserer Firma selbst kommen! Natürlich gibts auch viele Managementfehler, das ist aber wieder eine andere Geschichte. Die Leute sind dort auch einfach überfordert. Was hättet ihr für Ideen an Verbesserungsvorschlägen? Meine wären zB -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.) -Eine Softwareanpassung muss zunächst immer eine UML Anpassung vorausgehen -Tägliche automatisierte Unit Tests, Testmanagement einführen -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 -Qualitätsmanagement, Change Management, Anforderungsmanagement einführen -Dokumentenmanagement-Tool einführen (gibts auch nicht, die Files liegen alle in word oder pdf auf irgendwelchen Laufwerken rum) -... Was hättet ihr noch für Ideen? Findet ihr diesen Zustand nicht auch grausam? Kennt ihr zufällig auch Firmen wo so entwickelt wird ?!
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.
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? Ein bestehendes Projekt in UML quetschen? Kannst du vergessen. Vorher gehst du in Rente. Automatisierte Unit-Test sind eine gute Sache. 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. 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.
> 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.
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. Mit schlechtem Requirement Management kriegt man jedes Software-Projekt kaputt.
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 ... ;-)
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.
Konrad S. schrieb: > 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. Was ich meine ist folgendes Szenario: -Release 1.0 ist fertig. -Die Requirements für Release 2.0 werden aufgeschrieben. -Während der Implementierung für Release 2.0 stellt sich heraus, dass die Anforderungen ungenau, unvollständig und teilweise sogar völlig unzutreffend sind. Die Abteilungen sind anscheinend nicht in der Lage, untereinander klar darzulegen was welcher Kunde wie haben will, und welche Normen, Vorschriften und Zulassungsbedingungen in welcher Version für welches Land gelten.
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!" ;-) > 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. ;-) schlumpfcoder schrieb: > Ganz genau, ganz genau, du verstehst was ich meine.. anscheinend > arbeitest du ganz in einem ähnlichen Umfeld... Ich habe auch ein ähnliches "Erbstück", nur deutlich kleiner. Es ist aber immer noch zu groß, um es mal eben neu aufzuziehen. Mittlerweile gibt es automatisierte, regelmäßige Test. Die MTBC (mean time between crash ;-) konnte deutlich vergrößert werden, Buffer-Overflow und so das Übl(ich)e. Und mittlerweile gibt es einiges an Dokumentation. Es ist halt sowas wie Mäusemelken, ohne Ausdauer geht es nicht. > 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> ;-) > 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.) 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. Jan schrieb: > Zum Thema... So geht das in der Softwareentwicklung: http://www.projectcartoon.com/cartoon/1765
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.
schlumpfcoder schrieb: > 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. Ich wwill jetzt nich sagen, dass das normal ist, aber ungewöhnlich ist es auch nicht. schlumpfcoder schrieb: > Habe in 4 Jahren keine einzige Weiterbildung machen > können! Das ist allerdings ein guter Grund, sich anderweitig umzusehen. Gerade zu Beginn des Berufslebens bringen die Weiterbildungen den größten Erfolg. schlumpfcoder schrieb: > 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. So sehe ich das auch.
Das Wort das die Lage am Besten beschreibt ist Technical Debt. Klar kann man weitermachen wie bisher, aber irgendwann fressen die "Zinsen", d.h. das komplizierte Monster die ganze Produktivität auf, man kann praktisch nichts neues dazuprogrammieren ohne sich zu verheddern. Der Begriff hilft auch zu erklären, dass man irgendwann aufräumen muss. Man kann sich überlegen wie schnell man das macht oder wo man anfängt, aber Alternativen gibt es nicht. Alles neu machen ist a) teuer, b) riskant weil es schief gehen kann und c) vielleicht gar nicht so sinnvoll, weil in den Entwicklerköpfen die alte Software und die große Zielvorgabe "Soll alles können was die alte Software auch kann" steckt Über Corba würde ich nicht so schimpfen, das sind immerhin schon existierende Schnittstellen mit Interfaces. Da würd ich anfangen zu dokumentieren, danach kann man Modultests gegen diese Schnittstellen programmieren. So gewinnt man einen Überblick über das System. Wenn jetzt einzelne Module besonders schlimm sind kann man sie refactoren oder neu machen, die Modultests geben Sicherheit dass es danach noch funktioniert. Schwierieger wird, die Schnittstellen selber aufzuräumen, neu zu sortieren und zu modularisieren. Die neue Doku sollte helfen den Überblick zu behalten. Insgesamt ein langer Weg, jede einzelne Datei kann herausfordernd sein und versteckte "Schätze" wie Seiteneffekte haben. Mindestens genauso wichtig ist, alle Programmierer darauf einzuschwören und Standards bezüglich Entwurfsmuster, Strukturierung, Namensgebung und Dokumentation zu finden. Coding-Guidelines sind da nur ein kleiner Teil. Gerade für gestandene C-Programmierern ist das keine leichte Aufgabe. Entwurfsmuster und so anderes High-Level-Gedöns erscheinen halt oft sinnlos, als C-Programmierer arbeite ich nahe am Eisen, ich zwinge der Maschine meinen Genius auf. Was soll da unlogisch sein? Ok, ich mach Kommentare, vielleicht auch mal ne Doku... (für den Neuen, ders eh ned blickt) Was dabei rauskommt ist oft nicht so hilfreich, da halt nur ein Teil (oft sogar zu detailliert) beschrieben wird. (Sind doch 20 Seiten, was soll ich denn noch tun?) Die Dokumentation des Großen Ganzen, und des Zusammenspiels der Module ist oft ein Problem. Grüße & viel Erfolg
@schlumpfcoder: Die Bude heißt aber nicht "Knapp", oder?
@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? ;-)
Philipp K. schrieb: > 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. Das Problem ist, dass sich in großen Firmen mindestens eine, wenn nicht gar mehrere Zwischenstationen zwischen dem Kunden und dem Entwickler befinden. Man kann gar nicht den Kunden direkt fragen, wie er es denn wirklich haben will. Und die Anforderungen werden beim Kunden nicht selten von jemandem "eingesammelt", der selbst gar keine Software entwickelt, und daher nicht die richtigen Fragen zu stellen weiß. Auch hat man so keine Chance zu wissen, ob die Anforderungen wirklich vollständig sind. Woher denn auch? Man kann nicht ALLES hinterfragen - dann wird das Projekt nie fertig. Wenn etwas offensichtlich sinnlos ist, dann hakt man natürlich nach. Aber wenn eine Anforderung des Kunden vergessen wurde, dann kann sie eben auch nicht umgesetzt werden. Entwickler können vieles, aber Hellsehen is nich. Dann gibt es noch den Fall, dass der Entwickler sehr wohl nachfragt, aber der Software-Projektleiter eine Pfeife ist und die Nachfrage im Sande verläuft. :-( atm schrieb: > Zentrales Buildmanagment.. wer verwendet das heute noch nicht? Bombardier Transportation mit etlichen Tausend Mitarbeitern, zum Beispiel. Man will es seit längerem schon einführen, aber wir warten immer noch drauf. Generell gibt es Firmen, in denen zwar auch Software entwickelt wird, aber dies nicht das eigentliche Kerngeschäft darstellt. Bei denen würde ich nicht erwarten, dass unbedingt auf dem Stand der Technik entwickelt wird. Leider :-(
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
Hallo Schlumpfcoder, hehe, deine Story habe ich sinngemäß in 30 Arbeitsjahren bestimmt schon in mehr als einem halben Dutzend Firmen erlebt. 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. 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
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..
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.