Wie geht man mit Designfehlern um?
-
Danke an alle. Ich werde das beste draus machen und kleinere Sachen neu schreiben wenn noch Zeit bleibt. Eventuell die eine oder andere Funktion hinter einem Wrapper verstecken. Eines hab ich in diesem Projekt auf jeden Fall gelernt. Wie wichtig doch ein gut durchdachtes Design ist und wie sehr sich Fehler in der Design- und Implementierungsphase auswirken.
-
Chris++ schrieb:
...
Wie geht ihr mit solchen Dingen um?...Wir hatten da auch einige üble Sachen in der ersten Version unserer Software und da sind wir "Salamitaktik" gefahren: Bei jedem kommenden Release haben wir einen Teil ausgebügelt. Die Aufwände dafür wurden gleich in das Angebot für die Erweiterung eingeschätzt.
Chris++ schrieb:
...Wie soll man einem Kunden erklären das der Einbau von neuen Features, die bei gutem Design 2-3 Tage in Anspruch nehmen würden, 1-3 Wochen dauern?
Gar nicht. Der Kunde kann üblicherweise mit derartigen Details nichts anfangen. Das gibt nur unsinnige Rechtfertigungsdiskussionen à la "Warum haben Sie das nicht gleich richtig gemacht ?" ....
Aber vom Projektleiter kann man erwarten, dass er das versteht.
Insgesamt kannst Du als Argumentationshilfe "doppelte Buchführung" betreiben: Bei jeder Schätzung zwei Preise angeben - einen für "wenn wir ein vernünftiges Design hätten" und einen für "so, wie es ist".
Wenn's gut läuft, sieht es irgendwann auch der sturste Ignorant ein.Chris++ schrieb:
...Eines hab ich in diesem Projekt auf jeden Fall gelernt. Wie wichtig doch ein gut durchdachtes Design ist und wie sehr sich Fehler in der Design- und Implementierungsphase auswirken.
Versuche, möglichst Viele "mitlernen" zu lassen (allen voran den Projektleiter) ... je mehr aus dieser Panne lernen, um so leichter hast Du's später. Dazu gehört auch, sie die "Schmerzen" des schlechten Designs spüren zu lassen ... sonst hast Du beim nächsten Projekt in der Designphase das Problem, dass da (wieder) gespart werden soll ... "Mach' irgendwie schnell - Hauptsache billg/schnell fertig. Hat ja beim letzten Mal auch geklappt !"
... und Du hast doch keine Lust, denselben Streifen nochmal durchzumachen, oder ?
Gruß,
Simon2.
-
Wenn's gut läuft, sieht es irgendwann auch der sturste Ignorant ein.
wenn es schlecht laeuft sagt der vorgesetzte dem chef "soviel zeit brauchen wir zZ, und soviel haetten wir gebraucht wenn wir leute haetten die ahnung haben".
soeinen konfrontationskurs sollte man moeglichst vermeiden.
-
rapsoo schrieb:
Wenn's gut läuft, sieht es irgendwann auch der sturste Ignorant ein.
wenn es schlecht laeuft sagt der vorgesetzte dem chef "soviel zeit brauchen wir zZ, und soviel haetten wir gebraucht wenn wir leute haetten die ahnung haben"....
Darauf würde ich es ankommen lassen. Das ist nämlich ziemlich hohles Gerede ... "der Chef" weiß nämlich auch, dass er mit Neueinstellungen ein ziemliches Risiko eingeht (vom Aufwand mal ganz zu schweigen).
Und ehrlich gesagt: Es entspricht z.T. ja auch der Wahrheit ! Chris++ gibt ja zu, damals dämliche Entscheidungen getroffen zu haben (wie jeder ehrliche Programmierer) ... aber er hat daraus gelernt und ist damit (und mit der gesamten fach- und umgebungsspezifischen Erfahrung, die er gesammelt hat) wertvoller denn je für seine Firma.Den Chef möchte ich mal sehen, der mir eine Strick daraus drehen will, dass ich Erfahrungen sammle....die Alternative wäre nämlich nur Lernresistenz (und durch die ist noch niemand klüger oder wertvoller geworden).
Gruß,
Simon2.
-
daHa schrieb:
Chris++ schrieb:
Ich habe meinen Projektleiter schon vor einem halben Jahr gesagt das es besser wäre einige Teile neu zuschreiben. Er hat aber abgelehnt, da wir mächtig unter Zeitdruck stehen.
dieser mensch ist fehl am platz
Würde ich so pauschal nicht unterschreiben. Gerade in einer verfahrenen Situation geht's manchmal nur noch nach Vorne statt zurück.
Außerdem wollen Programmierer immer umschreiben und verbessern, das ist auch so ein Problem: wenn Du einem Programmierer oder einem Physiker Zeit lässt, wird er niemals fertig, er will refactoring machen und verbessern und neu schreiben und immer so weiter. Eine Gruppe von Programmierern bekommt jedes Budget klein, wenn man sie nur immer wieder verbessern lässt - gerade weil es immer was zu verbessern gibt. Lässt man dem Perfektionsstreben der Programmierer freien Lauf, wird man niemals fertig.
Insofern würde ich eher annehmen, daß der PL den Hintergrund nicht verstanden hat, was auf Kommunikationsdefizite hindeutet. Da Kommunikation im Projekt bidirektional ist, liegt die Schuldfrage irgendwo zwischen 40:60 und 60:40.
-
Marc++us schrieb:
Außerdem wollen Programmierer immer umschreiben und verbessern, das ist auch so ein Problem: wenn Du einem Programmierer oder einem Physiker Zeit lässt, wird er niemals fertig, er will refactoring machen und verbessern und neu schreiben und immer so weiter. Eine Gruppe von Programmierern bekommt jedes Budget klein, wenn man sie nur immer wieder verbessern lässt - gerade weil es immer was zu verbessern gibt. Lässt man dem Perfektionsstreben der Programmierer freien Lauf, wird man niemals fertig.
ja, da hast du sicher recht, bin selber jemand der gern wegen dieser oder jender verbesserung mal schnell ein paar wochen liegen laesst, bz weil ich oft nicht die erstbeste sondern die optimale loesung such.
das richtige mittelmass zu finden ist da oft nicht leicht, weil so richtig weis man es ja oft erst hinterher wenn alles fertig ist, und wenn man sich gern mit neuen themen beschaeftigt, sich hinterher nicht aergern will ueber das was man fabriziert hat oder auf welchen libs man aufbaut usw kommt man leicht ins dilemma.
allerdings gibts eindeutige situationen, und "hei, wir verlieren monat pro monat 1 bis 2 wochen und irgendann ist das ender der sackgasse erreeicht weil wir uns nicht einmalig 3 bis 4 wochen zeit nehmen und das problem eleminieren" ist doch recht deutlich.
Marc++us schrieb:
Insofern würde ich eher annehmen, daß der PL den Hintergrund nicht verstanden hat, was auf Kommunikationsdefizite hindeutet. Da Kommunikation im Projekt bidirektional ist, liegt die Schuldfrage irgendwo zwischen 40:60 und 60:40.
die frage koennte auch sein ob derjenige wirklich primaer projektleiter oder eigentlich der verkaeufer der software/dienstleistung ist und somit eigentlich andere ziele verfolgt.
-
Wenn der Drachen nicht zum Berg fliegt, muss die Sonne noch nicht untergehen.
-
Also zu dem Thema kann ich Romane schreiben:
- Softwarearchitektur ist wie das Fundament bei der Baustatik!Bei einer Hundehütte kann man bei dem Fundament ruhig schlampen.Nur habe ich es aber schon oft erlebt, dass die Hundehütte später 30 Stockwerke hatte. Z.B.:
Du entwirfst einen Prototypen (Dummy), um den Kunden mal zu zeigen, wie man so etwas lösen kann, um einen Auftrag zu akquirieren und überlässt die Entwicklung dem Auftragnehmerteam. Nach Jahren bekommst Du das selbe Projekt wieder serviert und stellst fest, dass das Team das Hundertfache an Codevolumen, um deinen Dummy gebaut haben. Mit ein hohen Anteil an Globalvariabeln, die mehrfach geklont wurden. Viele Routinen, die Du geschrieben hast, wurden mehrfach kopiert und leicht modifiziert an anderer Stelle wieder verwendet. Kein sauberes System-Engineering. Um dann Alles in einen zentralen Klassenklumpen zu leiten, wie zu schlimmsten "Goto"-Zeiten, ohne Doku oder Kommentare.
Du bekommst das Projekt nur deshalb wieder angetragen, weil Du früher mal den Prototyp geschrieben hast und das Team keine Änderung mehr vornehmen kann, ohne das an anderen Stellen 10 Bugs auftauchen. Nur sobald die erste Aufwandsschätzung absendest (-> "Totalschaden"), war es das mit der Beauftragung. Ein detailiertes Angebot aufzusetzen ist Zeitverschwendung. Die Leute hoffen immer nur von Dir zu hören, dass Du nur irgendwo "mal kurz" an einer Stelle vortreten musst und wollen nicht hören, wie blöd Sie eigentlich sind...
-
Kundenmanagement
Der Vertriebler macht vor dem Kunden haltlose Versprechungen, um einen Fuss in das Unternehmen zu bekommen, ungeachtet davon ob die Firma dabei Profit macht, in der Hoffnung, dass der Kunde auch die Folgeaufträge erteilen "muss". So werden in dem ersten Auftrag schon sämtliche professionelle Verfahrensweisen geschlampt. Nur kommen dann die Folgeaufträge, erhält das Team kaum bessere Konditionen und Refactoring kannst Du gleich vergessen. Der Kunde ist bereits "verzogen". Irgendwie schaffen es die Kundenmanager dann aber immer Extrapositionen auf der Rechnung zu setzen, um die Kosten zu decken. Das geht solange gut bis den Managern der Kragen platzt -> Fortschritt/Kosten. Und schon ist der erste SAP Vertriebler im Hause mit dem Motto - Lieber ein Ende mit Schrecken, als ein Schrecken ohne Ende. Und der Kunde wechselt zu der dunkelen Seite der Macht ...
-
Produktmanagement
Oft kommt es dann vor, dass in der Zuliefererindustrie Kunden 30% Umsatzanteil haben. Dann kommt dann das Management auf den PL zu: " Ich weiß, ist Scheiße. Aber unser Leben hängt davon ab." - Linke Hand Kamel, rechte Hand Nadelöhr. - "Sehe zu, dass deine Leute das Tier dort durchbekommen." - Was danach oft an SW abgeliefert wird, ist schon eigentlich ein klares Betrugsdelikt.
Oder der Erbsenzähler kommt auf einen zu: "Das ist euer EBIT. Vermasselt es nicht. Denn wenn ich in der nächsten Vorstandssitzung erzählen muss, das wir den Score nicht erreicht haben, ist die nächste Aktion eure indischen und chinesischen Nachfolger einzuphasen".
-
Projektmanagement
Nur die wenigsten PL haben es drauf den Projektfortschritt auf Basis von technischen und fachlichen Fakten (Requirements Engineering) zu beurteilen. Sie betreiben im Wesentlichen nur das klassische finanzielle und terminliche Meilenstein- und Release- Controlling. Eine sensibellen Komponete, die einen Arbeitsaufwand von 3% hat, kann darüber entscheiden, ob man 90% oder 0% für die Deadline hat.
Ein wirklich guter PL in einer Firma mit starker Prozessorientierung nervt Dich niemals: "Hey Meister, wann bist Du fertig? Ich muss den Kunden sagen, wann wir liefern können!" -
Requirements Engineering, Business Engineering, System Engineering
Software Design steht im direkten Zusammenhang mit der Konzeptentwicklung.
Nur eine geringe Anzahl der Leute im deutschsprachigen Raum (D,AUT,Ch,LUX) können mit modernen IT Prozessen und Methoden auch vernünftig das Produktmanagement andocken . Ich schätze sie auf ca. 80-100 ...
-
Prof84 schrieb:
...
Gib's zu: Du arbeitest in unserer Firma !!!
Super auf den Punkt gebracht - ich habe (mit Quellenangabe) Dein Post gerade komplett an einige Kollegen verschickt !
Danke,
Simon2.
-
Globale Variablen sind toll, vorallem wenn der Chef sie einbaut.
-
Besser sind mehrdimensionale (>7 Dimensionen) globale Arrays. Vor allem wenn alle Daten im Programm mit solchen Arrays verwaltet werden.
-
Versuchts mal dem intensiven Einsatz von Macros in Kombination mit Variablennamen wie a1, c3, d1, x1, y2,...
Das ist echt unterhaltsam.
-
Nichts gegen nen Chef, der alles copy & pasted.