wieso müssen programmierer immer anderer leute software schlecht reden?
-
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!
-
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.
