Moderne Entwicklungsmethoden - Anspruch und Wirklichkeit
-
Ich bin schon länger unzufrieden damit wie in meiner Firma gearbeitet wird. Da ich aber keinen wirklichen Vergleich zu anderen Firmen habe bin ich mir nie so richtig sicher, ob ich nicht einfach zu viel erwarte. Vielleicht habe ich auch nur zu lang das Gerede von irgendwelchen Silicon Valley Hipstern auf StackOverflow gelesen.
Die Firma ist ein kleiner Mittelständler und die Codebasis ist Teils bis zu 20 Jahre alt. Da bleiben viele Legacy-Sünden natürlich nicht aus. Wir maintainen immer noch einen System-Abstraktionslayer (Sachen wie Threads, Zeit, File-IO etc.). Das Build-System ist immer noch GNU make (auch unter Windows - mit msys), die offizielle "IDE" ist Emacs etc.
So weit so schlecht. Bis dahin könnte man natürlich immer argumentieren, dass es zu teuer wäre, diese Sachen mal auf einen neueren Stand zu bringen.
Viel schwerer wiegt, dass man sich immer pauschal gegen jede Neuerung stellt um die (furchtbare) Codequalität zu erhöhen.
Es gibt einen Styleguide an den sich niemand hält, schon gar nicht der leitende Entwickler.
Eben dieser leitende Entwickler produziert Code der direkt aus den 90ern stammen könnte. C mit Klassen, riesige "Module", die wiederum von anderen, ebenso riesigen Modulen, abhängig sind. Public Member, leaky Abstractions und er scheut sich auch nicht eine 2000-Zeilen Klasse zu duplizieren um in der zweiten Variante ein paar Sachen ändern zu können.
Unit Tests gibts nur für Dinge, die sowohl sehr kritisch sind und sich leicht testen lassen wie beispielsweise mathematische Algorithmen. Der Wert von testbaren Code, der positive Einfluss auf das ganze Design wird negiert.
Ansonsten gibt es gar keine automatischen Test (Integrations-, Systemtests etc.).
Es gibt keine Testabteilung oder wenigstens eine klar definierte Testphase. Neue Versionen gehen meistens direkt zum Kunden, wenn man gerade keinen kritischen Bug mehr gefunden hat - und scheitern dort regelmäßig.
Code Reviews gibts höchstens für wirklich umfangreiche oder kritische Aufgaben, dass ist dann eber eher ein "zeig dem Chef was du gemacht hast", nicht das, was ich mir unter einem Code Review vorstelle.
Neuen Technologien steht man erst mal grundsätzlich ablehnend gegenüber. Am liebsten möchte man alles selbst implementieren und der Einwand, dass Tool X oder Bibliothek Y genau diese Probleme löst wird meistens ohne weitere Diskussion abgeschmettert.
Von Dingen wie Continuous Integration oder einem agilen Entwicklungsprozess will ich gar nicht erst anfangen. Ich bin schon froh, dass wir endlich CVS durch git ausgetauscht haben und das Projektmanagement nicht mehr mit Emacs Org Mode machen.OK, ich weiß, dass in der Firma so Einiges schief läuft. Ganz so schlimm sollte es in der Regel wohl nicht sein. Trotzdem habe ich bis jetzt beim Studieren von Stellenangeboten nicht den Eindruck gehabt, dass sich moderne Entwicklungsmethoden schon bis in die C++ Welt rumgesprochen haben. Sowas finde ich wenn dann eher in der Java und C# Welt und auch da eher bei jungen Firmen.
Erwarte ich wirklich einfach zu viel, wenn ich automatische Tests, Code Reviews, Bibliotheken und modernen Tools für selbstverständlich bei der Entwicklung von neuem Code halte?
-
maximAL schrieb:
Erwarte ich wirklich einfach zu viel, wenn ich automatische Tests, Code Reviews, Bibliotheken und modernen Tools für selbstverständlich bei der Entwicklung von neuem Code halte?
Nein. Aber wie du schon beobachtet hast, und wie ich ebenfalls bestätigen kann, besteht ein deutlicher Zusammenhang zwischen Alter der Abteilung und Modernität der Entwicklungsmethoden. Methoden ändern sich gar nicht, oder nur sehr langsam, wenn sie erst einmal etabliert sind. Es ist schließlich auch gerade ihr Sinn, für ein gewisses Maß an Stabilität und Einheitlichkeit bei der Zusammenarbeit von Menschen zu sorgen.
Das trifft nicht nur auf Programmierung, sondern auf so ziemlich alles in der Welt zu.
-
SeppJ schrieb:
Aber wie du schon beobachtet hast, und wie ich ebenfalls bestätigen kann, besteht ein deutlicher Zusammenhang zwischen Alter der Abteilung und Modernität der Entwicklungsmethoden. Methoden ändern sich gar nicht, oder nur sehr langsam, wenn sie erst einmal etabliert sind.
Das bedeutet dann aber zwangsläufig, dass Berufserfahrung im Bereich der Softwareentwicklung (jenseits von ein paar Jahren) praktisch wertlos ist. Und tatsächlich habe ich auch noch keinen älteren Softwareentwickler getroffen, von dem ich wirklich etwas hätte lernen können. Außer irgendwelche Kriegsgeschichten, wie man damals in den frühen 90ern auf irgendeinem obskuren Unix-System...
-
Kündigen, Firma wechseln, wenn du etwas aus dir hältst.
-
maximAL schrieb:
Und tatsächlich habe ich auch noch keinen älteren Softwareentwickler getroffen, von dem ich wirklich etwas hätte lernen können.
Das stimmt so nicht, ich hab durchaus einige ältere Entwickler kennengelernt, von denen ich was gelernt habe, bzw. immer noch lernen könnte.
SeppJ schrieb:
Aber wie du schon beobachtet hast, und wie ich ebenfalls bestätigen kann, besteht ein deutlicher Zusammenhang zwischen Alter der Abteilung und Modernität der Entwicklungsmethoden.
Das kann ich auch an mir selber beobachten. Ich bin 30, vor sechs Jahren in der Firma angefangen. Hatte schon Berufserfahrung in anderen Firmen und auch privat sehr viel gemacht, hatte aber noch keinen Bezug zu dem, was die Firma macht. Deswegen auch erstmal den Eindruck bekommen, dass vieles nicht optimal läuft (ist natürlich auch so), und dass man vieles verbessern könnte. Anfangs war ich da auch viel aktiver dabei, Verbesserungsvorschläge zu machen. Mittlerweile bin ich viel tiefer in der eigentlichen Thematik drin, hab sehr viele Projekte und sehr viel Supportaufwand für abgeschlossene Projekte, und mich interessiert vieles einfach nicht mehr. Ich hab überhaupt keine Zeit und keine Lust, mich mit irgendwas "nebensächlichem" zu beschäftigen, was mich von meinen Kernprojekten ablenkt. Wenn neue Entwickler auf mich zukommen und irgendwas vorschlagen und meinen, könnten wir nicht..., denke ich mir meist nur noch, was interessierts mich jetzt? Will ich mir jetzt die Zeit nehmen, das zu evaluieren, zu testen, umzubauen, um dann (und das weiß ich schon sehr gut aus Erfahrung) über irgendwas drüberzustolpern, was niemand berücksichtigt hat?
Das betrifft bei mir persönlich aber nicht C++ an sich, ich schau mir z.B. neue Videos von der cpp con usw. an, da will ich schon wissen, was sich tut. Wenn aber irgendwelche Leute mit neuen Hype Sprachen wie Go oder Rust ankommen, bin ich erstmal nur genervt. Bei sowas würd ich sicher nicht den Betatester spielen.Ansonsten ist es bei uns nicht ganz so schlimm, wie bei euch. Auch teilweise über 20 Jahre alter Code mit Klassen, die über zig tausend Zeilen gehen. Aber vieles ist auch deutlich moderner, vieles wird umgebaut usw.
"Continuous Integration" haben wir, nennen das aber nicht so. Der Begriff sagt aber erstmal nicht so viel darüber aus, welchen Nutzen das tatsächlich hat.
Tests sind schwierig... Wir haben eine größere Testabteilung, die ist aber nicht sehr effektiv und findet viel eher irgendwelche Kleinigkeiten, als wichtige Bugs. An automatischen Tests arbeiten wir schon seit Jahren. Aber sehr weit sind wir da auch noch nicht gekommen. Zum einen ist die Software nicht sehr gut testbar, ist halt kein Java
Zum anderen ist das alles sehr komplex und viele der wichtigeren Workflows erstrecken sich über sehr viele Komponenten und hängen auch sehr stark von irgendwelchen Daten ab. Und viele wirklich sinnvolle Tests haben wir dafür noch nicht hinbekommen.
-
maximAL schrieb:
Erwarte ich wirklich einfach zu viel, wenn ich automatische Tests, Code Reviews, Bibliotheken und modernen Tools für selbstverständlich bei der Entwicklung von neuem Code halte?
Ja doch, das ist ein wenig viel erwartet.
Also so wie du das schreibst. Also alles zusammen und "selbstverständlich" - neh. Du wirst nicht SO viele Firmen finden die das alles so machen/haben.Aber deutlich besser als das was du beschreibst geht schon.
-
maximAL schrieb:
Viel schwerer wiegt, dass man sich immer pauschal gegen jede Neuerung stellt um die (furchtbare) Codequalität zu erhöhen.
Es gibt einen Styleguide an den sich niemand hält, schon gar nicht der leitende Entwickler.
Eben dieser leitende Entwickler produziert Code der direkt aus den 90ern stammen könnte.Solche Leute haben es sogar geschafft, dass eine saubere Arbeitsweise allgemein als "modern" verunglimpft wird (siehe Thread-Titel). "Schluderei war in den 90ern in Ordnung, weil das alle so gemacht haben und was alt ist, ist bewährt, also ist Schluderei heute erst recht in Ordnung."
Hier spielen meiner Meinung nach zwei Faktoren zusammen: Ein breites, aber ungleichverteiltes Spektrum an Erwartungen an eine Arbeitsstelle und eine Verherrlichung von Altem.
Die meisten Software-Entwickler arbeiten nur für das Geld am Ende des Monats und haben keine intrinsische Motivation etwas besser zu lösen als gestern. Dafür sind vermutlich am meisten die Schulen verantwortlich, die langfristiges Denken und persönliche Interessen und Stärken systematisch bestrafen. Die wenigen Entwickler, die ständige Verbesserung suchen, sind in der Minderheit und dadurch automatisch unterlegen. Die Mehrheit findet immer Argumente gegen Verbesserungsvorschläge, interessiert sich aber wie gesagt kaum für langfristige Verbesserungen. Das Unternehmen muss nur bis zur nächsten
KlassenarbeitLieferung überleben.Die Verherrlichung von alten Dingen als zweiter großer Faktor wird zufällig auch durch Schulen gefördert. Geschichte wird auf wenige bekannte Persönlichkeiten reduziert, die eine Art Spiel nach logischen Regeln gespielt haben, das am Ende immer gut ausging (der böse Zar hat gegen Lenin gespielt und Lenin hat gewonnen, weil er der Gute war und alles war gut bis der nächste Schurke aufgetaucht ist). Geschichte wird von den Siegern geschrieben, sozusagen. Dieses Konzept ist tief in unserer Kultur verankert. Es findet sich in den meisten fiktiven Geschichten wieder. Ich will darauf hinaus, dass Legacy-Schrott immer als gut genug verteidigt werden kann. Er stammt schließlich von den Altehrwürdigen, die etwas Langlebiges in die Welt gesetzt haben und deswegen die Guten sind. Die haben es gut mit uns gemeint und wir dürfen ihre Genialität nicht in Frage stellen.
Warum etwas riskieren, wenn ich einfach den Weg der vermeintlichen Sieger weitergehen kann?
-
TyRoXx schrieb:
Solche Leute haben es sogar geschafft, dass eine saubere Arbeitsweise allgemein als "modern" verunglimpft wird (siehe Thread-Titel). "Schluderei war in den 90ern in Ordnung, weil das alle so gemacht haben und was alt ist, ist bewährt, also ist Schluderei heute erst recht in Ordnung."
maximALs Horrorabteilung ist schluderig und unmodern. Es gab schon noch wesentliche Veränderungen in der Softwareentwicklung seit den 1990ern. Die damaligen und die moderneren Methoden kann man natürlich beide schlampig umsetzen.
Warum etwas riskieren, wenn ich einfach den Weg der vermeintlichen Sieger weitergehen kann?
Das ist ja schon oft sinnvoll, nichts unnötig zu riskieren. Risiko heißt auch, dass man verlieren kann und oft kann man sich diese Möglichkeit eben nicht leisten (egal ob bei Softwareentwicklung oder sonst irgendwas). Daher ist es schon oft vernünftig, auf bewährte Methoden zu setzen. Die mögen zwar nicht optimal sein, aber oft reicht es, wenn etwas überhaupt funktioniert. Es muss nämlich nicht immer alles höchst optimal sein, aber ein Ausfall wäre fatal.
Der echte Druck zu Neuerung kommt erst auf, wenn
a) Man sich erlauben kann, ein solches Risiko einzugehen und sich davon ein Szenario wie in c erhofft. Alternativ kann das Risiko auch einfach sehr gering sein, so dass es nichts kostet, zu experimentieren.
b) Man neu einsteigt und ein Risiko eingehen muss, weil die Konkurrenz mit ihren bewährten Methoden zu weit voraus ist.
c) Man nachziehen muss, weil ein Konkurrent mit einer erfolgreichen Neuerung davon gezogen ist.Das gilt wieder ganz allgemein für jeden Fortschritt, nicht nur für Softwareentwicklung.
Und klar, die Schule vermittelt die bewährten Methoden. Welche auch sonst? Sie ist schließlich dazu da, das Wissen früherer Generationen weiter zu geben und kann gleichzeitig auch noch nicht wissen, welches Neuerungen von heute überhaupt Bestand haben werden.
-
ShadowClone schrieb:
Kündigen, Firma wechseln, wenn du etwas aus dir hältst.
Ist in Arbeit. Mir geht es ja gerade darum mal ein realistisches Bild zu bekommen, was ich so erwarten kann. Wenn ich mit zu hohen Erwartungen rangehe bringt mir das ja auch nichts. Bis jetzt habe ich nur Start Ups im Java-Umfeld gesehen, die sich sowas auf die Fahne schreiben, allerdings fehlt mir da wieder der Backgrund (EE, RCP, EMF, GEF, WTF...).
Mechanics schrieb:
Das stimmt so nicht, ich hab durchaus einige ältere Entwickler kennengelernt, von denen ich was gelernt habe, bzw. immer noch lernen könnte.
Das war natürlich ausdrücklich meine persönliche Erfahrung.
Mechanics schrieb:
"Continuous Integration" haben wir, nennen das aber nicht so. Der Begriff sagt aber erstmal nicht so viel darüber aus, welchen Nutzen das tatsächlich hat.
Wir haben zum Beispiel das Problem, dass Teile des Codes von verschiedenen Produkten benutzt werden, welche wiederum auf verschiedenen Plattformen laufen und teils mit mehreren Compilern übersetzt werden. Es ist einfach nicht praktikabel das bei jeder Änderung für alle Kombinationen von Hand zu machen. Genau für sowas sind CI Server und Unit Tests da.
TyRoXx schrieb:
Die meisten Software-Entwickler arbeiten nur für das Geld am Ende des Monats und haben keine intrinsische Motivation etwas besser zu lösen als gestern.
Das Schlimme ist, dass ich es hier wirklich mit Überzeugungstätern zu tun habe. Denen ist das nicht einfach egal, die finden ihre Arbeitsweise allen ernstes gut und haben immer eine gute Begründung parat, warum man das jetzt so und nicht anders machen kann. Und wenn mir ein Senior-Entwickler sagt, dass man Funktionen nicht zum Strukturieren von Code verwenden sollte sondern nur für die Wiederverwendung, dann fällt mir dazu auch nichts konstruktives mehr ein.
-
SeppJ schrieb:
Das ist ja schon oft sinnvoll, nichts unnötig zu riskieren. Risiko heißt auch, dass man verlieren kann und oft kann man sich diese Möglichkeit eben nicht leisten (egal ob bei Softwareentwicklung oder sonst irgendwas). Daher ist es schon oft vernünftig, auf bewährte Methoden zu setzen. Die mögen zwar nicht optimal sein, aber oft reicht es, wenn etwas überhaupt funktioniert. Es muss nämlich nicht immer alles höchst optimal sein, aber ein Ausfall wäre fatal.
Das ist exakt die Argumentation der Schluderer. Besser hätte ich es nicht treffen können. Mal von mir auf Deutsch übersetzt: Verbesserung ist nur ein Risiko, Experimente sind immer zu teuer. Lernen ist zu teuer. Man müsste zugeben, dass man Fehler gemacht hat. Wer Fehler macht, wird nie ein Sieger der Geschichte werden. "Bewährte" (alte) Methoden sind immer die vernünftige Wahl (siehe mein vorheriger Beitrag). Wenn es ab und zu mal gut funktioniert, rechtfertigt das rück- und fortwirkend jeden vermeidbaren Rückschlag. Ausfälle nach Verbesserungen liegen nur an den Verbesserungen. Ausfälle ohne Verbesserungen sind normal. Software hat eben Bugs und es ist nicht möglich etwas dagegen zu unternehmen.
maximAL schrieb:
Und wenn mir ein Senior-Entwickler sagt, dass man Funktionen nicht zum Strukturieren von Code verwenden sollte sondern nur für die Wiederverwendung, dann fällt mir dazu auch nichts konstruktives mehr ein.
Stimmt, das fällt mir auch oft auf. Es ist fast so als wüssten diese Leute unbewusst, was gut und was eher schlecht ist. Schlechte Entwickler identifizieren sich dann irgendwie mit den schlechten Ideen und verteidigen diese vehement. Ein seltsames Phänomen.
EDIT: Wahrscheinlich ist es eher so, dass diese Leute zufällig irgendwelche Ideen verteidigen, weil sie nicht einschätzen können, was gut ist. Ja, das passt besser zu den "ich mag das aber lieber"-Totschlägern. Sie verteidigen also auch mal gute Ideen, was mir nur nicht auffällt, weil ich meistens übereinstimme. Die Gesamtanzahl der schlechten Ideen ist höher als die der guten, also je zufälliger jemand seine Vorlieben auswählt, desto schlechter ist sein Geschmack.
maximAL schrieb:
Das Schlimme ist, dass ich es hier wirklich mit Überzeugungstätern zu tun habe. Denen ist das nicht einfach egal, die finden ihre Arbeitsweise allen ernstes gut und haben immer eine gute Begründung parat, warum man das jetzt so und nicht anders machen kann.
Denen ist egal, ob sie etwas gut finden, weil es gut ist oder nur wegen einer zufälligen Vorliebe. Jeder verteidigt aber gerne seine Vorlieben.
-
@TyRoXx
Dieses Argument wird gerade deswegen so gerne vorgeschoben, eben WEIL es manchmal total zutrifft und schwerer wiegt als alles andere.Dass ein bestimmtes Argument oft als Entschuldigung/Verschleierung für Faulheit/Trägheit/... vorgeschoben wird, heisst ja nicht dass es nie stimmt und man sich nie danach richten sollte. Es heisst nur dass man hellhörig werden sollte und sehr genau hingucken/abwägen ob es auf die jeweilige Situation bezogen auch so ist.
Zu sagen dass das Argument immer Quatsch ist (und so interpretiere ich deinen Beitrag - falls das nicht stimmt bitte nicht übel nehmen sondern einfach korrigieren), halte ich daher auch für falsch.
Das umgekehrte Problem gibt es nämlich genau so. Leute die immer alles besser/moderner/XYZ-iger machen wollen, und dabei viel viel mehr kaputt machen/verschlechtern als richten/verbessern. Und auch diese finden ihre Arbeitsweise voll OK und gut und richtig.
Ist halt alles leider nicht so einfach. Man muss sich jeden Fall immer wieder aufs neue angucken und versuchen abzuschätzen was wann wie wo und warum die beste Lösung wäre. (Und das "leider" ist hier jetzt kein "spitze Formulierung" die Zynismus/Sarkasmus kennzeichnet, sondern ich meine das ganz ernst. Ich zumindest finde das schon sehr ermüdend. Hilft aber nix, ändert sich deswegen ja nicht.)
-
TyRoXx schrieb:
Das ist exakt die Argumentation der Schluderer. Besser hätte ich es nicht treffen können. Mal von mir auf Deutsch übersetzt: Verbesserung ist nur ein Risiko, Experimente sind immer zu teuer. Lernen ist zu teuer. Man müsste zugeben, dass man Fehler gemacht hat. Wer Fehler macht, wird nie ein Sieger der Geschichte werden. "Bewährte" (alte) Methoden sind immer die vernünftige Wahl (siehe mein vorheriger Beitrag). Wenn es ab und zu mal gut funktioniert, rechtfertigt das rück- und fortwirkend jeden vermeidbaren Rückschlag. Ausfälle nach Verbesserungen liegen nur an den Verbesserungen. Ausfälle ohne Verbesserungen sind normal. Software hat eben Bugs und es ist nicht möglich etwas dagegen zu unternehmen.
Es ist eben sehr oft im Leben existenzbedrohend, wenn ein Plan nicht funktioniert. Ist das so schwer zu verstehen? Esse ich lieber nur die Pilze, von denen mir die Alten erzählt haben, dass ich sie essen darf, oder probiere ich lieber alle einmal aus, um zu sehen, ob ich meine Ernte steigern kann? Setze ich das Firmenkapital ein, um mit bewährten Methoden ein Produkt auf den Markt zu bringen, oder riskiere ich Insolvenz, um eventuell ein besseres Produkt entwickeln zu können?
Das man damit auch Unaufgeschlossenheit gegenüber Neuerungen verteidigen kann, macht diese Einstellung nicht generell falsch.
-
maximAL schrieb:
Es gibt einen Styleguide an den sich niemand hält, schon gar nicht der leitende Entwickler.
Es gibt dafür keine Argumente. Es hat sich nicht bewährt, dass jeder so programmiert, wie es ihr gerade passt.
maximAL schrieb:
C mit Klassen, riesige "Module", die wiederum von anderen, ebenso riesigen Modulen, abhängig sind. Public Member, leaky Abstractions und er scheut sich auch nicht eine 2000-Zeilen Klasse zu duplizieren um in der zweiten Variante ein paar Sachen ändern zu können.
Dafür gibt es auch keine Argumente. Nein, wirklich nicht. Solche Leute verursachen mehr Arbeit als sie erledigen. Diese Art von Schluderei hat sich auch nicht bewährt. Nicht alles, was gängig ist, ist automatisch "bewährt"!
maximAL schrieb:
Unit Tests gibts nur für Dinge, die sowohl sehr kritisch sind und sich leicht testen lassen wie beispielsweise mathematische Algorithmen. Der Wert von testbaren Code, der positive Einfluss auf das ganze Design wird negiert.
Ansonsten gibt es gar keine automatischen Test (Integrations-, Systemtests etc.).Dafür gibt es keine Argumente. Software braucht immer automatische Tests. Die wegzulassen hat sich nicht bewährt.
maximAL schrieb:
Es gibt keine Testabteilung oder wenigstens eine klar definierte Testphase. Neue Versionen gehen meistens direkt zum Kunden, wenn man gerade keinen kritischen Bug mehr gefunden hat - und scheitern dort regelmäßig.
Kunden mögen so etwas akzeptieren, wenn sie keine andere Wahl sehen. Das hat sich aber nicht "bewährt"!
maximAL schrieb:
Code Reviews gibts höchstens für wirklich umfangreiche oder kritische Aufgaben, dass ist dann eber eher ein "zeig dem Chef was du gemacht hast", nicht das, was ich mir unter einem Code Review vorstelle.
Code Reviews lohnen sich immer. Software ist unheimlich komplex. Man kann nicht erwarten, dass mehrere Entwickler sinnvoll zusammenarbeiten ohne voneinander zu wissen. Blind Code einzuchecken ohne jede Überprüfung durch andere Menschen hat sich nicht bewährt.
maximAL schrieb:
Neuen Technologien steht man erst mal grundsätzlich ablehnend gegenüber. Am liebsten möchte man alles selbst implementieren und der Einwand, dass Tool X oder Bibliothek Y genau diese Probleme löst wird meistens ohne weitere Diskussion abgeschmettert.
Alles selbst zu machen hat sich nicht bewährt.
maximAL schrieb:
Von Dingen wie Continuous Integration oder einem agilen Entwicklungsprozess will ich gar nicht erst anfangen.
Auf CI zu verzichten hat sich nicht bewährt. Wild in der Gegend herumzuentwickeln hat sich nicht bewährt.
SeppJ schrieb:
Es ist eben sehr oft im Leben existenzbedrohend, wenn ein Plan nicht funktioniert.
Es ist existenzbedrohend sich nicht der Realität der Gegenwart anzupassen. Mehr sage ich doch gar nicht.
SeppJ schrieb:
Ist das so schwer zu verstehen? Esse ich lieber nur die Pilze, von denen mir die Alten erzählt haben, dass ich sie essen darf, oder probiere ich lieber alle einmal aus, um zu sehen, ob ich meine Ernte steigern kann?
Oder man kauft einfach die Pilze in einem seriösen Geschäft. Da bekommt man garantiert keine giftigen.
SeppJ schrieb:
Setze ich das Firmenkapital ein, um mit bewährten Methoden ein Produkt auf den Markt zu bringen, oder riskiere ich Insolvenz, um eventuell ein besseres Produkt entwickeln zu können?
Gerne bewährte Methoden. Schluderei ist keine bewährte Methode. Das ist meine Argumentation.
SeppJ schrieb:
Das man damit auch Unaufgeschlossenheit gegenüber Neuerungen verteidigen kann, macht diese Einstellung nicht generell falsch.
Eine saubere Arbeitsweise ist keine Erfindung des 21. Jahrhunderts. Alt=schlecht ist ein Strohmann. Darum geht es gar nicht. Ich verwende auch gerne C++, obwohl es uralt ist. Ich weiß aber, wie man es verwendet und warum neue Standards besser sind. Schluderer lehnen neue Standards ab, weil sie neu sind, weil sie glauben, dass Nicht-Schluderer alles ablehnen, was alt ist. Nicht zu wissen, warum man etwas so macht, wie man es macht, kritisiere ich hier.
hustbaer schrieb:
Das umgekehrte Problem gibt es nämlich genau so. Leute die immer alles besser/moderner/XYZ-iger machen wollen, und dabei viel viel mehr kaputt machen/verschlechtern als richten/verbessern. Und auch diese finden ihre Arbeitsweise voll OK und gut und richtig.
Richtig, das gibt es auch in der anderen Richtung. Das nennt man Hype, glaube ich. Man muss wissen, warum man etwas macht.
-
TyRoXx schrieb:
hustbaer schrieb:
Das umgekehrte Problem gibt es nämlich genau so. Leute die immer alles besser/moderner/XYZ-iger machen wollen, und dabei viel viel mehr kaputt machen/verschlechtern als richten/verbessern. Und auch diese finden ihre Arbeitsweise voll OK und gut und richtig.
Richtig, das gibt es auch in der anderen Richtung. Das nennt man Hype, glaube ich. Man muss wissen, warum man etwas macht.
Ich hätte jetzt gesagt man nennt das "dumme Leute"
-
meine Erfahrung ist: die (vermeintlich) guten kämpfen zu wenig - resignieren oder gehen dann
Es gibt wenige Entwickler die (lange)genug Arsch in der Hose haben (=Ausdauer+Fähigkeit) um Karren dauerhaft aus dem Dreck zu ziehen
(kann auch mal(oder oft) Jahre dauern)kein sinnloses kämpfen - aber auch nicht zu früh (paar Monate harter arbeit an dem Zustand sollte schon sein) die Flinte ins Korn werfen können in vielen Situationen was bringen
-
Gast3 schrieb:
meine Erfahrung ist: die (vermeintlich) guten kämpfen zu wenig - resignieren oder gehen dann
Wo gehen die dann hin?
-
TyRoXx schrieb:
Gast3 schrieb:
meine Erfahrung ist: die (vermeintlich) guten kämpfen zu wenig - resignieren oder gehen dann
Wo gehen die dann hin?
Zur nächsten Klitsche, in der es am Ende auch nicht besser läuft natürlich
-
Du musst vielleicht auch einfach lang genug dabei bleiben, bis du auch was zu sagen hast. Bei mir hats auch 1-2 Jahre gedauert, bis ich mich durchsetzen konnte. Wenn man sieht, dass deine Projekte laufen und du nicht nur leeres "modernes" Geschwätz von dir gibst, wird man eher auf dich hören.
-
Mechanics schrieb:
Du musst vielleicht auch einfach lang genug dabei bleiben, bis du auch was zu sagen hast. Bei mir hats auch 1-2 Jahre gedauert, bis ich mich durchsetzen konnte. Wenn man sieht, dass deine Projekte laufen und du nicht nur leeres "modernes" Geschwätz von dir gibst, wird man eher auf dich hören.
Der Kampf hört nie auf, weil jede erfolgreiche Maßnahme ganz schnell als selbstverständlich wahrgenommen wird, aber sich keine Kultur der ständigen Verbesserung einstellt. Je mehr Werkzeuge und Methoden man einführt, desto öfter ist man auch pauschal für alle Probleme damit verantwortlich.
-
andere Moeglichkeit: "leading by example". Ich hab auch in diversen chaos-projekten gearbeitet, aber gerade dann wenn Vorgaben und Richtlinien fehlen hat man meist Gestaltungsfreiraum weil eh jeder tut was er will. Was haelt Dich also ab fuer Deine Komponenten guten Code zu schreiben oder automatisierte UTs zu haben?
Spaetestens wenn du im groessten Projektstress immer rechtzeitig fertig bist waehrend andere noch ewig ihren Quatsch debuggen wird es Nachahmer geben :).
-
Mechanics schrieb:
Du musst vielleicht auch einfach lang genug dabei bleiben, bis du auch was zu sagen hast. Bei mir hats auch 1-2 Jahre gedauert, bis ich mich durchsetzen konnte. Wenn man sieht, dass deine Projekte laufen und du nicht nur leeres "modernes" Geschwätz von dir gibst, wird man eher auf dich hören.
Hey, ich bin seit über 5 Jahren dabei. Und tatsächlich haben die Sachen, die ich selbstständig umsetzen konnte gut funktioniert, während die Sachen, bei denen mit permanent reingeredet wurde regelmäßig in die Hose gegangen sind.
Das Problem ist einfach, dass die Vorgesetzten die gute Arbeit nicht sehen, weil das Themen sind, in denen die nicht drin stecken. Dort wo sie ihre Nase reinstecken und alles auf ihre Art gemacht haben wollen sehen sie dann, dass es nicht funktioniert - was dann natürlich meine Schuld ist.
Außerdem gibt es hier kein wirkliches Qualitätsbewusstsein. Es wird als normal betrachtet, dass man viel Zeit mit der Fehlersuche verbringt. Teils werden Mannmonate ins Debugging von einer Komponente gesteckt, das scheint niemanden zu stören. Investiert man hingegen Zeit für ein sauberes Design, schreibt Unit Tests etc., dann dauert das natürlich erst mal länger und man steht unter Rechtfertigungsdruck. Dass das Zeug dann aber funktioniert und nicht mehr ständig angefasst werden muss sieht nachher natürlich keiner.TheBigW schrieb:
Spaetestens wenn du im groessten Projektstress immer rechtzeitig fertig bist waehrend andere noch ewig ihren Quatsch debuggen wird es Nachahmer geben
Wir entwickeln hier aber eigene Produkte, die Monate und Jahre verschoben werden. Und es gibt hier auch nicht einfach "meinen Code" und "deren Code", weil die Aufgaben ständig verschiedenen Entwickler zugeteilt werden. Da hast du dann das Problem, dass sonst keiner versteht was deine Unit Tests eigentlich tun und der Code anderer Leute nicht getestet oder überhaupt testbar ist.
