Ich finde die Fragestellung an sich nicht falsch, wenn sie darauf bezogen ist, um daran zu lernen. Also wenn man sich z.B. die Frage stellt, "könnte mir das auch passieren"? Das Problem ist, wenn in der Fragestellung bereits Schlussfolgerungen drin sind, die man eigentlich gar nicht ziehen kann, wenn man eine solche Frage stellen muss.
"Zu Fett programmieren" ist schon eine Aussage, bei der man aufpassen muss. Ich höre sowas gerne von "Codern", also Leute, die nur im Kleinen Software basteln. Was heißt "fett" hier überhaupt? Zu groß? Zu langsam? Das hängt nicht zwangsläufig zusammen. Aussagen der Art "mein Windows wird immer größer und langsamer" verdeutlichen dieses Unverständnis.
Warum wird Software immer größer? Der reine Programm-Code spielt da selten die große Rolle, selbst wenn es millionen Zeilen sind. Der Speicherplatz geht für Assets (Bilder, Ton, etc.) drauf. Früher, als Speicher knapp war, hat man alles daran gelegt, seiner Software nur das beizulegen, was auch tatsächlich verwendet wird. Heute ist es schwierig, das alles selber zu machen. Zudem wird von heutiger Software ein viel höherer Funktionsumfang erwartet. Beides bekommt man ohne Bibliotheken kaum mehr so hin, dass man dazu auch eine entsprechende Plattformabdeckung erreicht - das Ding muss ja überall laufen. Oft muss man auch gegen APIs programmieren, die den Einsatz von Bibliotheken erfordern.
Diese Bibliotheken, selbst wenn sie modular aufgebaut sind, kann man sich nicht so zurecht schneiden, dass nicht hier und da ein MB verschenkt wird. Ein Beispiel sind Toolkits mit schicken Grids und Usercontrols; hier kommen halt alle Designelemente und Icons mit, egal ob das Programm diese benötigt. Aber auch Plattform-SDKs, Sachen wie das .NET Framework oder Java, usw. gehören dazu. Dazu kommt, dass eine solche Optimierung, selbst wenn sie machbar wäre, neue Bugs erzeugt, die gefunden werden müssen, und die Wartbarkeit ordentlich leidet. Beispielsweise kann man die angepasste Library nicht mehr als fertiges Paket einbinden und auf Knopfdruck updaten. Seit es möglich ist, Speicherplatz zugunsten besserer Entwicklung zu opfern, tut man dies.
Die Frage nach dem "warum ist Premiere/Photoshop/Visual Studio/... so langsam" ist schwieriger. Die Antwort liegt aus meiner Sicht meistens bei "Altlasten" - Kunden erwarten, dass ihre Formate und Arbeitsweisen von vor 10-20 Jahren weiter unterstützt werden (Windows XP/7, Office 2003). Möchte man einen bestimmten Teil neu entwickeln, will man den neuen Code nicht durch die Features, die man eigentlich loswerden, und auch nicht mehr weiterentwickeln möchte, direkt wieder ruinieren. Was dann in der Praxis oft passiert, ist, dass der alte Code zur Abwärtskompatibilität drin bleibt, und z.B. nur aufgerufen wird, wenn eine Datei mit altem, nicht migrierbarem Format geöffnet wird. Leider wird der alte Code wiederum einen Rattenschwanz an ggfs. sehr zentrale Abhängigkeiten haben, was verhindert, dass dieser Code 100% isoliert werden kann, und keinen Einfluss auf den Rest mehr hat. Dadurch müssen über die Jahre immer mehr Dinge geladen, und zusätzliche Logik ausgeführt werden.
Glaub mir, die meisten Entwickler würden sehr gerne Altcode großzügiger rauswerfen, und Dinge "richtig" umstrukturieren. Aber erstens ist das eine Geldfrage: bei großen Softwareprojekten müsste man eigentlich alle 3-4 Feature-Releases einen reinen Wartungsrelease machen, bei dem kein neues Feature dazu kommt, sondern nur der Code glattgezogen wird. Aber wer kauft diese neue Version, die vermutlich sogar neue Bugs enthält? Und zweitens wird es dem Product Owner oft lieber sein, irgendwo 1% Kunden nicht zu vergraulen, als dass die Software irgendwo vielleicht 30% schneller startet - zumal kein Entwickler den am Ende konkret messbaren Nutzen einer solchen Aufräumaktion vorher garantieren kann.
Ich bin keiner, der alles frisst, was man ihm vorsetzt. Fanboys gibt es hier ja genug. Traurige Spezies.
