Wieviel LOC pro Tag?

Gregor

Antwort42 schrieb:

Ich habe gerade ein Video von einem Top-C++-Entwickler gesehen, da hat das Suchen und Finden eines Fehler in einem 10-Zeiler mehrere Wochen gedauert. Wie kannst du davon ausgehen dass der Mitarbeitet das in weniger als einen Tag schaffen muss?

Was fuer ein Fehler? Hast Du einen Link auf das Video?

https://www.youtube.com/watch?v=JSjoCisIHcM Der Coder heißt Chandler Carruth und er arbeitet bei Google und auch an Clang/LLVM. Ich glaube der Fehler war, dass ein Return Stack Objekt ungültig war oder so.

Mechanics

Wir untersuchen auch mehrmals pro Jahr Fehler, wo wir mehrere Tage brauchen, um den zu finden. Wochenlang haben wir aber noch nie nach einem Fehler gesucht.

hustbaer

Bestimmte Fehler haben wir - in mehreren Iterationen, in Summe - schon mehr als eine Woche lang gesucht.

Mechanics

Ja, in mehreren Iterationen schon Manche Fehler tauchen immer wieder auf, können nicht grundsätzlich gelöst werden (zumindest nicht ohne sehr viel umzubauen und zu riskieren, erstmal viele neue Bugs einzubauen), also wird nur das aktuelle Problem gelöst, und irgendwann taucht dasselbe Problem in einer etwas abgeänderten Form wieder auf.

numLOC schrieb:

Und für Ausbesserungen wird uns keine Zeit gegeben, da Featurausbau immer Vorrang hat.

Das kann nur zu sau schlechten Programmen führen, die regelmäßig abstürzen und vor Bugs so strotzen, weil immer etwas angehängt, aber nie überarbeitet und aufgeräumt wird.

Das könnte man am besten mit einem uralten Gebäude vergleichen, bei der immer irgendetwas drangeflanscht wurde, anstatt das Ding einfach von Grund auf neu zu planen, abzureisen und neu zu bauen.

Ein Admin ist kein Programmierer, das dürfte ein wesentliches Problem sein.
Ich würde an deiner Stelle den Schritt nach vorne wagen und deinem Chef erklären wie man Software "richtig" entwickelt, dass seine Bewertungsfunktion nach den Lines of Code für die Gülle ist und falls er dich dann deswegen rausschmeissen möchte, hast du nichts verloren, denn wenn sich da nichts ändert, ist die Suche nach einem anderen Job sowieso nur die einzig richtige Wahl.

Dein Chef und sein Bewertungsmodell muss sich ändern, nicht du.
DAS solltest du vor ihm vertreten.

MFK schrieb:

Weg da, ganz schnell weg. Und schreib mir bitte mal, wie der Laden heißt.

Fast vergessen, ich würde auch gerne wissen wie der Laden heißt.
Damit ich nicht in Gefahr laufe dort Software zu kaufen.

berniebutt schrieb:

Nebenbei aber ein sehr interessantes Thema:

Wie misst und beurteilt man die Produktivität und die Qualität eines
Mitarbeiters in der Softwareentwicklung? LOC alleine ist sicher kein Kriterium!

Ich würde zur Bemessung der Produktivität und Qualität die Anzahl von Bugs für den Code eines zu implementierenden durchschnittlich aufwendigen Features mit der Dauer, die er zum Implementieren dieses Features benötigt hat in Relation setzen und danach bewerten.

Sprich, der Programmierer soll ein Feature implementieren.
Wenn er fertig ist, wird die Zeit, die er dafür benötigt hat gestoppt, danach geht das zur Qualitätssicherung, die sucht dann die Bugs und schon kann man den Programmierer bewerten.

Gefundene Bugs werden dann natürlich zurückgereicht, um die Fehler auszubügeln.
Das dürfte sich gut in einem Stufenweisen Entwicklungsmodell umsetzen lassen, wenn die zu erzielenden Stufen klein genug sind.

