Wie viele Zeilen Code schreiben Softwareentwickler bzw. Programmierer durchschnittlich pro Tag?

Das Ergebnis basiert auf 37 Abstimmungen

Über 500 62%
0 - 10 16%
201 - 500 14%
51 - 100 8%
11 - 30 0%
31 - 50 0%
101 - 200 0%

12 Antworten

201 - 500

Rund 250 Zeilen Funktionalität und dann nochmal mindestens 250 Zeilen für Testen. Dabei ist zu beachten, dass dahinter sehr viel Recherche und Nachschlagen in Dokumentationen steht, was in der Arbeitszeit auch eine wichtige Rolle spielt, davon ausgehend, dass kein Code importiert wird, sondern wirklich Zeichen für Zeichen abgetippt.

Weniger als 0! Kein Scherz! (Erklärung in den nächsten Absätzen ...)

Ich spreche hier mal aus meiner eigenen Erfahrung als professioneller Entwickler mit vielen zich Jahren Berufserfahrung.

Ich werde oft in Projekte berufen, die seit vielen Jahren bzw. Jahrzehnten gewachsen sind.

Das erste, was ich mit Legacy-Code mache, ist vernünftige Tests zu schreiben, bzw. das System überhaupt erst mal testbar zu machen.

Im zweiten Schritt wird "Kosmetik" gemacht und der Code aufgehübscht, offensichtliche Bugs entfernt, Sicherungen eingebaut, uvm.

Dann wird groß ausgemistet, und größere Codeteile redesigned bzw. extrem viel alter Klumpatsch weggeworfen.

Am Ende werden neue Features eingebaut und die Software weiter gehärtet.

Und jetzt kommts: Wenn ich damit fertig bin, habe ich i. d. R. mehr Codezeilen vernichtet, als insgesamt hinzugefügt.

An den Projektmetriken sieht man dann, dass ich eine negative Anzahl an Codezeilen beigetragen habe, was immer ganz lustig aussieht.

Das Projekt ist danach deutlich schlanker, schneller, sicherer, allgemein effizienter, hat vernünftige Tests und neue Features.

Deshalb ist es für einige Entwickler gar nicht mal so unüblich, wenn sie über die Projektlaufzeit gemittelt im Schnitt -10000 (Minus Zehntausend!) Zeilen Code pro Tag "produzieren".

Aber das bezog sich auf Legacy-Code.

Meine allgemeine Erfahrung bei Neuentwicklungen ist, dass die besten Programmierer die wenigsten Zeilen an Code schreiben, der dann letztendlich auch im Projekt dauerhaft (!) bestehen bleiben.

Die schlechtesten Entwickler schreiben meistens den meisten Code, der dann aber natürlich nicht gut durchdacht ist, und eine Million mal mutiert, bis er dann irgendwann entfernt wird.

Solche Entwickler produzieren natürlich massenhaft LOCs, aber da das alles Abfall ist, bleibt davon am Ende nicht viel übrig.

Gute Entwickler überlegen sich vorher was und vor allem wie sie es schreiben, was dann meist enorm kurz, effizient und dennoch semantisch gut verständlich ist.

Bei Stackoverflow und auch an anderer Stelle werden dazu Statistiken erhoben, und seit den 90ern ändert sich nicht viel daran: Gute Programmierer schaffen etwas über 100 Zeilen pro Tag. Damit sind die gemeint, die auch übrig bleiben.

Du kannst natürlich locker 2000 oder 3000 Zeilen pro Tag eintippen, aber da kann ich dir garantieren, dass das am Ende größtenteils Murks sein wird.

Fazit: Je besser der Entwickler, desto weniger LOCs. Und bei Legacy-Projekten sind negative LOCs eher die Regel, als die Ausnahme, zumindest in der Anfangsphase. :)

CSANecromancer  01.04.2020, 07:45

Kann ich so bestätigen. Eine meiner bisher härteste Geschichte war 1/250 Zeilen pro Tag: Ich habe 1,5 Jahre (500 Tage) nach einem schweren Bug gesucht, der dann mit zwei Zeilen Code zu fixen war.

Aber auch in den negativen Bereich komme ich des öfteren, so wie von hilfsbereit beschrieben.

