Du hast ja sooo recht.
Gruß
K-H
Danke, daher hier gleich noch ein paar mehr Gedanken dazu:
Es ist oft die übliche Situation, auf die ich treffe: Motivierte neue Mitarbeiter mit gehobenen Kenntnissen scheitern am "Chefdesigner" (der oft auch Chef ist), der argumentiert, das das schon immer so gemacht wurde und da es ja funktioniert und die Software verkauft wird, auch nicht so schlecht sein kann.
Das die Branchenlösung meistens nur mangels alternativer Lösungen für die gleiche Branche eher auf Basis von Erpressung vom Kunden weiter benutzt wird, weil die nix anderes finden, wird dabei gerne von der Unternehmensleitung ignoriert, es sei den ein Wettbewerber kommt da auf einmal in die Quere und bietet auch nur ähnlich gute Branchen-Prozessqualität, aber mit wesentlich besser und schnellerer Bedienung der Software.
Dann wird man auf einmal hektisch und wirft alles über den Haufen, am besten noch Delphi ganz wegschmissen, Visual Studio .NET oder Java ist ja viel besser und es gibt ohne Ende verfügbare fähige Mitarbeiter, die das mal eben auf der Neuen Plattform zusammenbauen (was schon mal Bullshit ist, Verfügbarkeit von fähigen Programmierern ist im deutschsprachigen Raum eine Sozial- und Geldfrage. Wer in dieser Branche aktuell keinen Job hat, will entweder nicht wirklich einen Job, weil er nicht von seinem Heimatort weg will, übertriebene Vorstellungen von seinem Wert hat oder einfach nicht auf dem Level ist, auf dem er sich selber gerne sieht).
Techniken wie Entity Framework usw. liefern ja in der Präsentation für die Entscheidungsträger schnelle Prototypen, so das das alles ganz toll aussieht.
Der typische Delphi Programmierer im Team, der nun eigentlich nur noch den Quellcode am Leben halten soll, bis das neue Produkt dann von den Klugschnackern in spätestens 2 Jahren fertig ist, stellt sich eben auf Dienst nach Vorschrift mit anschließender Kündigung ein und wartet halt ab was da kommt, sucht aber evtl schon mal, ob nicht auch andere Mütter schöne Töchter haben, spricht neuer Arbeitgeber ist auf einmal gar nicht mehr so unwahrscheinlich wie vorher.
2-3 Jahre später ist der neue Kram immer noch Prototyp und unbenutzbar, der Delphi Programmierer hat mit wesentlich kleinerem Team trotzdem 2-3 Jahre lang das Produkt verbessert und die Klugschnacker mit der neuen Plattform überbieten sich dabei, neue Ausreden zu finden, warum man noch nicht so weit ist wie man dachte. Irgendwann merkt dann auch der blödeste, das da was schief läuft ...
Wenn der Neueinsteiger aber schon vorher versucht, seine Aufgaben mit optimaler Performance umzusetzen und diese Kenntnisse in der gesamten Produktentwicklung zu etablieren, das Stammpersonal dabei aber meistens ja schon mit kleinen Detailtechniken überfordert und oft aufgrund des Alters >=50 ziemlich ignorant ist, die eigenen Kenntnisse in Frage zu stellen oder auch nur zu kapieren, was physikalisch abläuft, dann leidet nicht nur das eigene Selbstbewusstsein für den Neueinsteiger, sondern auch die generelle Motivation.
Und selbst eigentlich banale und auch mit Grundschul-Physikkenntnissen nachvollziehbare Vorgänge werden ignoriert.
Dazu ein Beispiel aus der Delphi/Firebird Welt:
Wenn du einen execute block mit einem tcpip paket und 200 inserts darin vom client zum server sendest und der mit seinem cpu/ssd speed das dann abarbeiten kann, dann geht das kaum schneller.
Wenn aber der ignorante Kollege, der zwar mal vor 20 Jahren gelesen hat, das parametrisierte Queries besser sind, bei prepare und transaktionen aber nicht mehr aufgepasst hat, Wert darauf legt, das es immer so gemacht wird wie er das will, der sollte dann folgendes wissen: Pro parambyname werden mehrere tcpip packages hin und her jagt. Wenn er aber gar nicht hinterfragt, warum das 50 mal länger dauert wie die schnelle execute block Version, dann ist es schwierig, den zu überzeugen, wenn die Hierarchien es nicht hergeben.
Auf seinem lokalen Entwicklungsrechner mit kleiner Test-
DB und schneller SSD merkt er auch kaum einen Unterschied, also behauptet er einfach, das der Kram mit execute block quatsch ist.
Das sind nämlich bei zB 200 inserts mit je 50 Spalten dann eben mal ca. 50000 tcpip pakete. Diese dann multipliziert mit der Ping zeit (auch im Ms bereich) und 100 andere Clients, die den gleichen Müll programmiert haben, erstickt jedes Netzwerk ...
Bei genauer Analyse kommt zuerst fast immer eine Ausrede nach der anderen warum das so ist wie es ist, dann die Erkenntnis, das man was machen kann und muss. Die Dataset-Datasource Architektur ja ganz lustig ist für Mini Anwendungen, im Enterpriseumfeld hat die aber nix zu suchen und selbst bei kleineren Installationen ist die oft schon Unsinn, weil keiner eine klare und vollständige Aussage machen kann, was passiert, wenn man zB. auch nur eine Rechnung abschließt, weil keiner einen Überblick hat über die wild verschachtelten Events, die dann auch noch selber in der Datenbank rumkaspern.
Spätestens der Blick dabei ins Netzwerkprotokoll macht auch dem Blindesten deutlich, das Daten nachgeladen werden, die aber auch gar nicht mit dem aktuellen Vorgang zu tun haben. Der ach so schlaue Supertarchitekt hinter dem Quellcode sucht dann seine Ausreden zusammen, und dann hör ich immer wieder, das die Komponenten schuld sind, usw.. Erst später merkt er, das die Komponenten nur das machen, wofür er die einsetzt. Wenn du dir mit dem Hammer dauend auf den Finger haust, ist es ein Fehler, dafür den Hammer verantwortlich zu machen ...
Das Problem ist ja oft das der Prophet im eigenen Lande nichts wert ist, daher ist es insbesondere für einen Neueinsteiger im Unternehmen immer schwierig, den alteingesessenen Platzhirschen mal die Meinung zu geigen.
Wenn die Unternehmensleitung aber ein echtes Interesse aber eine Verbesserung hat, dann stehe ich für so was gerne bereit, weil ich nach meinem Auftrag wieder nach Hause fahren kann. Jedes Pseudo-Argument für beschissene Programmierung wird von mir auch als solches aufgezeigt, aber eben direkt mit Hinweise wie es besser geht und wie man es auch besser macht.
Die meisten Kunden, die mich für solche Aufträge gebucht haben, sind übrigens Wiederholungstäter und ein paar Wochen nach der erfolgreichen Umsetzung der ersten Optimierungen durch das eigene Team laden die mich dann wieder ein, um die neuen Kenntnisse auszubauen und neu aufgetretene Fragen entweder im extra Workshop zu klären oder per Hotline und Remote-Session zu diskutieren. Nicht selten kommt es dabei vor, das Mitarbeiter "der alten Garde" dabei dann schon gar nicht mehr dabei sind ...
Im Rahmen unserer Hotline Pakete machen wir übrigens auch einfach schon mal Remote Sessions, um das Netzwerkprotokoll bei Funktionen zu untersuchen, die unerklärlich langsam sind, das geht auch mit geringerem Budget ...