wieso müssen programmierer immer anderer leute software schlecht reden?
-
Achja, meine Antwort zu dem Thema:
Weil anderer Leute Software einfach schlecht ist.Die eigene meist auch, nur bei der eigenen ...
... weiss man warum man bestimmte Dinge so gemacht hat wie sie sind (und dass sie aus "gutem Grund" suboptimal sind)
... weiss man was bestimmte Dinge bedeuten die vielleicht andere nicht checken, weil man sie selbst verbrochen hat
... muss man sich nicht einarbeiten, weil man sich schon auskennt, und merkt daher nicht wie schrecklich unübersichtlich das ganze ist
... weiss man wenn man einen Bug findet wie viele ander man schon im Vorfeld vermieden hat, bzw. wie viele andere man schon gefixt hat, und denkt sich "im Verhältnis dazu ist der eine Bug ja *nichst*"
uswusf.D.h. man sieht einfach nicht wie schlecht die eigene Software ist. Natürlich gibt es auch einige die immer alles toller finden was sie selbst machen. Da ich selbst von "anderer Leute Software ist Scheisse" Phänomen betroffen bin, allerdings nicht grundsätzlich alles gut finde was ich macht (bin da eher überkritisch), denke ich dass vielleicht auch bei anderen Programmierern der "sich selbst toll finden" Faktor weniger eine Rolle spielt.
-
hustbaer schrieb:
Hmmm...
Weiss nicht ob es Sinn macht das so zu sehen/zu formulieren.Also ich meine Leute die Code schreiben der nicht dem entspricht was sie selbst als "das wäre optimal" definieren würden.
Doch doch, "optimal" ist, wenn der Abstand zwischen Soll und Ist nach einer gewählten Norm 0 bzw möglichst klein ist.
Du hast eine Sollfunktion, faltest diese mit der Wahrnehmungsfunktion des Programmierers, und subtrahierst davon die Outputfunktion des Programmierers - davon wird das Minimum gesucht.
Ein Programmierer liefert als eine Lösung des Minimierungsproblems:
min | sollfunktion * problemwahrnehmungsfunktion - outputfunktion |
Offensichtlich gibt es für 2 Programmierer mit unterschiedlichen problemwahrnehmungsfunktion1 und problemwahrnehmungsfunktion2 unterschiedliche Lösungen des Minimierungsproblems, d.h. Programmierer 1 wird die für 2 optimale Lösung nicht als solche erkennen, und umgekehrt.
Man kann dieses Dilemma nur auflösen, wenn man die Minimierung in den mehrdimensionalen Raum zieht, d.h. mehrere Personen arbeiten gemeinsam daran, wodurch deren problemwahrnehmungsfunktion vereinheitlicht wird.
-
@Marc++us:
Och da könnte ich jetzt viel dazu schreiben aber das würde boss zu tl;dr führen.
Kurz: hast du schön geschrieben, aber Menschen funktionieren nicht so.Eines Sache vielleicht doch noch schnell...
jeder Programmierer erstellt Software, die nach seinem Meßprinzip "optimal" ist.
Das heisst für mich ganz klar dass sich "Meßprinzip" hier auf die Software bezieht. Und das wiederum schliesst für mich aus, dass weitere Parameter mit "gemessen" (bewertet) werden, die mit der Software gar nichts zu tun haben. (z.B. wie sehr sich jmd. anstrengen will ist kein Parameter der Software die er schreibt, es beeinflusst bloss die Software die er schreibt).
(EDIT: wie sehr sich jmd. anstrengen will könnte man auch als Konstant ansehen, und Konstanten sind natürlich in der Bewertungsfunktion OK. Der Parameter wäre dann wie sehr er sich wirklich anstrengt, und das hat eben wieder nichts in einer Bewertungsfunktion für Software zu suchen, da es ja kein Parameter der Software ist /EDIT)Zumindest habe ich deine Aussage so verstanden. Und da so mMn. kein Schuh draus wird, meine ich auch dass ich nicht sicher bin ob es Sinn macht das so zu formulieren. (Bzw. ich bin mir fast sicher dass es keinen Sinn macht
)
-
Marc++us schrieb:
d.h. mehrere Personen arbeiten gemeinsam daran, wodurch deren problemwahrnehmungsfunktion vereinheitlicht wird.
Oft resignieren sie auch vor der verdrehten Problemwahrnehmungsfunktion der Mitstreiter - dann finden einige Entwickler das eigenen Produkt auch scheiße
-
@pumuckl: das ist dann eine Führungsaufgabe.
-
hustbaer schrieb:
Das heisst für mich ganz klar dass sich "Meßprinzip" hier auf die Software bezieht. Und das wiederum schliesst für mich aus, dass weitere Parameter mit "gemessen" (bewertet) werden, die mit der Software gar nichts zu tun haben. (z.B. wie sehr sich jmd. anstrengen will ist kein Parameter der Software die er schreibt, es beeinflusst bloss die Software die er schreibt).
Das steckt doch in meiner Outputfunktion drin - die Konvergenzgeschwindigkeit für die Minimumsuche wird durch Fähigkeit und Geschwindigkeit des Programmierers beeinflusst. Und der Fleiß steckt in der Meßfunktion, d.h. mancher ist erst mit 99,9% Übereinstimmung zufrieden, andere bereits mit 80%.
-
Ich finde Dokumentation toll. Ich mag sie aber nicht schreiben, weil das öde ist. Wenn ich sie nicht schreibe, ist der einzig positive Effekt dass ich etwas nicht machen musste was ich öde finde. Dieser Effekt ist aber flüchtig, es bleibt nichts übrig was man bewerten könnte. Ausser der fehlenden Doku.
Das bleibende Resultat schlägt sich also ausschliesslich negativ in der Messung nieder - die Doku ist ja nicht da, und ich finde Doku super, ist also gegenüber der Alternative wo es eine Doku gegeben hätte schlechter. Sogar die Erinnerung daran die Doku nicht geschrieben zu haben bewerte ich nicht positiv sondern negativ, weil ich ja ein schlechtes Gewissen habe.
Und ich sehe keine Möglichkeit das in eine Messfunktion welche Parameter der Software messen soll reinzubekommen.
Ich kann ja eine Messfunktion die den ist-Zustand für des Systems X misst nicht einfach anpassen, nur weil vor ein paar Tagen mal kurz ein Parameter des Systems Y einen bestimmten Wert hatte. Das macht doch keinen Sinn.
-
hustbaer schrieb:
Ich finde Dokumentation toll. Ich mag sie aber nicht schreiben, weil das öde ist. Wenn ich sie nicht schreibe, ist der einzig positive Effekt dass ich etwas nicht machen musste was ich öde finde. Dieser Effekt ist aber flüchtig, es bleibt nichts übrig was man bewerten könnte. Ausser der fehlenden Doku.
Zeit.
Dadurch dass du die Doku nicht schreibst, hast du X mehr Features implementiert und Y mehr Bugs entfernt.
-
... was sich aber ins Gegenteil verkehren kann, wenn die undokumentierte Software nach 3, 4 Jahren von einem anderen Programmierer erweitert oder portiert werden muß. Nicht jeder ist ein "source = doc"-Künstler, was Bezeichnerwahl und Faktorisierung angeht.
-
Shade Of Mine schrieb:
hustbaer schrieb:
Ich finde Dokumentation toll. Ich mag sie aber nicht schreiben, weil das öde ist. Wenn ich sie nicht schreibe, ist der einzig positive Effekt dass ich etwas nicht machen musste was ich öde finde. Dieser Effekt ist aber flüchtig, es bleibt nichts übrig was man bewerten könnte. Ausser der fehlenden Doku.
Zeit.
Dadurch dass du die Doku nicht schreibst, hast du X mehr Features implementiert und Y mehr Bugs entfernt.Ja, ist mir schon klar.
Aber du verstehst was ich meine ...?
-
Lol, ihr wisst doch beide genau, was der jeweils andere meint.
-
So ganz ist mir der Sinn von Marc++us' Theorie nicht klar. Damit kann ich doch alles erklären, jedes beliebige Verhalten ist im Sinne irgendeines Kriteriums optimal. Aber eine Theorie, die alles erklärt, erklärt nichts. Und so kann daraus auch nicht der Schluss, dass man besser in Gruppen arbeiten soll, gezogen werden. Zumal der Schluss auch nicht unbedingt plausibel ist, denn "Viele Köche verderben den Brei."
-
Bashar schrieb:
Zumal der Schluss auch nicht unbedingt plausibel ist, denn "Viele Köche verderben den Brei."
stimmt, normal schafft einer an und der rest kocht
-
Dokumentation gehoert einfach zu qualitativ guter Software dazu!
-
ja, die schreibt dann der azubi... und wenn er das programm verstanden hat, darf er bischen spielen
-
Mei, ich kenn' da einen, der hat an einem WE in selbstverordneten Überstunden einen Fräsbahngenerator runtergerissen, der war ein paar Wochen später unabgemeldet in Indien und hat von da aus angerufen, daß er nicht mehr wieder kommt, eingehaltenes Versprechen.
Den Code hat hinterher keine Sau mehr verstanden, aber der tut bis heute - ist auch gut 12 Jahre her jetzt. Schlechtreden könnte ich den bis heute nicht.
Das, was verärgert, ist, daß er uns ohne vernünftige Doku hinterlassen hat.
-
Nein, die Doku muss der Entwickler schreiben, der die Software geschrieben (oder verbrochen) hat.
-
Bashar schrieb:
So ganz ist mir der Sinn von Marc++us' Theorie nicht klar. Damit kann ich doch alles erklären, jedes beliebige Verhalten ist im Sinne irgendeines Kriteriums optimal. Aber eine Theorie, die alles erklärt, erklärt nichts. Und so kann daraus auch nicht der Schluss, dass man besser in Gruppen arbeiten soll, gezogen werden. Zumal der Schluss auch nicht unbedingt plausibel ist, denn "Viele Köche verderben den Brei."
Jo, mein letztes Posting anbelangend:
Der Typ hatte einen Geistesblitz und hat den runtergerissen - solche Momente hatte ich auch gelegentlich.
Aber dann ist er durchgetickert und hat uns ohne Doku hinterlassen - sein Zeug hat aber funktioniert, nur ich schnall's nicht, neben ein paar anderen Proggern. Der hat sich vermutl. Koks und XTC in Red Bull aufgelöst und intravenös gegeben, keine Ahnung.
Das war kein Teamwork, der hat das ganz alleine gemacht und ein Team hätte in der Situation nichts besser machen können.
Aber wir lassen das jetzt trotzdem einfach liegen. Nicht wartbar.
-
kellerassel schrieb:
ja, die schreibt dann der azubi... und wenn er das programm verstanden hat, darf er bischen spielen
Der azubi versteht bzw. überblickt das Programm aber nicht.
Vor allen nicht wenn der Code scheisse ist.
-
es kommt doch immer darauf an, man muss die ja nicht gleich überfordern, so dass sie nicht mehr kommen... aber es wird doch funktionen geben, die aus ein paar zeilen bestehen, die nicht mit 50 klassen interagieren, welche relativ leicht verständlich sind und ein kommentar fehlt? dabei liest man code und macht was nützliches - ist doch okay für den anfang, oder?
also in meinem würden mir spontan schon ein paar stellen einfallen
