wieso müssen programmierer immer anderer leute software schlecht reden?
-
Marc++us schrieb:
Dazu kommt dann gerade noch, daß Software (leider) doch hoch individuelle Lösungen generiert, d.h. jeder Programmierer erstellt Software, die nach seinem Meßprinzip "optimal" ist.
Ach das wäre schön wenn das wahr wäre.
Ja, manche tun das. Anderen ist es sowas von egal wie der Code aussieht. Leider. Deren Programme darf ich nämlich öfter mal warten.
-
hustbaer schrieb:
Marc++us schrieb:
Dazu kommt dann gerade noch, daß Software (leider) doch hoch individuelle Lösungen generiert, d.h. jeder Programmierer erstellt Software, die nach seinem Meßprinzip "optimal" ist.
Ach das wäre schön wenn das wahr wäre.
Ja, manche tun das. Anderen ist es sowas von egal wie der Code aussieht. Leider. Deren Programme darf ich nämlich öfter mal warten.Natürlich stimmt das. Ich sagte doch explizit "nach seinem Meßprinzip optimal".
-
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. Leute die sich sehr wohl darüber im Klaren sind dass sie es besser machen könnten, die die nötigen Fähigkeiten dazu auch mitbringen würden, es aber trotzdem nicht tun. Und auch nicht weil der böse Manager wiedermal Zeitdruck macht und sie sich davon beeindrucken lassen, sondern schlicht und ergreifend weil es ihnen nicht wichtig ist ihre Arbeit gut zu machen.
Bei solchen Leuten dann noch zu sagen er macht das was nach seinem Messprinzip optimal ist, halte ich nicht für sinnvoll. Weil sein "Messprinzip" kann dann nur sein dass er Dinge ignoriert die er eigentlich wüsste, weil es ihn nicht schert.
Die Formulierung "macht das was nach seinem Messprinzip optimal ist" ist dann bloss noch ein Euphemismus für (u.A.) "manchen ist halt scheissegal was sie abliefern".
-
kellerassel schrieb:
tggc schrieb:
Sieht irgendwie sinnlos aus das Spiel.
der hatte doch mal in seiner sig. einen link zu einem panzertowerdefense, auf das er ja mächtig stolz gewesen sein muss
Da hast du jemanden zitiert, dessen Verhalten du am allerwenigsten als Grundlage für eine Verallgemeinerung auf alle Programmierer benutzen solltest
Warum Programmierer häufig scheinbar übertrieben über anderer Leute Software meckern: Weil sie in den kleinen und größeren Fehlern der Software ihre eigenen kleinen und größeren Fehler wiedererkennen, aber auch deren Ursache. Man ärgert sich über Fehler, die man selbst verursacht, aber auch über Fehler/Unreinheiten, die andere verursacht haben, weil die wiederum eigene Fehler verursachen (siehe auch Broken Window Theory
Kurz: ein Programmierer, der eine Unzulänglichkeit in deinem Programm sieht, beschwert sich entweder darüber, weil er sehr penibel ist, oder weil er weiß, dass er selbst durch solche Unzulänglichkeiten schon einige Fehler verursacht hat und eigentlich penibel sein sollte. Und es ist so viel einfacher, über anderer Leute Software zu meckern, als seine eigene Software zu verbessern...
-
Warum ist Software von anderen immer schlechter als die eigene?
Weil der andere vermutlich andere Bedürfnisse hatte... Wie oft wiederholt sich die Diskussion, wieso vi ein Text-Editor sein soll, wenn man nach dem Programmstart nichtmals Texte editieren kann - man selbst hätte das ganz anders gemacht, mecker, mecker, mecker...Wieviel Software habe ich geschrieben, weil mir die von anderen Leuten nicht gefiel?
Das mache ich heute weniger, denn obwohl ich vermutlich immernoch sehr kritisch bin, stelle ich fest, dass ich zwar das Know-How habe, es besser zu machen, mir meistens die Zeit dazu fehlt.Meckern ist auch eine Form von Beachtung. Man meckert, also hat man die Software wahrgenommen und sie sogar so gut angesehen, dass man sagen kann, was man alles scheiße findet. So brutal es ist, es ist so, denn was gut ist, ist ja wohl selbstverständlich...
Der Entwickler von DokuWiki hat auf seiner Homepage einen Link zu seiner Amazon-Wunschliste. DokuWiki ist eins der sehr wenigen Projekte, die ich derzeit durch etwas (imho - bzw. für mich) Besseres abzulösen versuche. Ich schickte ihm eine DVD, die er sich wünschte als ein Dankeschön, dass seine Software unser Projekt trägt. Den obwohl die Software nicht perfekt ist, ist sie hilfreich, kostenlos und wird von mir benutzt. Da muss man nicht nur meckern, sondern kann durchaus mal 'Danke' sagen.
Programmierer müssen also nicht immer Software anderer Leute schlecht machen.
-
Martiniclan schrieb:
Allesquatsch schrieb:
Und selbst dort ist das Gros leider minderbegabt.
Das sehe ich im Wesentlichen auch so, obwohl Gros Minderbegabt... alles relativ.
Hallo Martiniclan,
war jetzt auch nicht so abwertend gemeint, wie es vielleicht geklungen hat.
Aber gerade bei gestalterischen oder intellektuellen Tätigkeiten gibt es eine große Spreizung der Fähigkeiten. Auf sehr viele, die ausreichende Fähigkeiten mitbringen, gibt es wenige, die ihr Handwerkszeug in künstlerischer Perfektion beherrschen.
Für mich sind K&R solche Genies, ohne die es so geniale Sprachen wie C oder C++ nicht gäbe.
Aber es muss auch Leute geben, die die Lagerverwaltung bei OPEL programmieren.Das ist in der IT schon immer so gewesen, denn bereits Frederick P. Brooks, der in den Sechzigern die Entwicklung von OS/360 leitete, hat erkannt:
Für große IT-Projekte kann man nicht darauf hoffen, dass man genügend Genies zusammenbekommt. Man muss eben so entwickelt, dass es auch mit den in großer Anzahl verfügbaren mittelmäßigen Entwicklern klappt.In der IT ist die Spreizung leider besonders groß,
weil in den letzten dreißig Jahren enormer Bedarf war, so dass in der Hype-Phase jeder, der schon mal die Computerbild gekauft hat, schon mal ein Jobangebot bekam
weil man spätestens seit Visual Basic auch mit rudimentärem Wissen etwas zusammenbauen kann, was für den Laien aussieht wie ein tolles PC-Programm.
weil die Branche so jung ist, dass Werkzeuge und Methoden noch nicht so ausgereift sind und entsprechend die Strukturen fehlen, wie Mitarbeiter ausgebildet werden müssen.
Interessant ist dabei auch die parallele Diskussion in "Was kommt nach der Objektorientierung?", in der die (meines Erachtens richtige) Idee aufgekommen ist, dass JAVA dazu da ist, damit weniger begabte und günstigere Entwickler damit arbeiten, für die C++ einfach zu gefährlich ist.
Ciao, Allesquatsch
-
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!