3
CSANecromancer  01.04.2020, 13:25
@colum123

Das war sooo übel.

Es ging um eine zentrale (netzwerktechnisch gesehen, also Server) Rechenkomponente, welche höchstmodular aufgebaut ist. Das heisst, dass Logiken für einzelne Rechnungsläufe zur Laufzeit eingebunden werden, abhängig von einigen Dutzend Konfigurationen. Das wird deswegen so gehandhabt, damit möglichst wenig Overhead vorhanden ist und die einzelnen Rechnungsläufe so schnell wie nur irgend möglich ablaufen können.

So. Und jetzt kam es in manchen Fällen zu Buchungsfehlern, die sich aber nicht wirklich zuordnen liessen, da die Fehlbeträge immer zufällig erschienen. Diese gesamte Rechenkomponente war so komplex, dass es niemanden in der Firma gab, der noch durch das Teil durchstieg, da der ursprünglliche Entwickler schon lange weg war und die Dokumentation branchentypisch (sprich: nonexistent) war.

Ich habe fast 1,5 Jahre gebraucht, um die Abläufe und Vorgänge in der Komponenten nachvollziehen zu können. Danach konnte ich die Fehlberechnung in einem von mir aufgesetzten Test nachstellen. Nachdem das gelungen war, habe ich mich einen halben Tag lang gefreut und habe danach 30 Minuten gebraucht, um die Fehlerstelle zu finden und 3 Minuten, um den Fehler mit 2 Zeilen zu fixen: Bei einer Korrekturberechnung war es so, dass in einem bestimmten Konfigurationsfall (nicht allzu häufig aber eben auch nicht tierisch selten) ein Betrag erst abgezogen und später korrigiert wieder aufgerechnet werden sollte. Beim Korrekturabzug fehlte das Minus vor dem zu verrechnenden Betrag.

  1. Zeile: Prüfen, ob die Korrekturkonfiguration auch wirklich greift.
  2. Zeile: Den Korrekturbetrag mal -1.0 genommen.
2
grtgrt  01.04.2020, 09:14

Ja: Auch ich kann das bestätigen.

3

Puh im Durchschnitt könnte ich das gar nicht betiteln. Es gibt sicher Tage, bei Greenfield Projekten, also neuen ohne bestehenden Code, wo man mehrere Tausend Zeilen am Tag schreibt. Genauso gibt es Tage, wo man gar keinen Code schreibt.

Generell spielen aber viele Faktoren rein. Du hast Leute die sauberer programmieren und kleine Funktionen schreiben, das wieder rum sorgt wieder für einen Overhead im Sinne von Funktionsköpfen, gleiche mit Klassen, was die Zeilenanzahl hochtreiben kann.

Auf der anderen Seite hast du Leute, die schlicht viel Copy & Pasten, was zum gleichen Ergebnis führt.

Der nächste betreibt Test-driven Development und hat damit anfangs nicht selten mehr als doppelt soviel Code.

Abgesehen davon, was ist eine Zeile? Der eine gibt ein JSON Objekt oder ein Array relativ Kompakt in einer Zeile aus, beim nächsten ist ein Item in einer Zeile.

Daneben gibt es ja noch andere Sachen als die Programmiersprache selbst wie entsprechende Query Languages z.B. SQL. Bei einem normalisierten Datenbankmodell kommen entsprechende JOINs zu Stande und bei einer vernünftigen Abfrage, die nur die Spalten abfragt, die man benötigt, kommen auch dadurch ordentlich Zeilen zusammen. Da kommen auch mal für relativ simple Sachen und die reine "Verdrahtung" hunderte Zeilen zusammen.

Auch Validierungen, Logging und so Sachen erzeugen viele Zeilen, ohne groß Logik, die fix runter geschrieben sind.

In Summe ist das Schreiben von Code aber oft auch gar nicht der Hauptteil der Arbeit, sondern Code lesen, Code verstehen, Absprache mit Kollegen, kleine Änderungen machen, auch mal Code löschen, Probleme verstehen, Meetings, Planungen, Gespräche mit dem Kunden, Schreiben von Dokumentationen, Lesen von Dokumentationen, lösen von Git Konflikten, hier mal Software aktualisieren, da mal was in der IDE konfigurieren oder einfach mal einen Kollegen helfen, ihm über die Schulter schauen usw. Gibt sicher viele, viele Tage, wo nicht eine Zeile Code geschrieben wird oder eben verdammt wenige.

