Was sind eure Erfahrungen als Softwareentwickler ?
-
Umfrage: Was sind eure Erfahrungen als Softwareentwickler ?
Auswahl Stimmen Prozent Bei uns wird Software häufig mit unrealistischen Targets enwickelt 3 20.0% Bei uns stehen meistens ausreichend Ressourcen für ein Projekz zur Verfügung 1 6.7% Bei uns ist Codequalität wichtig und wir haben genug Zeit um guten Code zu schreiben 6 40.0% Bei uns wird um die Targets zu erreichen die Codequalität vernachlässigt 5 33.3% Hallo,
ich arbeite seit etwa 4 Jahren als Softwareentwickler (C,C++) in einem Unternehmen, das Software für Banken herstellt und habe einige Projekte geleitet. Dabei sind mir folgende negative Aspekte im Unternehmen aufgefallen und ich wollte von anderen Menschen mit Berufserfahrung erfahren, ob es Ihnen ähnlich geht oder ob die Zustände nur in unserem Unternehmen so sind:
- Man bevorzugt "schnelle" Lösungen, die langfristig zu absehbaren Problemen führen werden, gegenüber Lösungen die kurzfristig länger dauern aber langfristig Zeit sparen würden
- Das Zeitlimit für viele Projekte is unrealistisch
- Die Manntage, die man braucht werden weit unterschätzt
- Um Software schnell zu veröffentlichen wird das Testen sehr stark vernachlässigt
- Die Planung am Anfang wird vernachlässigt. Es werden Projekt gestartet, bevor ausreichend geklärt ist, was das Ziel ist und welchen Impakt die Veränderungen auf existierende Verhalten haben werden
- Es is die Tendenz da auf Design Pattern und gut strukturierten Code zu verzichten und Speghetti-Code zu schreiben wenn dadurch die Produktionsziele schneller erreicht werden.
- Bei wichtigen Projekten sind die Zuständigkeiten nicht klar und es gibt Machtkämpfe zwischen den technische Projektleitern (oder denjenigen die meinen das Projekt zu leiten) untereinander als auch zwischen den technischen Projektleitern und den Businness Managern.
Was ich gerne diskutieren würde, ist ob andere Leute die gleiche Erfahrungen gemacht haben oder ob es Unternehmen in Deutschland gibt in denen ausreichend Ressourcen zur Verfügung gestellt werden um Projekte zufriedenstellend und stressfrei zu bearbeiten.
Falls Softwareentwicklung bedeutet, dass man ständig unrealistische Targets erreichen muss, welche Alternativen hat man als C++ Programmierer.
-
Seit wann ist es uncool 'Ziele' zu schreiben?
-
Walli schrieb:
Seit wann ist es uncool 'Ziele' zu schreiben?
Full ack. Zumal ich meine Software nie auf dem Target entwickle, sondern sie dort erst am Ende teste
-
Verstehe ich nicht, du sagst du hast selbst Projekte geleitet. Gehören Dinge wie Zeit-, Aufwandschätzung, Ermitteln von Wechselwirkungen, das Erstellen des Projektplans, Verteilung der Aufgaben etc. nicht zu den Aufgaben eines Projektleiters?
Und wenn das Management nicht hinter der (hoffentlich realistischen) Planung steht welche die Fachabteilung oder die Projektverantwortlichen produziert haben und meinen die Projekte müssten in unrealistisch kurzer Zeit vollbracht werden, wechsel halt den Job. Oder versuche mit der Ebene über dir die Probleme zu erörtern, dann hast du sie wenigstens darauf hingewiesen. Und wenn sie gar nicht mit sich reden lassen schalt eben auf Durchzug und führe deine Aufgabe so durch das DU dir nichts vorzuwerfen hast.
-
Ich habe noch nicht soo die Mördererfahrung (früher Ausbildung, jetzt Teilzeitentwickler neben Studium), aber einige Punkte kamen mir dann doch sofort bekannt vor:
charon007 schrieb:
- Man bevorzugt "schnelle" Lösungen, die langfristig zu absehbaren Problemen führen werden, gegenüber Lösungen die kurzfristig länger dauern aber langfristig Zeit sparen würden
Ja, definitiv.
charon007 schrieb:
- Um Software schnell zu veröffentlichen wird das Testen sehr stark vernachlässigt
Nicht nur das. Ich habe auch die Erfahrung gemacht, dass man scheinbar annimmt, das Eintragen von Fehlern in Bugtrackern sei schon die halbe Miete und man könne das Problem auf die lange Bank schieben. Die Bugs werden in die Datenbank eingetragen mit Standardpriorität und werden dann erstmal bei Seite gelassen, bis ein Kunde (Firma) einen Amoklauf ankündigt.
charon007 schrieb:
- Die Planung am Anfang wird vernachlässigt. Es werden Projekt gestartet, bevor ausreichend geklärt ist, was das Ziel ist und welchen Impakt die Veränderungen auf existierende Verhalten haben werden
Das stimmt, schlimmer finde ich aber, dass der Kunde, ob Einzelperson oder auch Firma (Erfahrung betrifft auch Banken / Versicherungen), selbst nicht genau weiß, was er will. Spezifikationen schreibt man nicht und wenn man sie schreibt, sind sie ungenau. Zur Formulierung genauer Gedanken sind Kunden garnicht in der Lage. Sei P der ausführbare Prototyp, der die Spezifikation S des Kunden erfüllt. Kunde bestätigt dies und sagt: "Super, so brauchen wir das". P wird in Software gegossen und nach 3 Monaten schreibt der Kunde eine saloppe E-Mail: "Das ist bis jetzt alles ganz schön, aber s Element von S hätten wir jetzt lieber doch so gelöst, dass ..." (Spezifikationsteil einfügen, welche die Architektur der Software komplett über den Haufen wirft).
Um die neue Spezifikation S' jetzt noch schnell erfüllen zu können, baut man ganz viel hässliche Krücken in das Programm, sodass es unwartbar wird. Aber den Termin hat man geschafft.
charon007 schrieb:
- Es is die Tendenz da auf Design Pattern und gut strukturierten Code zu verzichten und Speghetti-Code zu schreiben wenn dadurch die Produktionsziele schneller erreicht werden.
Auch bestätigt.
-
Tim schrieb:
Walli schrieb:
Seit wann ist es uncool 'Ziele' zu schreiben?
Full ack. Zumal ich meine Software nie auf dem Target entwickle, sondern sie dort erst am Ende teste
Ich habe nicht gesagt, dass es uncool ist Ziele zu vereinbaren, die werden benötigt damit klar ist was gemacht werden muß und um den Erfolg des Projektes am Ende abzuschätzen. Was ein Problem ist, ist daß die Ziele bei uns häufig mit einem Zeitlimit kommen (manchmal wird dem Kunden vom Verkauf ein Zeitpunkt für die Fertigstellung des Projekts gegeben, bevor die Softwareabteilung überhaupt weis, dass es ein Projekt geben wird). Meistens ist es möglich das Projekt auch in der Zeit fertigzustellen aber nur wenn man sehr viele Kompromisse bezüglich der Qualität macht.
verstehe ich nicht, du sagst du hast selbst Projekte geleitet. Gehören Dinge wie Zeit-, Aufwandschätzung, Ermitteln von Wechselwirkungen, das Erstellen des Projektplans, Verteilung der Aufgaben etc. nicht zu den Aufgaben eines Projektleiters?
Und wenn das Management nicht hinter der (hoffentlich realistischen) Planung steht welche die Fachabteilung oder die Projektverantwortlichen produziert haben und meinen die Projekte müssten in unrealistisch kurzer Zeit vollbracht werden, wechsel halt den Job. Oder versuche mit der Ebene über dir die Probleme zu erörtern, dann hast du sie wenigstens darauf hingewiesen. Und wenn sie gar nicht mit sich reden lassen schalt eben auf Durchzug und führe deine Aufgabe so durch das DU dir nichts vorzuwerfen hast
Die genannten Aufgaben sind Aufgaben eines Projektleiters, allerdings sind die zur Verfügung stehenden Programmierer und die Zeit innerhalb derer das Projekt fertiggestellt werden muss/soll nicht ausreichend, um die Projekte anständig zu bearbeiten, sodass in fast allen Projekten (on von mir oder von anderen geleitet) nur dann rechtzeitig abgeschlossen werden,wenn man Qualität start vernachlässigt.
Meine Idee ist es das Unternehmen evtl. zu wechseln. Das was ich hier erfahren möchte ist, ob es immer so sein wird wenn ich in der Softwareentwicklung bleibe egal für wenn ich arbeite oder ob es tatsächlich Unternehmen gibt in denen ausreichend Ressourcen zur Verfügung stehen um qualitativ hochwertige Software zu schreiben.
-
charon007 schrieb:
Tim schrieb:
Walli schrieb:
Seit wann ist es uncool 'Ziele' zu schreiben?
Full ack. Zumal ich meine Software nie auf dem Target entwickle, sondern sie dort erst am Ende teste
Ich habe nicht gesagt, dass es uncool ist Ziele zu vereinbaren, die werden benötigt damit klar ist was gemacht werden muß und um den Erfolg des Projektes am Ende abzuschätzen. Was ein Problem ist, ist daß die Ziele bei uns häufig mit einem Zeitlimit kommen (manchmal wird dem Kunden vom Verkauf ein Zeitpunkt für die Fertigstellung des Projekts gegeben, bevor die Softwareabteilung überhaupt weis, dass es ein Projekt geben wird). Meistens ist es möglich das Projekt auch in der Zeit fertigzustellen aber nur wenn man sehr viele Kompromisse bezüglich der Qualität macht.
Ich denke Walli wollte eher darauf hinaus, dass du in der Umfrage "Targets" anstatt "Ziele" schreibst...
-
charon007 schrieb:
- Man bevorzugt "schnelle" Lösungen, die langfristig zu absehbaren Problemen führen werden, gegenüber Lösungen die kurzfristig länger dauern aber langfristig Zeit sparen würden
- Das Zeitlimit für viele Projekte is unrealistisch
- Die Manntage, die man braucht werden weit unterschätzt
- Um Software schnell zu veröffentlichen wird das Testen sehr stark vernachlässigt
- Die Planung am Anfang wird vernachlässigt. Es werden Projekt gestartet, bevor ausreichend geklärt ist, was das Ziel ist und welchen Impakt die Veränderungen auf existierende Verhalten haben werden
- Es is die Tendenz da auf Design Pattern und gut strukturierten Code zu verzichten und Speghetti-Code zu schreiben wenn dadurch die Produktionsziele schneller erreicht werden.
- Bei wichtigen Projekten sind die Zuständigkeiten nicht klar und es gibt Machtkämpfe zwischen den technische Projektleitern (oder denjenigen die meinen das Projekt zu leiten) untereinander als auch zwischen den technischen Projektleitern und den Businness Managern.
Ist bei uns prinzipiell genauso, und das nicht nur auf Entwicklungen bezogen, sondern generell auf etwaige Konfigurationen/Landscape-Architekturen etc. Hängt wohl auch in gewissem Maße von der Größe einer Firma ab. Ganz so drastisch würd ichs dennoch nicht unbedingt sehen. Außerdem kann man - einen entsprechenden Dickkopf vorrausgesetzt - hier durchaus auch etwas bewegen wenn man einfach starr nach dem Motto "Qualität vor Termin" vorgeht, denn auch wenn dann immer ein Drama draus gemacht wird wenn manche Termine nicht pünktlich eingehalten werden, so passts am Ende dann doch immer auch wenns bissl später kommt - vorrausgesetzt natürlich dass die Qualität dann entsprechend gut ist. V.a. sehen dann auch manche ein, dass es letztlich doch rentabler ist lieber mal etwas mehr Zeit zu investieren... Ist im gewissen Sinn auch ein Lernprozess
-
Meine Erfahrungen zu den Themen:
charon007 schrieb:
- Man bevorzugt "schnelle" Lösungen, die langfristig zu absehbaren Problemen führen werden, gegenüber Lösungen die kurzfristig länger dauern aber langfristig Zeit sparen würden
Kommt auf den Umfang des "länger dauerns" an. Ein paar Tage zu investieren, wenn das von der Zeitplanung her machbar ist, ist nicht selten. Einen Großumbau, der mehrere Wochen in Anspruch nimmt ist natürlich nicht mal eben zwischenzuscheieben. Dafür gibts aber ein Board wo Themen für Investitionsaufwände gesammelt werden, so dass Verbesserungsideen nicht ganz ad acta gelegt werden. Diese Themen werden auch tatsächlich abgearbeitet.
- Das Zeitlimit für viele Projekte is unrealistisch
- Die Manntage, die man braucht werden weit unterschätztSelten. Wenn das vorkommt wird beim Abschlussgespräch analysiert woher die fehlerhafte Einschätzung kommt und ggf. Verbesserungen am allgemeinen Prozess vorgenommen.
- Um Software schnell zu veröffentlichen wird das Testen sehr stark vernachlässigt
Keinesfalls. Es gibt einen mehrstufigen Testprozess der sehr akribisch durchgeführt wird. Es wird lieber unvollständige Software mit bekannten und dokumentierten Mängeln ausgeliefert oder der Termin verschoben als schlecht getestete Software an den Kunden zu liefern. Verlässlichkeit und Ehrlichkeit gegenüber dem Kunden sind wichtige Bestandteile der Unternehmenspolitik.
- Die Planung am Anfang wird vernachlässigt. Es werden Projekt gestartet, bevor ausreichend geklärt ist, was das Ziel ist und welchen Impakt die Veränderungen auf existierende Verhalten haben werden
Im Normalfall nicht. Bei komplexen Änderungen kann es vorkommen dass Seiteneffekte vorher nicht absehbar waren und erst im Entwicklungsprozess zum Vorschein kommen, das ist aber eher selten der Fall.
- Es is die Tendenz da auf Design Pattern und gut strukturierten Code zu verzichten und Speghetti-Code zu schreiben wenn dadurch die Produktionsziele schneller erreicht werden.
Nein. Da viele verschiedene Entwickler am gleichen Code arbeiten sind gegenseitige Qualitätskontrolle und Verbesserungen gewährleistet. In kritischen Projektphasen wird teilweise extra ein QS-Team ausgehoben das neuen Code begutachtet.
- Bei wichtigen Projekten sind die Zuständigkeiten nicht klar und es gibt Machtkämpfe zwischen den technische Projektleitern (oder denjenigen die meinen das Projekt zu leiten) untereinander als auch zwischen den technischen Projektleitern und den Businness Managern.
Das Miteinander gehört zur Unternehmenskultur, dazu gehört auch dass Konkurrenzkämpfe möglichst nicht entstehen, den TPLs Herausforderungen zugestanden werden und der Druck von oben nicht unnötig stark ist. Das funktioniert recht gut.