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%

13 Antworten

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.

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

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

Ja: Auch ich kann das bestätigen.

3
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ß:Studium / Ausbildung – Master of Science in Informatik, Universität Paderborn 2014
Über 500

Kommt drauf an, können auch 0 sein. Softwareentwickler machen mehr als nur Code zu schreiben.

Ein Softwareentwickler ist ein Software engineer, also ein Ingenieur.

Die Arbeit ist nicht so unterschiedlich von der eines Ingenieures der eine Brücke oder Produkt entwickelt. Es geht nicht darum wie viel er schreibt, sondern was bei rumkommt.

Irgendwo zwischen 0 und 700 oder so würde ich habe sagen.

Softwareentwickler machen mehr als nur Code zu schreiben.

Was zb?

1
@canapril

Code Reviews (Code von andren Entwicklern anschauen), Dokumentation schreiben, Plannung(der Software an sich, Klassendiagramme usw., Aber auch des Verfahrens im Unternehmen).

Ein Softwareentwickler ist am ein Ingenieur. Man muss etwas neues entwerfen. Das braucht Planung und Organisation.

5
@canapril

Wovor hast du Angst?

Da scheißt dir schon niemand auf den Tisch. Es ist eben wichtig das man in dem Unternehmen eine einheitliche Code Qualität hat.

3
@jort93

Den Code von anderen anzuglotzen bis man versteht woran die Person überhaupt gedacht hat, ist schon etwas sche*ße, aber man bekommt ja trotzdem sein Geld für die Zeit.

Danke für die Antwort.

Braucht das ganze TheorieWissen aus dem Studium?

0
@canapril

Naja, gute Kommentare helfen beim verstehen.

Man wird ja nicht nach LOC bezahlt.

Ich bin selbst noch nicht durch mitm studium, kommt sicher auf den Betrieb an in dem du landest. Alles brauchst du sicher nicht, ist doch immer so. Können ja auch nicht wissen was du genau brauchst.

1
@canapril

Code lesen, häufig auch von anderen ist ein deutlich größerer Teil der Arbeit als neuen Code schreiben. Das macht von der Arbeit am Code wohl gut über 70% aus, neben dem Schreiben von neuen Code oder vorhandenen Code zu modifizieren.

Genau deshalb gibt es ja auch Sachen wie das Refactoring, Code Reviews und TDD, um diese Probleme dann nicht im Anschluss zu haben, auch wenn die Sachen kaum wo gelebt werden.

1
@jort93
Code Reviews (Code von andren Entwicklern anschauen), Dokumentation schreiben, Plannung(der Software an sich, Klassendiagramme usw., Aber auch des Verfahrens im Unternehmen).

Und einfache Support- und Moderationsaufgaben erledigen.

0

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ß:Beruf – Softwareentwickler/Projektleiter seit 2012

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
@apachy

Und Warum sollte man nach deiner Meinung KEIN Programmierer werden?

Was hast du gegen Programnierer?

0
@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

Was möchtest Du wissen?