Obiges gilt für ein durchschnittliches Programm in dem Performance keine große Rolle spielt.

Wenn die Effizienz bzw. daraus resultierender Performancegewinn des Codes wichtig ist, muss das Bewertungssystem natürlich erweitert werden, das ist klar.

Chefs die selber programmieren können, die haben es übrigens bei so etwas viel einfacher, weil sie auch die Schönheit und Eleganz von Code sehen und erkennen können.
Das kann nämlich ebenfalls etwas wert sein, als ein Müllcode, der zwar keine Bugs enthält und das Feature in X Tagen erledigt hat, aber ansonsten z.b. daraus besteht, alles selbst zu implementieren, anstatt fertige Funktionen der API zu benutzen.
Das alles selber implementieren kann nämlich auch die Wartung der anderen erhöhen, denn das Zeug kennen sie ja nicht und selber Implementieren bedeutet, dass da zusätzliche LOCs dazu kommen die eigentlich vermeidbar wären.

Aber gut, anhand der Anzahl der Bugs müsste so ein zusätzlicher Code, der alles selbst implementiert rein statistisch auffallen. Denn mehr LOCs bedeuten auch mehr Bugs.

Korrektur:

Auskenner schrieb:

Das alles selber implementieren kann nämlich auch ~~die Wartung~~den Wartungsaufwand der anderen erhöhen, denn das Zeug kennen sie ja nicht und selber Implementieren bedeutet, dass da zusätzliche LOCs dazu kommen die eigentlich vermeidbar wären.

hustbaer

Boah, registrier dich mal oder überleg dir vorher was du alles schreiben willst.

Xin

hustbaer schrieb:

Bestimmte Fehler haben wir - in mehreren Iterationen, in Summe - schon mehr als eine Woche lang gesucht.

Vor etwa 10 Jahren habe mal 8 Wochen Vollzeit nach einem Bug gesucht.

Ich hatte Schrödingers Katze im Quelltext.

Ich habe gelernt, dass ich 8 Wochen an einem Problem dranbleiben kann und mich zu einer Lösung durchkämpfen kann, selbst wenn es einen tierisch ankotzt.
Wobei ich sagen muss, dass ich die letzten beiden Wochen darüber nachgedacht habe, ob ich das Projekt sterben lasse und meine Unfähigkeit anerkenne.
Letzteres fand ich nicht akzeptabel und so lernte ich, dass nicht jede Optimierung Zeit spart und dass ich bei Debugausgaben mehr darauf achten muss, Seiteneffekte zu vermeiden, die den Bug blöderweise versehentlich korrigieren, so dass der Fehler nie auftritt, wenn man danach sucht.

volkard

Bin wohl ein Anfänger. Schaffe es nie, länger als einen Tag an der falschen Stelle zu suchen.

hustbaer

@Xin
You win

8 Wochen vollzeit kommt glaub ich nichtmal bei unserem hartnäckigsten Bug zusammen.
Dafür kann ich > 5 Jahre Kalenderjahre anbieten (vom Zeitpunkt wo der Bug das erste mal reportet wurde bis wir ihn endlich gefunden haben - GESUCHT haben wir dazwischen immer wieder mal)
(Genau kann ichs nicht sagen, denn zu dem Zeitpunkt wo der Bug das erste mal reportet wurde haben wir noch kein Bugtracking System verwendet.)

