Wieviel LOC pro Tag?

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.

Gregor

volkard schrieb:

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*

Kann man bei C++ nicht irgendwie automatisch zusätzliche Checks beim Kompilieren einbauen? In Fortran (ifort Compiler) kompiliere ich einfach mit

-CB -check uninit -check pointers -traceback

und schon wird beim Auführen des Programms genau an solchen Stellen abgebrochen und mir wird in der Fehlermeldung ganz genau gesagt, was los ist. Das Finden derartiger Bugs ist dann letztendlich eine Frage von Minuten.

Xin

volkard schrieb:

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

Manchmal bekomme ich Fehlerbeschreibungen ("Tut's irgendwie nicht"), den Quellcode präsentiert und ich merke, wie ich automatisch die Anfängerfehler durchgehe... Bedingung in Schleifen, Semikolon... und im so im Prinzip im Moment, wo ich den Code sehe schon sagen kann, was verkehrt läuft.

Wenn der Bug aber ist, dass ein 3D-Körper kein Volumen mehr hat, obwohl der Körper perfekt aussieht. Der Körper soll nicht geschlossen sein.
Solche Bugs bekomme ich dann, weil mich da durch beiße.
Die OpenGL-Visualisierung ist perfekt.
Also muss man die Konstruktion des 3D Körpers verfolgen und stellt dann fest, dass an einem Punkt eine Ordinate bei der 7. Stelle hinter'm Komma in einem speziellen Fall verrutscht, was den Körper an einer Stelle nicht sauber schließt, aber die Information geht bei der Visualisierung verloren, da OpenGL mit float arbeitet und wir mit double. Das ganze ergab sich, dass die Facette, die aus mehr als drei Punkten besteht, die nicht perfekt in einer Ebene lagen und die Ebene dann eben einen Punkt nicht mehr genau genug trifft. Der Körper besitzt damit einen minimalen Schlitz und ist daher fehlerhaft.
Die Daten sind von einer anderen Software importiert. Wir sind extrem genau, das Datenformat ist sehr lasch. Wir müssen quasi alles reparieren bzw. interpretieren.

In einer anderen Firma hatte ich einen Fall, wo eine Exception falsch behandelt wurde, was anderswo eine Exception auslöste, die falsch behandelt wurde, was anderswo eine Exception auslöste, die bei mir einschlug. Die einzige Info, die ich hatte, war dass mein Code getestet ist und die gefangene Exception eigentlich nix mit mir zu tun hat. Gelegentlich kommt eine Exception vorbei, obwohl in dem Moment keiner was getan hat.

Wenn Du das alles an einem Tag schaffst, super. Ich empfehle Dich meinem Chef und gebe das Datenformat gerne ab.

Ansonsten fängt nicht jeder als Profi an.

hustbaer schrieb:

@Xin
You win

8 Wochen vollzeit kommt glaub ich nichtmal bei unserem hartnäckigsten Bug zusammen.

Juhuu...

Privatprojekt im Studium, bezahlt hat mir das keiner. Damit war ich für den Bug auch selbst verantwortlich. Aber Vollzeit meint wirklich 7*8 Tage * min. 8 Stunden/Tag. Aber ich habe draus gelernt. ^^

numLOC schrieb:

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. ...
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.

Darf ich mal fragen mit welchen Erwartungen Du Dich hinter einen Computer setzt?

numLOC schrieb:

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.

Ein Haus baut man auch nicht von heute auf morgen. Warum sollte das bei Software anders sein?

Ich habe erwartet, dass ich da morgens ins Büro kommen und Code wie ein irrer bis zum Abend runterkloppe. Anstelle dessen war ich viel mehr mit Analyse, Debuggen und Recherche beschäftigt. Ich habe mehr auf einem Blatt Papier mir die Zusammenhänge aufgezeichnet, als dass ich Code eingetippt habe. Beim Wochenmeeting musste ich Woche für Woche erzählen warum ich noch nicht weiter bin. Für die eigentliche Aufgabe wurde ein Tag angesetzt und nach 2 Monaten war ich erst fertig, weil ich überhaupt keine Ahnung von den ganzen Zusammenhängen und den Frameworks hatte. Die nächste Aufgabe hatte wieder mit einem anderen Framework und der Anpassung einer fremden Software zu tun, die ich auch nicht kannte, und da bin ich auch nicht mit fertig geworden.

