Warum sind die meisten Programmierer schlechte Bugfixer?
-
Manchmal kann aber ein Außenstehender trotzdem einen Bug viel schneller oder überhaupt finden, als jemand der das Projekt in und auswendig kennt. Denn derjenige der das Projekt sooo gut kennt, kann auch betriebsblind werden. Es kommt aber natürlich auf die Art des Bugs an. Aber ein Fremder muß nicht generell die größere Hürde überwinden.
-
~john schrieb:
Wenn man ein Projekt übernimmt, und dann daran arbeitet ist das machbar, aber mal eben so einen Bug in fremden Programmcode zu finden ist mit sehr viel Einarbeitungsaufwand verbunden, der oftmals in keinem Verhältnis zu Ergebnis steht.
Das hängt davon ab, was der Außenstehende tun soll:
Soll er den Bug unter Einbeziehung der Architektur ändern, benötigt er viel mehr Zeit. Konzentriert er sich aber ausschließlich auf den Bug - unter Vernachlässigung von Kollateralschäden - wird er wohl schneller und rascher Ergebnisse erzielen können.
-
Ein paar mal und dann wirds richtig schwierig.
-
Tyrdal schrieb:
Ein paar mal und dann wirds richtig schwierig.
Daraus folgt, dass es bei den meisten Projekten richtig schwierig ist, und damit wären wir wieder bei der Ausgangsfrage. Die man IMO damit beantworten kann: Weil die meisten Programmierer schlechte Programmierer sind.
-
Artchi schrieb:
Manchmal kann aber ein Außenstehender trotzdem einen Bug viel schneller oder überhaupt finden, als jemand der das Projekt in und auswendig kennt. Denn derjenige der das Projekt sooo gut kennt, kann auch betriebsblind werden. Es kommt aber natürlich auf die Art des Bugs an. Aber ein Fremder muß nicht generell die größere Hürde überwinden.
Stimmt schon, ja.
Muss nicht generell.
Meistens braucht er aber länger.
Und spätestens wenns dann um's Fixen geht kann es für nen Aussenstehenden schnell sehr aufwendig werden. MUSS natürlich auch nicht sein. Gibt ja genug Bugs die so simpel und "lokal" sind, dass das Fixen überhaupt kein Thema ist, sobald man den Bug mal gefunden hat.
-
Bashar schrieb:
Weil die meisten Programmierer schlechte Programmierer sind.
Ich wollte es nicht schreiben .. vielleicht nicht die meisten, aber viele.:)
-
knivil schrieb:
Bashar schrieb:
Weil die meisten Programmierer schlechte Programmierer sind.
Ich wollte es nicht schreiben .. vielleicht nicht die meisten, aber viele.:)
Naja.
Eine Aussage nach dem Muster "Die meisten X sind schlechte X" ist immer wahr, man muss nur den Grenzwert für "schlecht" passend wählen
Dass die meisten Programmierer denken dass die meisten Programmierer schlecht sind, liegt IMO daran, dass der typische Programmierer kaum ein Programm das nicht seinem Stil entspricht als "gut" bewertet. Bei Bekannten/Arbeitskollegen/Leuten mit bekanntem Namen etc. ist man vielleicht gewillt mal näher hinzusehen. Und drüber nachzudenken was bestimmte Konstrukte die man nicht auf anhieb versteht eigentlich sollen, wenn man diese in einem fremden Programm vorfindet. Bei Programmen von "irgendwelchen" Leuten eher nicht.
Daher sind auch Programmierer die wirklich schlecht sind geneigt Programme von wesentlich besseren Programmierern als schlecht einzustufen, so lange sie diese nicht kennen oder aus irgend einem Grund denken dass sie einfach gut sein müssen.Viele Programmierer die gerade mal über das Noob-Stadium hinaus sind, haben den Eindruck, dass die meisten anderen Programmierer die totalen Pfeiffen/Wirrköpfe/... sind. Frei nach dem Motto "versteh ich nicht -> muss schlecht sein (weil ich bin ja jetzt kein Noob mehr und hab daher den vollen Durchblick)".
p.S.: die meisten Menschen sind schlechte Menschen
-
Bashar schrieb:
Tyrdal schrieb:
Ein paar mal und dann wirds richtig schwierig.
Daraus folgt, dass es bei den meisten Projekten richtig schwierig ist, und damit wären wir wieder bei der Ausgangsfrage. Die man IMO damit beantworten kann: Weil die meisten Programmierer schlechte Programmierer sind.
Das gefällt mir so nicht. Dazu müßte man "schlecht" definieren. Oftmals sind Programmierer auch viel zu umfassend eingesetzt und müssen dann auch auf dem Gebiet arbeiten, wo sie sich nicht so gut auskennen. Das kommt in kleineren Teams ja sehr oft vor, daß jeder alles macht - da ist dann ein Datenbankmann, der sich wirklich top damit auskennt, den man aber aus unerfindlichen Gründen GUIs programmieren lässt. Die GUI sieht dann a) aus wie eine Datenbankmaske und ist für kein Schwein bedienbar und b) total verbuggt, weil er ganz anders denkt als ein User.
Letztlich ist die Softwareentwicklung organistorisch in den meisten Fällen nach wie vor völlig unterentwickelt in Bezug auf Aufgabenteilung, Rollen und Spezialisierungen.
Beim Auto gibt's ja auch einen Spezialisten für Powertrain, niemand lässt den an HMI ran. Softwareleute in kleinen Teams erstellen aber oftmals Applikationen, die in der Komplexität fast ebenso groß sind, aber irgendwie sollen alle austauschbar sein und jeder muß alles können.
Wo das schon relativ gut entwickelt zu sein scheint ist im Spielebereich, wo sich die Teams innerhalb der Untergruppen auf bestimmte Bereiche konzentrieren.
Dazu kommt oftmals auch noch ein großer Zeitdruck - das Programm ist sehr schön durchentwickelt, und dann muß zwischen Donnerstag 18:30 und Montag 08:00 noch ein komplexes Feature eingestanzt werden (ja, ich bin an solchen Aufträgen auch mitschuldig, viele Grüße nach DD), da wird nur noch gewürgt. Das ist eben der Alltag in der Industrie, der trotz Scrum & Co mitregiert.
Vor diesem Umfeld ist die Aussage, die Masse der Programmierer sei schlecht, nicht haltbar.
Ohnehin unwahrscheinlich: vermutlich ist die Masse der Programmierer durchschnittlich, und nur 15,9% sind schlecht.
-
Marc++us schrieb:
Bashar schrieb:
Tyrdal schrieb:
Ein paar mal und dann wirds richtig schwierig.
Daraus folgt, dass es bei den meisten Projekten richtig schwierig ist, und damit wären wir wieder bei der Ausgangsfrage. Die man IMO damit beantworten kann: Weil die meisten Programmierer schlechte Programmierer sind.
Das gefällt mir so nicht. Dazu müßte man "schlecht" definieren.
Komisch, aber dazu, dass sie schlechte Bugfixer sind, hattest du sofort eine Meinung.
Vor diesem Umfeld ist die Aussage, die Masse der Programmierer sei schlecht, nicht haltbar.
Nur, wenn du annimmst, dass diese Aussage sich aus der Tatsache, dass viele Programme schlecht sind, herleitet.
Wie viele Programmierer gab es vor 40, 50 Jahren? Damals musste man schon extremer Übergeek sein oder einen Doktortitel haben, um überhaupt Zugang zu einem Computer zu haben. Heute schickt das Arbeitsamt Leute in VB-Kurse. Die Spitze gibt es immer noch, aber die Pyramide ist nach unten gewachsen. Wir haben zwar heute viel bessere Tools als damals, bessere Prozesse und Methodiken, aber die Anforderungen sind auch höher. Im Grunde sind die meisten Programmierer schlecht (ich würde mich selbst übrigens auch nicht als besonders guten Programmierer bezeichnen), wir haben das nur inzwischen akzeptiert und sind mit dem State of the art zufriedenzustellen. Blöd wenn man bedenkt, dass Turing noch dachte, dass Computer zur Jahrtausendwende intelligent sein würden.
Ohnehin unwahrscheinlich: vermutlich ist die Masse der Programmierer durchschnittlich, und nur 15,9% sind schlecht.
Nö, die Masse ist durchschnittlich (wie soll es auch anders sein?) und 80% sind schlecht.
-
Bashar schrieb:
Wie viele Programmierer gab es vor 40, 50 Jahren?
[...]
Wir haben zwar heute viel bessere Tools als damals, bessere Prozesse und Methodiken, aber die Anforderungen sind auch höher.bist du dir da sicher? Meiner Kenntnis nach gilt das Smalltalk-System noch heute als Maßstab, an dem sich alle objektorientierten (und die, die es gerne sein wollen) IDEs messen lassen müssen. Und das stammt aus den Jahren 1972-1980, also rund 40 Jahre alt.
Daß die Anforderungen heute höher sind, stimmt, was den Funktionsumfang angeht.
Andererseits mußte man vor 40, 50 Jahren typischerweise mit ungleich schwächerer Hardware auskommen, was den Programmierern enormes Effizienz-Denken und allerlei Tricks zur Reduzierung von Speicher- und Zeitbedarf abverlangte - wenn zur Implementation beispielsweise nur 8 K oder 38 K RAM zur Verfügung standen. Ziemlich anspruchsvoll, wenn man damit und mit 5 oder 10 MHz Takt auskommen mußte, um ein komplettes Mehrbenutzer-Betriebssystem zu implementieren.
-
zum Beispiel schrieb:
was den Programmierern enormes Effizienz-Denken und allerlei Tricks zur Reduzierung von Speicher- und Zeitbedarf abverlangte
Und dann führst Du ausgerechnen Smalltalk als Paradebeispiel für alte Tugenden an.
-
Marktlücke:
Verding dich doch einfach als bugfinder.Viel Spaß bei zig-Tausend Zeilen unkommentiertem code.
Da sind schon Viele verzweifelt.
-
Bashar schrieb:
Nö, die Masse ist durchschnittlich (wie soll es auch anders sein?) und 80% sind schlecht.
Das kann nicht sein.
-
marktluecker schrieb:
Marktlücke:
Verding dich doch einfach als bugfinder.Solche Leute gibt es.
Die lassen sich nach Erfolg bezahlen, da sind Summen im fünf- bis sechsstelligen Bereich angesagt.
-
Bashar schrieb:
Die Spitze gibt es immer noch, aber die Pyramide ist nach unten gewachsen.
Vielleicht haben sich aber auch letztlich die Anforderungen nach unten verschoben. Für viele Applikationen reicht möglicherweise der vom Arbeitsamt umgeschulte VB-Programmierer völlig aus.
Früher hat man bei vielen Sachen gar nicht an ein Programm gedacht, da schrieb man das auf Zettel auf, heute wird das in Software gemacht. Aber nicht jede Applikation ist eine Steuerung für Atomkraftwerke.
-
Marc++us schrieb:
marktluecker schrieb:
Marktlücke:
Verding dich doch einfach als bugfinder.Solche Leute gibt es.
Die lassen sich nach Erfolg bezahlen, da sind Summen im fünf- bis sechsstelligen Bereich angesagt.
Zählen die schon zu den Sicherheitsexperten? Oder beziehst du dich mehr auf den "Putztrupp" ala "Hier wird das Label falsch gesetzt"?
-
Ich habe die bisherigen Beiträge im Schnelldurchlauf gelesen - und wundere mich. Nur triviale Programme haben keine Bugs, aber welches Programm ist schon trivial? Seit den Anfängen der Programmierung gehört zur Programmierung auch ein sauberer Programmentwurf und die Integration einer geordneten Fehlersuche. Die Hersteller der Compiler haben da als Hilfe Debug und Event-Handling angeboten - nur das tut es nicht oder nicht auf Dauer!
Die Frage ist wichtig. Es geht um Programmierstil. Wenn der schlecht ist, kann man nichts machen!
-
[...] that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
(C.A.R. Hoare)
-
Debugging setzt Wissen über die Funktionsweise dessen vorraus, was man gerade macht, Programmieren nicht. Mit heutigen Entwicklungsumgebungen und Werkzeugen kann man viele Technologien benutzen ohne diese verstehen zu müssen. Solange alles läuft, prima... Wenns dann aber nicht geht sind solche Leute aufgeschmissen.
-
gui-code bzw. 3d-engine code (hab ich zwar noch nicht gemacht, kann ich mir aber gut vorstellen) um nur einige beispiele zu nennen, also alle code stellen mit vielen objecten, recursion, schleifen und events sind ein horror zum debuggen. da kann man machen was man will und die debugger helfen dir auch nicht (nur wenig). in so einem fall lässt dir das ganze am besten auf die console ausgeben, oder setzt breakpoints auf variablen werte, nur auf welche;) ...
lg lolo
