Oft kommt so "müll" auch davon, das das Ziel nicht gut genug beschrieben werden konnte.
Meiner Erfahrung nach kommt Müll hauptsächlich durch zwei Dinge zu Stande:
-
der Entwickler hat keine Ahnung davon was er eigentlich tut
-
der Entwickler leidet unter enormem Zeitdruck und muss "schnell schnell" alles fertigbekommen, kann sich die Zeit aber nicht dafür nehmen.
In beiden Fällen sieht man, ob der Entwickler wenigstens gute Ideen gehabt hat, die man weiterverfolgen kann.
Ob der Entwickler tatsächlich eine Null ist oder eben nur unvollständig gearbeitet hat erkennt man daran, dass die grundlegenden Teile sauber ausgearbeitet sind, der Rest aber dreckig drangebaut wurde.
Da mag der Entwickler schuld sein, vllt. aber auch der Auftraggeber, der nach 20 mal nachfragen immer noch nicht richtig definieren konnte.
Das ist auch ein großes Problem: es wird eine Anforderung definiert, daran wird dann 3 Monate programmiert und danach kommt der Auftraggeber drauf, dass er doch alles ganz anders braucht - das erschüttert die Struktur der Software in ihren Grundfesten und ohne alles neu zu schreiben kommt man einfach nicht drum rum, dass man "schnell schnell" in 2 Tagen die Arbeit von 2 Monaten erledigt.
Wenn die Aufgabe hieß, fahr nach Rom, dann reicht der Zug aus.
Und dann baut der Entwickler Schienen, zwei schöne Bahnhöfe und ein paar Tunnels.
Wenn mir dann aber einer sagt, nim noch 3 Leute mit, dann buch ich eben 3 Plätze dazu und gut ist. Muss ich aber noch meine Ausrüstung mit nehmen, dann brauch ich schon das ganz große Auto. Ich denk ihr versteht schon ;)
In diesen Fall baut man dann vielleicht noch einen Gepäckwagon hinzu - aber spätestens wenn der Auftraggeber dann auf einmal nach London will, wirds mit dem Zug schwierig - einfach mal schnell den Eurotunnel dazugebaut ist nicht - und wenn dann noch der Wunsch kommt, dass man jetzt auch noch nach New York will, braucht man ein Flugzeug - das baut der Entwickler dann, aber das hat dann Stromabnehmer und einen Gepäckwagon. Das sieht für einen Außenstehenden nach Mist aus, liegt aber daran, dass ein System auf etwas umgebaut wurde, was es eigentlich nicht können hätte sollen.
Das schöne an der Geschichte ist aber häufig. Dass auch eine Version 2 irgendwann den Platz von V1.0 bekommen wird und man lieber noch mal von vorne beginnt.
Große Software ist schwer zu überblicken.
Ja - und besonders schwierig ist es im Projektgeschäft, dann ein Feature auszubauen, welches er haben wollte und jetzt nicht mehr braucht, weil du einen drauf lassen kannst, dass er es drei Wochen später doch wieder braucht. Du stehst also vor einem Dilemma: bereinigst du den Code, wird er das Feature wieder haben wollen und darfst es wieder dazubauen - belässt du es im Code, wird er es nie wieder haben wollen und dein Nachfolger wird sich über den "Trottel der den Code nicht aufräumt" wundern :)
Aber im Grund gib ich dir Recht, es ist schon ein nettes Gefühl, wenn man zu 100% sagen kann. "Das hab ich euch so vor 2 Jahren gesagt". Wenn Kollegen daneben hocken und dann sagen können "Ja das hat er". Dann ist das doch Gefühlt, wie 2 Beförderungen xD
So ist es - nur leider kommt das selten vor.