Ich bin wohl zu dumm für den Job, da ich auch nicht studiert habe.

Gregor

Xin schrieb:

Wenn der Bug aber ist, dass ein 3D-Körper kein Volumen mehr hat, obwohl der Körper perfekt aussieht. Der Körper soll nicht geschlossen sein.
Solche Bugs bekomme ich dann, weil mich da durch beiße.
Die OpenGL-Visualisierung ist perfekt.
Also muss man die Konstruktion des 3D Körpers verfolgen und stellt dann fest, dass an einem Punkt eine Ordinate bei der 7. Stelle hinter'm Komma in einem speziellen Fall verrutscht, was den Körper an einer Stelle nicht sauber schließt, aber die Information geht bei der Visualisierung verloren, da OpenGL mit float arbeitet und wir mit double. Das ganze ergab sich, dass die Facette, die aus mehr als drei Punkten besteht, die nicht perfekt in einer Ebene lagen und die Ebene dann eben einen Punkt nicht mehr genau genug trifft. Der Körper besitzt damit einen minimalen Schlitz und ist daher fehlerhaft.
Die Daten sind von einer anderen Software importiert. Wir sind extrem genau, das Datenformat ist sehr lasch. Wir müssen quasi alles reparieren bzw. interpretieren.

Bugs der Art "Die Ergebnisse, die mir das Programm zurueckliefert sind irgendwie falsch", sind natuerlich enorm schwer zu finden, wenn sie ueberhaupt auffallen. Ich glaube gerne, dass Du da lange nach gesucht hast. Ich hatte mit solchen Problemen auch schon jede Menge Spass. Eigentlich ist das Debuggen solcher Bugs sogar enorm interessant. Ich habe bei mir gemerkt, dass ich dann teilweise richtig kreativ bei den Debugging-Techniken werde. Unter Umstaenden muss man den Fehler durch irgendwelche Zwischenergebnisse zurueckverfolgen, die man nur schwer interpretieren kann. Oder man hat es mit derart grossen Datenmengen zu tun, dass es schwer ist, die Natur des Fehlers darin ueberhaupt zu erkennen.

Xin

numLoc schrieb:

Ich habe erwartet, dass ich da morgens ins Büro kommen und Code wie ein irrer bis zum Abend runterkloppe. Anstelle dessen war ich viel mehr mit Analyse, Debuggen und Recherche beschäftigt.

Das entspricht etwa meiner Erfahrung. Bei mir auf'm Tisch landet gerne das Zeug, dass andere mit der Kneifzange nicht freiwillig anpacken.
Entwickeln ist aber oft zu großen Teilen recherchieren, analysieren, reverse engineering, testen und debuggen und anschließend Tests automatisieren, um die Qualität abzusichern.
Das eigentliche Entwickeln ist eher ein überschaubarer Bruchteil der Arbeit. Am Ende der Woche hat man eventuell nur zwei Variablen vertauscht.

Code runterkloppen macht sicherlich am meisten Spaß, aber das ist wie Tetris spielen. Je länger man spielt, desto wichtiger ist, dass man nicht einfach nur runterkloppt.

numLoc schrieb:

Ich habe mehr auf einem Blatt Papier mir die Zusammenhänge aufgezeichnet, als dass ich Code eingetippt habe. Beim Wochenmeeting musste ich Woche für Woche erzählen warum ich noch nicht weiter bin. Für die eigentliche Aufgabe wurde ein Tag angesetzt und nach 2 Monaten war ich erst fertig, weil ich überhaupt keine Ahnung von den ganzen Zusammenhängen und den Frameworks hatte. Die nächste Aufgabe hatte wieder mit einem anderen Framework und der Anpassung einer fremden Software zu tun, die ich auch nicht kannte, und da bin ich auch nicht mit fertig geworden.

Da darf man vielleicht auch mal Deinen Projektleiter fragen, ob er Dich entsprechend Deiner Fähigkeiten einsetzt.
Ich stünde auch wie ein Ochs vor einem Berg, wenn man mir ein unbekanntes Stück Code, ein unbekanntes Framework und eine Aufgabe vorsetzt und sagt 'Mach mal'.
Dann geht es eben genauso wieder los: recherchieren, analysieren, Zeichnungen machen...