@Mechanics
Nönö, mit "in mehreren Iterationen, in Summe" meine ich nicht dass wir Regressions hatten. Sondern dass angefangen wurde den zu suchen. Nach 1-2 Tagen war dann wieder was anderes ganz dringend, also wurde wieder aufgehört zu suchen. Ein paar Monate später wurde wieder jmd. auf den Bug angesetzt. Der meinte dann vielleicht eine Idee zu haben warum der Bug eventuell auftreten könnte, und dann wurde halt auf Verdacht was eingebaut was vielleicht helfen könnte. Dann aber doch nicht geholfen hat. Dabei sollte ich vielleicht dazusagen dass wir nicht wussten wie man den Bug reproduzieren kann. Wurde einfach von Kunden gemeldet. Mehrfach, und von verschiedenen Kunden, so dass wir uns sicher sein konnten (mussten) dass das nicht erfunden oder einfach Dummheit/Schusseligkeit vom Kunden war.
Aber eben keine Anleitung das Phänomen nachzustellen.
Und so wurde halt gesucht und auf Verdacht rumprobiert wenn gerade Zeit dafür war.
Im Endeffekt war es dann was so einfaches (und auch so einfach zu reproduzieren), dass ich es immer noch nicht ganz verstehe dass a) es vorher keinem aufgefallen ist und b) es beim Testen nie bemerkt wurde.
Und zu fixen war es dann auch super-einfach - viel einfacher geht kaum. Und wenn den Bug nicht mit Absicht wieder jemand reinmacht, dann bleibt der auch gefixt

hustbaer

volkard schrieb:

Bin wohl ein Anfänger. Schaffe es nie, länger als einen Tag an der falschen Stelle zu suchen.

Auch bei nicht reproduzierbaren Fehler?

SeppJ

volkard schrieb:

Bin wohl ein Anfänger. Schaffe es nie, länger als einen Tag an der falschen Stelle zu suchen.

Auch bei Code, den du nicht selber geschrieben hast?

volkard

SeppJ schrieb:

volkard schrieb:

Bin wohl ein Anfänger. Schaffe es nie, länger als einen Tag an der falschen Stelle zu suchen.

Auch bei Code, den du nicht selber geschrieben hast?

Wenn ich den Quellcode einsehen und testen kann, gehts gewöhnlich auch recht fix. Doof wird's, wenn der Fehler völlig außerhalb meiner Reichweite ist, schwere Architekturfehler und undokumentierte Einschränkungen von Fremdlibs zum Bleistift, aber die Fehler werden ja als Feature deklariert und nicht gefixt.

volkard

hustbaer schrieb:

volkard schrieb:

Bin wohl ein Anfänger. Schaffe es nie, länger als einen Tag an der falschen Stelle zu suchen.

Auch bei nicht reproduzierbaren Fehler?

Wenn der Fehler garantiert nicht reproduziert werden kann, wirds schwierig.

Erinnere mich an Code von fremden Proggern,

//häßlicher code
…
delete foo;
…
//10 Zeilen, die nach C aussehen
…
return f(foo->bar)+fabs(y);

und die Schutzverletzung kommt ca alle 14 Tage Laufzeit, nämlich nur, wenn das delete zufällig auch noch auslöst, daß das ganze Speicherfragment dem BS zurückgegeben wird. Und geschätzt noch 1000 weitere so Fehler um Projekt. *Aua*

Mit Multithreading und sinnlosen Locks kann man auch gute Rätsel bauen.

Hatte wohl einfach Glück, auf keins zu treffen. Oder hab ich nur die bösen Erinnerungen verdrängt?

Danke, es tut gut zu hören, dass auch ihr Profis mal länger braucht und nicht jeden Aufgabe in einem Tag erledigt ist, das beruhigt mich ungemein. Meine Firma will ich trotzdem nicht nennen. Nur soviel, selbst die Ct hat schon über ihre Dienstleistung berichtet, also ist sie mit Sicherheit nicht ganz unbekannt. Ich habe übrigens gestern mit meiner Psychologin darüber gesprochen den Job dort an den Nagel zu hängen und dann was vernünftiges zu finden, oder halt ganz mit dem beruflichen Programmieren aufzuhören. Ich solle immer auf mein Baugefühl achten und nur das tun, wo ich ein gutes Gefühl dabei habe. Jeder Gang zur Arbeit war bis jetzt die Hölle für mich, ich habe mich so nie sooo schlecht gefühlt. So etwas kann einen echt fertig machen.