Wie viele lines/h schaffen die Profi-Progger?
-
Mechanics schrieb:
Da ist man doch nicht im negativen Bereich. Auch wenn man am Ende weniger Zeilen hat, hat man doch Zeilen "geschrieben".
Das stimmt zwar, aber die Codezeilen insgesamt im Projekt sind gesunken.
Ändert aber nichts daran das lines/h so ziemlich das unsinnigste Kriterium ist um einen Entwickler einzustufen. Quantität ist selten ein Qualitätskriterium. Wenn jemand einen Entwickler langsam nennt, sollte er vorher auch das Ergebnis betrachten. Ich habe jedenfalls in der Praxis festgestellt das die langsamen im Endeffekt schneller sein können (sofern die Qualität dafür entsprechend höher ist).
-
in meinem Umfeld waren bisher immer die schnelleren auch die besseren. Einen Entwickler, der enorme Codemengen von niedriger Qualität produziert, habe ich ebensowenig erlebt wie einen, der im Schneckentempo höchste Qualität produziert.
Und das kann ich mir auch erklären.
Der bessere schafft viel Funktionalität mit wenig - aber dafür gutem - Code und ist deshalb schneller fertig und benötigt keine Zeit für Debugging/Rewrite-Zyklen.
-
Mechanics schrieb:
Im negativen Bereich wäre man höchstens, wenn man kurz vorm Kündigen irgendeine Datei aufmacht und ohne nachzudenken Strg+A, Entf, Strg+S drückt.
Was hoffentlich für den Betrieb kein Problem sein sollte, da das Projekt ja noch in der Quellcodeverwaltung vorliegt.
-
CodeMetrics schrieb:
Wie ist der Quotient (lines code/h)/(Verdienst in € in der Proggerei)?
Ich progge 1k lines/week und verdiene 4k/monat in meiner Proggeria.
:p
-
. o O ( mir reichts in der Regel nach einer Line wieder für ein paar Stunden )
-
Der Standard ist es doch, 10 Stunden zu diskutieren um dann 10 Zeilen zu schreiben.
-
Hi,
die Frage ist sehr schwierig zu beantworten.
Wie einige hier schon angemerkt haben, ist die Frage was rechnet man mit ein. Vom ersten Prototypen bis hin zum finalen Release vergeht einige Zeit wovon nur ein mehr oder weniger großer Anteil das "Coden" selbst ist.
Einen beträchtlichen Teil der Zeit verbringt man mit Meetings was die Software können soll, mit Architektur und Design Überlegungen und nicht zu vergessen Qualitätssicherung und Dokumentation.
Ich habe mal gelesen 8 Zeilen pro h seien "Durchschnitt". Bei einem Projekt von einem Jahr Laufzeit kommt man da auf etwa 15.000 Zeilen Quellcode. Wenn diese 15k LOC wie oben genannt den gesamten ersten Teil des Produktlebenszyklus bis zum Release abdecken, denke ich ist dieser Wert realistisch.
Wenn man jetzt natürlich hergeht und einen Entwickler damit beschäftigt, dass man ihm quasi vorbetet: 'Hey programmier mir mal eine Klasse welche die Schnittstelle I hat und die Funktionalität F realisiert', dann würde der erwartete Wert natürlich wesentlich höher liegen.
Viele Grüße!
-
starseed84 schrieb:
Einen beträchtlichen Teil der Zeit verbringt man mit Meetings was die Software können soll, mit Architektur und Design Überlegungen und nicht zu vergessen Qualitätssicherung und Dokumentation.
Aus der Praxis kann ich dir sagen: Das mag in großen Firmen/Entwicklungsteams der Standard sein, in kleinen wäre das eher der Glücksfall.
-
Es kommt doch auch darauf an, wie weit fortgreschritten das Projekt/Produkt ist. Wenn ich frisch auf der grünen Wiese anfange, produziere ich unheimlich viel Code.
Aber um so weiter ich komme, um so weniger Code schreibe ich. Manchmal schreibe ich dann Tage lang keinen Code, um dann (wie von Ethon gesagt) zehn Zeilen zu schreiben.Und dann wandelt sich etwas von "Projekt" in ein Support um... d.h. bei einer Produktpflege (hier mal eine neue Funktion, da mal ein Bugfix) ist nicht viel mit Codeschreiben angesagt.
-
asc schrieb:
starseed84 schrieb:
Einen beträchtlichen Teil der Zeit verbringt man mit Meetings was die Software können soll, mit Architektur und Design Überlegungen und nicht zu vergessen Qualitätssicherung und Dokumentation.
Aus der Praxis kann ich dir sagen: Das mag in großen Firmen/Entwicklungsteams der Standard sein, in kleinen wäre das eher der Glücksfall.
Ist das gut? Das kann man pauschal genauso wenig entscheiden, wie alles andere auch. Ich bin mittlerweile Senior Developer in meiner Firma und nehme an sehr vielen (auch strategischen) Besprechungen statt, und komm dadurch weniger zum Arbeiten. Viele davon natürlich viel zu lang und sinnlos. Oft werden diese Besprechungen von Managern oder Consultants organisiert, um die strategische Ausrichtung von Projekten oder das richtige Vorgehen bei bestimmten neuen Kundenanforderungen zu diskutieren. Und oft läuft es darauf hinaus, dass sie einfach viel zu wenig Ahnung von unserem System und unseren Möglichkeiten haben und deswegen ewig über irgendwas gesprochen wird, was mir eh schon klar ist.
Andererseits finde ich diese Besprechungen aber grundsätzlich sinnvoll, weil früher die Entwicklung einfach chaotischer verlief und vieles mehrfach entwickelt wurde, oder es wurde irgendwas noch viel stärker ausgebaut, was wir eigentlich ersetzen wollten.Qualitätssicherung und Dokumentation? Dafür haben wir eigene Abteilungen. Ja, paar Besprechungen mit der QS gibts, aber fällt nicht wirklich ins Gewicht.
-
Hi,
Mechanics schrieb:
Qualitätssicherung und Dokumentation? Dafür haben wir eigene Abteilungen. Ja, paar Besprechungen mit der QS gibts, aber fällt nicht wirklich ins Gewicht.
Auch die Arbeitszeit dieser QS würde ich dann zu der Gesamtarbeitszeit für die Software rechnen. Ob jetzt der Programmierer selbst die Unit-Tests schreibt und ausführt oder die QS - die Arbeitszeit ist erst mal weg. Die Effizienz kann man natürlich dadurch steuern - ins positive wie ins negative :).
Im Endeffekt würde ich es vielleicht so schreiben
LOC LOC/h = ----------------------------------------------------------------- Anforderungen + Codierung + Design + Doku + Integration + QualitätWer dann diese Arbeitspakete ausführt ist erst mal egal. Der Anteil ist natürlich je nach Projekt und Anforderungen variabel, hier und da mögen auch mal ganze Pakete gänzlich weg gelassen werden.
Was ich damit sagen möchte, Software ist weit mehr als das einhacken von Quellcode, entsprechend schwierig ist das ermitteln von LOC/h.
Viele Grüße
-
Die (sinnlose) Frage war doch, wie viele Lines/h Progger schaffen. Es ging nicht um die Effizienz der Firma an sich.
Ich würde das jetzt auch nicht dazuzählen. Es kommt drauf an, worauf man hinaus will. Zumindest sind Zeilen in der Hinsicht überhaupt keine sinnvolle Metrik, deswegen brauchen wir hier auch nicht über den Aufwand anderer Abteilungen zu reden. Man stellt sich ja (hoffentlich) nicht die Frage, wie lange brauchen wir, um ein Projekt mit 1.2 Mio Zeilen zu erstellen? Wenn man eine Aufwandsabschätzung macht, dann ist natürlich auch die Zeit der QS wichtig. Aber wenn man über sowas wie, nennen wir das mal Produktivität der Entwickler, spricht, dann finde ich die Zeit der QS nicht relevant.