numLoc schrieb:

Ich bin wohl zu dumm für den Job, da ich auch nicht studiert habe.

Das kann ich nicht beurteilen. Ich kann aber nachvollziehen, dass eine Aufgabe, die die eigenen Fähigkeiten übersteigt frustrierend sein kann. Als ich die 8 Wochen im Studium nach dem Bug gesucht habe, wollte ich wissen und verstehen, was ich da produziert habe, dass es mich so lange aufhalten kann. Diese Lehr-Zeit hätte ich einem Projektleiter, der mich dafür bezahlt, nicht erklären können. Dessen Job wäre dann gewesen, mir Unterstützung bereitzustellen, die mit mir das Problem löst. Nur hatte ich niemanden, der mich da unterstützen konnte.
Ich habe aber draus gelernt.

Wenn Dein Projektleiter Dich 8 Wochen an so einem Problem sitzen lässt, dann darfst Du auch fragen, ob diese Situation seine beste Möglichkeit ist, das Problem zu lösen.
Wenn Du also erklären musst, warum Du immernoch nicht fertig bist und Dein Projektleiter reagiert nicht, dann hat er entweder keine bessere Alternative oder trägt die Verantwortung dafür, dass Du keine Unterstützung bekommst.
Wenn Du nicht das Beste bist, dann darfst Du nach Unterstützung fragen, und damit den Projektleiter zu unterstützen, um die Sache im Sinne der Firma zu beschleunigen.
Und wenn Du das Beste bist, was Deine Firma dazu aufzubieten hat, dann bist Du der richtige Mann für den Job.
Die Koordinierung, also den richtigen Mann für den Job zu finden, ist aber eigentlich der Job des Projektleiters.

Ich habe 'Praktische Informatik' studiert, was sich am besten mit "Wir werfen Dich ins kalte Wasser und gucken mal, ob Du schwimmen kannst" übersetzen lässt. Das war genau das Studium: Schreiben Sie einen Linux-Treiber für diese PCI-Karte. Ich kann unter Linux den gcc aufrufen... aber PCI-Treiber?
Das ist offensichtlich auch Dein Berufsbild.

Ich habe nahezu jeden Bug gefixt, auch dann wenn neuschreiben schneller gewesen wäre, weil ich verstehen wollte, welcher Fehler mir nicht sofort ins Auge springt. Und das ist manchmal frustrierend, weil es einem immer wieder bewusst macht, dass man eben nicht so gut ist, wie man glaubt.
Lob ist selten. Das größte Lob ist quasi, dass man die Bugs bekommt, an denen sich andere die Zähne ausgebissen haben. In der Regel mit den Worten "Kannst Du mal eben drüber schauen?".

Entwickeln ist ein strategisches Knobelspiel: Zum einen braucht man eine Strategie, wie man möglichst wenig knobeln muss und wenn man knobeln muss, dann braucht man eine Strategie, wie man das Problem lösen kann...
Ein Studierter kann nicht alles. Er hat mit etwas Glück ein paar Strategien auf Lager und die Erfahrung, dass man auch schonmal 8 Wochen lang debuggen muss, um Erfolgreich zu sein, bzw. hat gelernt, sich nicht den Bug durch die Fehlerausgabe zu vernichten. ^^

@numLoc: Vielleicht suchst du dir eine größere Firma. Kleine Firmen können enorm undankbar sein und ihre Mitarbeiter regelrecht verheizen.
Deine Zweifel kennen wohl nicht wenige Entwickler!

PS: Vll. lernst du parallel noch, wie du dir das Leben als Entwickler einfacher machen kannst. D. h., TDD, Patterns etc.

L. G.,
IBV

Marthog

Gregor schrieb:

Kann man bei C++ nicht irgendwie automatisch zusätzliche Checks beim Kompilieren einbauen?

Clang kann das, aber bis Apple den mit Google entwickelt hat, haben sich kaum Compilerbauer und auch sonst keine Firma dafuer verantwortlich gefuehlt.