Und natürlich gibt es auch massive Unterschiede je nach Bereich und Firmengröße. Im Webbereich haben wir ja z.B. noch CSS usw. wo viele Zeilen zusammen kommen können. In einer größeren Firma gibt es vermutlich meist striktere Abläufe, Code Reviews usw. vor allem wenn man Produkte erzeugt.

Wer eher Dienstleister ist mit Wartungsverträgen und co. und einen Kunden am Ohr hat, weil bei dem alles steht und 50 Leute die Hände in den Taschen hat, der hat diese Zeit nicht. Da kommen auch mal fix hunderte Zeilen bei einer Operation am offenen Herzen rein, quasi einhändig, während der Kunde alle 30 Sekunden anruft und das immer eine Etage höher geht, bis du den Geschäftsführer dran hast, der mit Wörtern wie Regressansprüchen um sich wirft. Natürlich alles entstanden aus einen Anruf auf der Hotline, der dich um 3 Uhr Nachts aus dem Bett geklingelt hat.

Da sagst du natürlich nicht, sorry ich wecke noch ein paar Kollegen, wir machen mal eben ein Code Review und ein paar Integrationstests.

Auf der anderen Seite wird so wohl nie etwas in den Google Algorithmus reinkommen.

Woher ich das weiß:Berufserfahrung – Softwareentwickler/Projektleiter seit 2012
apachy  01.04.2020, 07:42

Btw du musst natürlich auch nicht Programmierer werden, es gibt in der IT noch viele weitere Funktionen, wie z.B. Projektleiter usw. In kleinen Firmen ist man hingegen häufig Mädchen für alles mit einem unterschied ausgeprägten Schwerpunkt.

0
NackterGerd  04.04.2020, 12:27
@apachy

Und Warum sollte man nach deiner Meinung KEIN Programmierer werden?

Was hast du gegen Programnierer?

0
apachy  04.04.2020, 13:53
@NackterGerd

Ich sagte doch nicht, er soll kein Programmierer werden, sondern er MUSS keiner werden. Er schreibt hier in den Kommentaren ja, dass er nicht so Lust hat auf Code von anderen lesen und den verstehen, Code Reviews usw.

Er hat mit seinem Background jede Menge weitere Möglichkeiten, wenn der Bereich zu viele Sachen enthält, die ihm nicht liegen. Zumeist auch deutlich besser bezahlt.

0
51 - 100

Hängt auch stark davon ab, an was man arbeitet, und welche Programmiersprache man nutzt.

Setzt man aktuell ein neues Projekt auf? Dann können es hunderte Zeilen sein, in "gesprächigen" Sprachen mit viel Boilerplate wie Java sogar noch mehr. Arbeitet man an einer bestehenden, großen Codebase, dann sind 100 Zeilen bereits ziemlich viel.

Es ist wichtig im Hinterkopf zu behalten, dass das eine sehr schlechte Metrik für die Produktivität von Entwicklern ist.

Woher ich das weiß:Berufserfahrung – Software Engineer seit 2015, u.a. Telefónica und gutefrage
0 - 10

Gefühlt ist man mehr am Code löschen als am schreiben. Teilweise wird Code überflüssig, an eine andere Stelle verschoben oder durch geschicktes Refactoring oder den sinnvollen(!!) Einsatz von Design Pattern vereinfacht. Wenn ein Projekt mal die initiale Phase passiert hat, kommen halt auch viele Maintenance und Bugfix Aufgaben dazu.

Und selbst wenn man mal ein neues Feature entwickelt, coded man hoffentlich nicht einfach drauf los, sondern macht sich Gedanken über sinnvolles Design und Abhängigkeiten des Codings.

Neben dem eigentlichen Code schreibt man natürlich noch einiges an Unit und Integration Tests (das zähle ich nicht in die Statistik rein - ebensowenig wie Konfigurationsdateien für Docker, Jenkins, etc.), das frisst auch noch Zeit.

Dann gibt es noch die üblichen Zeitfresser wie Teammeetings, Code Reviews, etc.