Wie geht man mit Designfehlern um?
-
Hi,
also in dem Projekt, an dem ich grade arbeite, stecken einige schwerwiegende Designfehler. Die sind so schrecklich das ich sie hier nicht nennen kann ohne mein Gesicht zu verlieren... Jedenfalls sorgen diese Designschnitzer regelmäßig für neue Fehler, teilweise unberechenbares Programmverhalten und extrem aufwändige Workarounds für neue Features.
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. Theoretisch könnte man auch gleich das ganze Programm neu schreiben...
Mein Kollege sieht das auch so. Wir haben uns schon oft Gedanken gemacht wie wir unsere Klassen jetzt Entwerfen müssten. Leider hatten wir dieses Wissen damals noch nicht... 
Wie geht ihr mit solchen Dingen um? Einfach weitermachen und hoffen das es irgendwie klappt? Mit dem Gedanken "Er hat es ja so gewollt" leben und stur alle Fehler beseitigen? Oder immer wieder drauf pochen das große Teile neu geschrieben werden müssen?
Das schlimmste ist eigentlich das mein Kollege (der sich mit dem Code + Programm am meisten auskennt) bald die Firma wechselt und ich mich dann alleine um den Mist kümmern muss. 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?
-
Da bleibt halt nur: Neu Designen oder eben dem Kunden erklären das es 1-3 Wochen dauern wird. Ist doch ganz einfach.
Ausserdem, wenn es so viele Fehler verursacht, dann werden ihr irgendwan sowieso keine Kunden mehr haben.
-
DEvent schrieb:
Ausserdem, wenn es so viele Fehler verursacht, dann werden ihr irgendwan sowieso keine Kunden mehr haben.
So sehe ich das auch.
-
Ein Wrapper um die gefährlichen Stellen herumschreiben, der alles zurechtbiegt. Jedenfalls soweit zurecht, dass man den Code benutzen kann.
Ich weiss, das ist nicht gerade ideal; aber es verhindert, dass die Applikation komplett neu geschrieben werden muss.
-
Ich würde sagen stückweise refactorn.
-
Hem, also neuschreiben macht niemand ebend mal so. OK, bei einem HelloWorld-artigen Programm ist das kein Thema. Aber sobald es größer ist und auch noch produktiv im Einsatz ist
no chance! Wenn das gängige Praxis wäre, würde es keine Cobol-Programme mehr geben. Entweder du baust es nebenbei um, oder ihr macht ein neues Projekt (halt mit komplett anderem Namen, nichts mit "neue Version von Projekt X"), so das es offiziell extra Budget gibt.Nebenbei umdesignen kannst du aber ohne Erlaubnis machen: wenn du an einer Stelle was machen mußt, kannst du es gleich umdesignen. (aber nur den einen Part) So mache ich das meistens, wenn ich über etwas den Kopf schüttel, was ich mal vor Jahren verzapft habe.
Da wirst du aber auf jeden Fall ein paar Refactoringtools benötigen, die dich unterstützen. Welche Sprache und welches OS ist es denn? Wenn es C++ und Windows ist, kannst du mit VisualAssist X oder Ref++ schon mal einfacher "umbauen". Blind von Hand wird das schwieriger.JBenis Hinweis ist auch gut. Und zwar kann man ja einen Wrapper oder Adapter designen, der Legacycode "versteckt". Und die neuen Sachen, die ihr codet, benutzen den Wrapper/Adapter.
-
Chris++ schrieb:
Wie geht ihr mit solchen Dingen um?
Das kommt immer auf den Einzelfall an. Wenn du stichhaltig darlegen kannst, dass [teilweises] Neuschreiben letztendlich Zeit und Kosten sparen wird, wirst du bei einem vernünftigen Menschen dabei auch auf offene Ohren stoßen.
Denn die Argumentation des Zeitdrucks zieht nicht, wenn du beweisen kannst, dass es mit deinem Vorschlag letztendlich schneller gehen wird und das Endprodukt bessere Qualität haben wird. Dazu musst aber wohl nachvollziehbare Zahlen vorlegen können. Wenn du das nicht kannst, hast du schlechte Karten. Wenn doch, und der Projektleiter bleibt dennoch bei seiner Meinung, bring es (z. B. in einem Teammeeting mit dem Entwicklungsleiter/Abteilungsleiter/etc.) so offen wie möglich zur Sprache. Lass dich bloß nicht von plumpen "Es muss aber!"-Ansagen unterbuttern.
/edit: Vergiss nicht, dass du bei so einem Vorgehen vielleicht zugeben musst, dass du Scheiße gebaut hast.
-
Habt ihr eigentlich wenigstens modular programmiert? Mit wohldefinierten Schnitstellen? Dann wäre eine neuimplementierung eines Moduls kein Problem
-
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
Chris++ schrieb:
Das schlimmste ist eigentlich das mein Kollege (der sich mit dem Code + Programm am meisten auskennt) bald die Firma wechselt und ich mich dann alleine um den Mist kümmern muss.
die natuerliche folge, du wirst der naechste sein wenn so weitergewurschtelt wird.
Gratulation an den projektleiter der mit dem projekt dann dort ist wo er vor urzeiten warChris++ schrieb:
Theoretisch könnte man auch gleich das ganze Programm neu schreiben...
Mein Kollege sieht das auch so.siehe oben, ein halbes jahr stillstand quasi, und es hat sich nichts geaendert
die rechnung, 1 x 3 wochen oder jedes monat 3 wochen zeitverlust sollte der duemmste verstehen
Chris++ schrieb:
Wie geht ihr mit solchen Dingen um? Einfach weitermachen und hoffen das es irgendwie klappt? Mit dem Gedanken "Er hat es ja so gewollt" leben und stur alle Fehler beseitigen? Oder immer wieder drauf pochen das große Teile neu geschrieben werden müssen?
1x probiert nach wunsch vorzugehn und umzusetzten, horror
danach immer sofort auf die probleme hingewiesen und wenn keine aussicht auf loesung, projekt verlassen.wenn ich nicht unbedingt das projekt brauch um mein leben zu finanzieren heissts auf wiedersehn, passiert frueher oder spaeter sowieso, nur man spart sich den persoenlichen stillstand (frustatoion, anstatt brauchbares zu lernen nur aerger mir dem vorhandenen, kein erfolgserlebniss, usw, -> bringts nicht
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?
geht dich nix an, ist aufgabe des projektleiters
ich hoffe du hast die kommunikation von vo reinem halben jahr schriftlich (mail)
wenn nicht, lern draus, immer alles per mail besprechen bzw ergebnisse von besprechungen mit projektleitern dokumentieren und von beteiligten absegnen lassen.
du kannst dich sonst 100%tig drauf verlassen das es heisst: die programmierer sind schuld, bzw du weil ja sonst niemand mehr da ist
-
Chris++ schrieb:
Wir haben uns schon oft Gedanken gemacht wie wir unsere Klassen jetzt Entwerfen müssten. Leider hatten wir dieses Wissen damals noch nicht...
das wirst du in nem jahr dann wohl auch ueber dein jetziges wissen denken. also programmierer evolutioniert man sein programmiererlebenlang
Wie geht ihr mit solchen Dingen um? Einfach weitermachen und hoffen das es irgendwie klappt? Mit dem Gedanken "Er hat es ja so gewollt" leben und stur alle Fehler beseitigen? Oder immer wieder drauf pochen das große Teile neu geschrieben werden müssen?
beides ist keine loesung, zu deinem koennen muss nicht nur die faehigkeit klassen zu designen gehoeren, sondern auch auf bestehendem code zu maintainen. grundsaetzlich wird man mit altem code nie zufrieden sein und wann auch immer man freumden code bekommt, wird man noch mehr der meinung sein, dass man lieber alles from scratch schreiben sollte, aber das ist keine akzeptable loesung, denn auch deine neue software wird fehler haben, nicht die selben, aber dafuer jede menge anderer kinderkrankheiten, denn niemand wird dir sagen "oh, wir haben das 2jahre lang entwickelt, nimm dir doch 4 und schreib das nochmal aber ordentlich, sodass wir in 4jahren so ziemlich da sind wo wir jetzt sind".
also schreib einfach so sauberen code wie es dir jetzt moeglich ist, versuch stueck fuer stueck, wenn du 'features' einbauen sollst, statt hacks zu machen, einfach saubere schnittstellen zu haben und bei den features guten code zu haben, eventuell, wenn du dem zeitplan voraus bist, bau etwas mehr um als dein feature braucht um es sauberer zu machen.
Das schlimmste ist eigentlich das mein Kollege (der sich mit dem Code + Programm am meisten auskennt) bald die Firma wechselt und ich mich dann alleine um den Mist kümmern muss. 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?
das gehoert dann ebenfalls zu den faehigkeiten eins programmierer die heute verlangt werden, aufwands vermitlung bzw marketing. du musst dem kunden sagen welch weite auswirkungen so ein feature hat und dass es 4wochen dauert, nach 2wochen kannst du dann sagen dass du die wochenenden durchgearbeitet hast um das wichtige feature fertig zu haben, und dann ist der kunde gluecklich... und darauf kommt es an. auf keinen fall solltest du dem kunden deine 'wahrheit' ueber das produkt sagen, drueck es immer positiv aus.
statt "hab heute wieder zwei total dumme fehler gefunden" sag lieber "das programm ist jetzt noch stabiler, weil ich ein paar sehr selten auftretende inkompatibilitaeten mit ... geloest habe".
-
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.
