Neues allein um des Neuen willen ohne Mehrwert, wer hat da wirklich was davon?
Was ich aber vorfand war grausam unlesbarer Bestandscode. Allein der Versuch von Refaktorierung war ein K(r)ampf. Sowohl mit der
IDE als auch mit den "alten Hasen".
Ich habe vor 16 Jahren, als ich meinen aktuellen Job antrat (Mein Gott! Ist das schon so lange her?!), genau dasselbe Problem gehabt. Ich musste erstmal eine vernünftige Sourcecode-Verwaltung einführen und an vielen Stellen seltsame Konstrukte im Sourcecode zu verstehen versuchen. Ich hatte zum Glück noch den Hauptentwickler griffbereit, so dass ich mir mit dem Aufräumen einige Jahre Zeit lassen konnte. (Es war auch nicht wirklich so schlimm, wie sich das jetzt anhört, einiges war sicherlich dem "Not developed here/by me"-Syndrom geschuldet.) Ich habe mich seitdem bemüht, eine Struktur in die Entwicklung zu bringen (Bibliotheken in Projekte einbinden statt Units oder Sourcecode aus anderen Projekten zu kopieren(!)) und seltsame Konstrukte mit Kommentaren zum "Warum" zu versehen (und sinnlose oder gar falsche Kommentare einfach zu löschen). Aber manchmal komme ich mir vor wie Sisyphus, denn wir haben ein paar Spezis, die immernoch genau so arbeiten wollen wie früher bzw. wollen, dass die Entwickler so arbeiten wie früher (Projektleiter: "Das haben wir doch für ein früheres Projekt schon mal gemacht, kopieren Sie doch einfach den Sourcecode und passen Sie ihn an!").
Im Job davor war es ähnlich. Da gab es einen Entwickler, der Sourcecode-Verwaltung für Teufelszeug hielt...
Auf der anderen Seite warte ich täglich darauf, dass jemand kommt und meint, wir sollten endlich von Subversion auf das "viel modernere und flexiblere" git umsteigen (welches bei einem zentralen Repository im LAN kaum Vorteile gegenüber
SVN hat, aber darüber kann man ewig diskutieren). Das wird vermutlich spätestens dann passieren, wenn wir einen Entwickler frisch von der Uni einstellen, immer vorausgestzt wir finden überhaupt nochmal einen, der Delphi als Entwicklungswerkzeug akzeptiert.
Einfach nur eine Programmiersprache zu beherrschen reicht noch lange nicht, um ein gutes Produkt zu bauen. Du brauchst das historische Wissen, warum manche Dinge so unfassbar schräg programmiert wurden. Du brauchst das fachspezifische Wissen um die Probleme die deine Software lösen soll. Große Firmen wie Microsoft haben dafür Manager, die nur fürs Denken und Erklären bezahlt werden. Dort braucht der Programmierer im Wesentlichen ein Lastenheft. Je kleiner aber die Firma, umso mehr Verantwortung haben die einzelnen Programmierer. Geht dann einer in Rente oder fällt aus anderen Gründen aus, ist das Chaos vorprogrammiert.
Ist das am Ende nicht die eigentliche "technische Schuld", um das Buzzword mal aufzugreifen? Der Wissenstransfer zwischen den Entwicklern?
Nicht nur zwischen Entwicklern. Es gibt da ja auch noch die "Fachabteilungen". Auch die müssen miteinander und mit den Entwicklern reden. Wenn das nicht klappt, geht sehr viel Energie durch Reibung verloren. Es wird Softwareentwicklern ja gerne nachgesagt, sie seien introvertiert und könnten/wollten nicht kommunizieren. Ja, solche Leute gibt es, aber nein, das ist nicht auf Softwareentwickler beschränkt, wie ich aus eigener Erfahrung weiß.
Vielleicht ist es genau das, was Open Source Software langfristig erfolgreicher macht. Die Wege sind manchmal länger, weil die quasidemokratischen Prozesse zu vielen Parallelentwicklungen führen (siehe Wildwuchs an Linux-Distributionen). Andererseits kann man dann aus vielen Lösungen die besten auswählen und macht das Gesamtkonstrukt am Ende besser.
Äh, nein. Zumindest UIs unter Linux sind ein graus (und das beschränkt sich nicht nur auf Linux, ich sage nur: "Thunderbird"). Da ist selbst der Mist, den Microsoft seit Windows 8 produziert hat, besser. Und was habe ich davon, wenn ich unter 50 E-Mail Clients aussuchen kann, die alle Mist sind? Es wäre was anderes, wenn ich mir für jede Kategorie von Programmen jeweils die Kombination von Features auswählen könnte, die ich gerne hätte, aber das geht ja leider nicht, man kann nur Programme auswählen.