Warum sind die meisten Programmierer schlechte Bugfixer?
-
tntnet schrieb:
Es gibt kein Programmierwerkzeug, welches Bugs von vorneherein ausschliesst. Die Bugs werden aber unter Umständen subtiler und daher schwerer zu finden. Das bedeutet nicht unbedingt, dass der Code schlecht ist. Auch guter Code enthält leider Fehler.
Es gibt eines, du kannst code in formeln zerlegen und analysieren und so vom vorgegebenem input auf den vorgegebenen output loesen. kannst du die formel nicht loesen, ist der code fehlerhaft.
das verschiebt natuerlich den fehler, die fehler liegen dann auf der definitions seite. Aber rein bugmaessig ist so ein code fehlerfrei da er genau nach definition handelt.
-
DEvent schrieb:
* Programme die viel an ihrem Environment ändern (Rollback eines Tests nicht möglich)
Man testet doch in einer Testumgebung, da ist meist ein Rollback möglich. An was hast du da gedacht?Ab einer gewissen Datenmenge wird das schon schwerer... oder in einem Echtzeitumfeld (near realtime, ich spreche jetzt nicht von Embedded), wo Datenströme auf das System einprasseln. Die Testumgebung ist deutlich geringer komplex als das Applikationsumfeld.
Ein TDD ist ja eine Linearisierung der Daten nach der Zeit, und damit nur eine Annäherung an das Verhalten der Realität.
-
Schwer reproduzierbare Bugs finden und fixen ist schonmal grundsätzlich schwer, auch wenn man den Code selbst geschrieben hat. Das wurde ja schon mehrfach geschrieben.
Wenn der Code dann noch von jmd. anderem ist, dann ist es doppelt und dreifach schwer. Ich würde meinen dass das selbstverständlich ist und keiner näheren Erleuterung bedarf.
Da der OP aber anscheinend genau eine solche haben will...Bei Code den ich selbst geschrieben habe, bzw. wo ich am gesamten Entwicklungsprozess eng beteiligt war, habe ich einen guten Überblick über das ganze Programm. Ich kenne die Stellen wo "gehackt" wurde (z.B. schnell umsetzbar statt sauber programmiert wurde) und überhaupt weiss ich was wo wie passiert.
Daher kann ich viel schneller Vermutungen darüber anstellen, was den Bug auslösen könnte. Wenn es dann ums fixen geht, kann ich auch viel besser abschätzen was ich wo wie ändern kann, ohne dass dadurch neue Fehler entstehen.Bei Code der nicht von mir ist fehlt mir dieser Überblich. Sich so einen Überblich zu verschaffen ist nicht ganz einfach, und erfordert auch einiges an Zeit. Da der Code von jemandem geschrieben wurde der anders denkt als man selbst, folgt er auch anderen ungeschriebenen Gesetzen. Das macht es doppelt schwer. Etwas was man selbst nie machen würde, und daher auch gar nie auf die Idee kommen würde davon auszugehen jemand anderes könnte es machen, findet der ursprüngliche Programmierer vielleicht voll OK, und hat es an ein paar Stellen verwendet. Genau so kann es umgekehrt sein: man findet einen komplizierten Workaround für irgendwas was man selbst ganz OK gefunden hätte, und wundert sich dann erstmal lange warum er es nicht anders gemacht hat, weil es anders ja auch total OK gewesen wäre. Und sucht den (nicht vorhandenen) zwingenden Grund für den komplizierten Workaround.
-
rapso schrieb:
tntnet schrieb:
Es gibt kein Programmierwerkzeug, welches Bugs von vorneherein ausschliesst. Die Bugs werden aber unter Umständen subtiler und daher schwerer zu finden. Das bedeutet nicht unbedingt, dass der Code schlecht ist. Auch guter Code enthält leider Fehler.
Es gibt eines, du kannst code in formeln zerlegen und analysieren und so vom vorgegebenem input auf den vorgegebenen output loesen. kannst du die formel nicht loesen, ist der code fehlerhaft.
das verschiebt natuerlich den fehler, die fehler liegen dann auf der definitions seite. Aber rein bugmaessig ist so ein code fehlerfrei da er genau nach definition handelt.
Du hast es ja selbst beantwortet. Probleme bleiben. Das, was Du exakt definieren kannst, bzw. definiert hast, kann im Prinzip Fehlerfrei funktionieren. Aber tut es das auch, wenn ich beispielsweise in einer multithreaded Umgebung Gleichzeitigkeit habe? Oder bei fehlerhaften Eigabedaten? Bei beliebigen fehlerhaften Eingabedaten? Oder auch bei im Prinzip korrekten, aber doch ungewöhnlichen Daten? Reagiert das System bei beliebigen Benutzerinteraktionen korrekt? Was ist bei hoher Last? Was ist, wenn ein unerwarteter technische Fehler auftritt? Es gibt einfach viele Probleme, die sich nicht einfach in eine Formel zerlegen lässt.
Wie auch beim TDD kann dadurch eine bestimmte Fehlerart stark reduziert werden. Aber auch die Werkzeuge wollen richtig eingesetzt werden. Häufig kommt beim TDD auch das Problem, dass ich doch nicht alle möglichen Fälle bedacht habe. Da habe ich schon ein ach so tolles Werkzeug TDD und dennoch spielt da der Faktor Mensch eine Rolle. So was ärgerliches aber auch
.
-
volkard schrieb:
Alle Generalisierungen sind falsch.
Ist diese Aussage nicht etwas zu generell?
...
-
.bugbuster. schrieb:
Vorallem wenn es um Bugs geht die nicht ganz so einfach zu reproduzieren sind oder wenn sie den Code nicht selber geschrieben haben, sind einige Programmierer richtig schlecht, wenns darum geht einen Bug zu fixen. Warum?
Um Bugs zu finden, muß man den Code richtig kennen, und das ist bei fremden Programmcode nun einmal sehr zeitaufwendig. 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. Außenstehende haben leider meist keinerlei Überblick wie groß der Aufwand wirklich ist.
-
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.
