Programmierleistung bzw. Quantität messen

[Simple Man]

Hi,

Mich würde mal interessieren, wie man Programmierleistung bewerten/messen/angeben kann.
Beim Kistenstapeln kann ich ungefähr schätzen wieviele Kisten pro Stunde schaffbar sind und das Ganze auf eine bestimmte Anzahl von Stunden oder Tagen vorsichtig hochrechnen.
Doch wie mache ich es beim Programmieren? z.B. eine Standardapplikation mit Formularen, Buttons, Datenbankabfragen, WebServices, etwas businesslogic um Daten zu parsen/verarbeiten etc etc

Dass es nicht trivial mit der simplen Anzahl von Codezeilen, Methoden, graphischen Elementen oder ähnlichem geht, ist mir auch klar. Gibt es da standardisierte Kriterien oder zumindest einen Ansatz um zu sehen ob jemand eine ruhige Kugel schiebt oder wirklich "produktiv" arbeitet?

 

[Zunra]

"Erfahrung und Bauchgefühl"

Denn auch wenn sich um "bekannte Sachen" handelt, kommt es auf die Feinheiten an.

Wenn du jemanden "überwachen" willst kannst du ih nur mit ähnlichen Aufgaben vergleichen. Und wenn er startk abweicht fragen warum. Denn es können auch bei einfachen Problemen unvorgesehene Dinge auftreten.

Und eine bitte an alle Erbsenzähler "Qualitaet geht vor Quantitaet!eins11"

 

[Majestro1337]

naja du kannst doch ähnlich komplexe projekte und deren gesamtarbeitszeit als relation nehmen...

 

[ice-breaker]

Ich glaube er meint damit mehr, dass man durch eine Erfassung der Leistung eines Programmierers auch zwei oder mehr vergleichen kann. Also alle Programmieren auf irgendein Modell abbilden, dass sich dann vergleichen lässt.

 

[Der_Dicke82]

Naja, du musst es einfach mit deinen eigenen Maßstäben messen. Worauf kommt es dir am meisten an? Und wurde das gut umgesetzt?

Viele Dinge sind einfach in gewisser weise gegenläufig Geschwindigkeit <---> Qualität.

Also worauf kommt es dir an? Bei so etwas wie Code ist ja evtl. auch etwas wie Dokumentation nicht ganz unwichtig, falls jemand anderes später noch etwas ändern soll.

Also kommt es wirklich im Einzelfall auf die gestellte Aufgabe an und demnach sollte man den Programmierer auch bewerten. Die Bewertung an sich würde ich dann einfach an einem Vergleich mit besseren/schlechteren Programmierern machen. Ein Standardbewertungssystem halte ich da für ausgeschlossen.

Gruß, Stefan

 

[can320]

Zerbrich dir nicht unnötig den Kopf. Nimm einfach die Zeilenanzahl. Die Teilst du duch die Zeit. Ergibt die Leistungsfähigkeit des Programmierers. (Doku Zeilen einfach mitzählen)

 

[Zunra]

Viele Dinge sind einfach in gewisser weise gegenläufig Geschwindigkeit <---> Qualität.

Danke :-)
Ich schreibe ohne Probleme XYZ Zeilen an Code und setze XYZ Features um. Leider treten unter bestimmten Bedingungen dann Bugs auf :-)

 

[miac]

Hängt sicher auch vom Einsatzgebiet ab.

Ansonsten ist Erfahrung bei Abnahme des Ergebnis nötig.

Leider gibt es da große Unterschiede.
Im SAP Bereich gibt es zum Beispiel unendlich viele Bastler, die überhaupt keine Ahnung von internen Datenstrukturen, Benennung und Modularisierung haben. Auftraggeber ist aber meistens einer, der nur das Ergebnis sieht. Und später kommt dann der große Supportbedarf bezüglich Wartung. Das ist die "niedrigster Stundensatz geht vor" Mentalität. Hier ist immer noch großer Output wichtig.

In der Automatisierung zählt Sicherheit und da wird auch die Qualitätssicherung größer geschrieben. Hier zählt die Qualität des Codes mehr.

 

[Zunra]

Zerbrich dir nicht unnötig den Kopf. Nimm einfach die Zeilenanzahl. Die Teilst du duch die Zeit. Ergibt die Leistungsfähigkeit des Programmierers. (Doku Zeilen einfach mitzählen)

Genau das funktioniert nicht!
Die anzahl der Zeilen steht weder für umgetzte Features noch für Qualitaet!

Du kannst ein Problem in 10 oder 50 Zeilen lösen. Und beide Lösungen können gut oder schlecht sein.

Eine Messung nach Zeilen ist (sorry für den Ausdruck): "Totaler Schwachsinn!"

 

[miac]

Zerbrich dir nicht unnötig den Kopf. Nimm einfach die Zeilenanzahl. Die Teilst du duch die Zeit. Ergibt die Leistungsfähigkeit des Programmierers. (Doku Zeilen einfach mitzählen)

Genau da gewinnen die Spaghetti-code Programmierer.

 

[keef]

Ganz einfach:
Es geht nicht!
Um das zu beurteilen musst Du gleiche Aufgaben an die Programmierer verteilen und anschl. deren Ergebnis prüfen. Sprich Du musst es selber können oder einen kennen der sich damit auskennt.
Alles andere ist die typische BWLer-Denke "alles ist messbar". Auch wenn ich nicht weiß worum es geht.
Zu beachten ist dabei in erster Linie Doku, Qualität, Performance.
Anzahl der Zeilen ist kein Kriterium! Wenn einer eine Funktion nicht kennt und diese mit 100 Zeilen codieren muss, ist er ja nicht besser als einer der de Funktion kennt und nur eine Zeile braucht

cu
keef

 

[Whiz-zarD]

Genau das funktioniert nicht!
Die anzahl der Zeilen steht weder für umgetzte Features noch für Qualitaet!

Du kannst ein Problem in 10 oder 50 Zeilen lösen. Und beide Lösungen können gut oder schlecht sein.

Das Problem ist nicht nur die Lösung selbst. Das Problem ist auch die Sprache.
Z.B. wenn man eine Liste implementieren möchte: In moderneren Sprachen (z.B. C# oder Java) gehört sowas zum Sprachumfang. Eine Zeile reicht und man hat eine Liste.
In C z.B. muss man entweder auf fremde Bibliotheken zurückgreifen, oder selber eine Liste implementieren. Beides benötigt mehr Zeit und vorallem mehr Zeilen.

In C benötigt man generell mehr Zeilen, als in C# oder Java, da der Programmierer sich selbst noch im Dinge kümmern muss, die C#/Java selbst übernehmen (z.B. Garbage Collector)

Die Leistung wird zwar gerne in der Industrie in Zeilen gemessen, aber aussagen tut die Zeilenanzahl gar nichts, weil es von verschiedenen Faktoren abhängig ist, die hier nicht berücksichtigt werden.

 

[Tumbleweed]

Würde grob unterteilen in Effektivität und Effizienz. Die Effektivität kannst du ganz gut bewerten. Schafft ein Programmierer in vorgegebener Zeit eine Aufgabe, dann sollte das einem anderen auch möglich sein (im direkten Vergleich). Zumindest sollte die Abweichung nicht sonderlich groß sein. Wobei man manchmal auch ein Brett vorm Kopf hat. Programmierer sind auch nur Menschen und manchmal denkt man eben in eine falsche Richtung.
Wenn du dann die Effizienz betrachtest, und das kannst du nur, wenn du selber ziemlich gut bist, dann kann die ganze Sache mit der Effektivität natürlich noch mal kippen. Wenn der langsamere Programmierer zwar nicht ganz fertig geworden ist bzw. nicht so schnell wie der erste Programmierer, dafür aber eine elegantere Lösung gezaubert hat, dann würde ich das definitiv bevorzugen, weil es auf lange Sicht Aufwand (und somit Kosten) spart. Wartung ist der übelste Brocken und da rächt es sich, wenn unsauber rumgehackt wurde.

Es gibt code metrics, code coverage usw. Da kannst du dir Statistiken auflisten lassen wie das Verhältnis von Kommentaren zu lines of code usw. Ist eine nette Spielerei, die Aussagekraft kann ich nicht bewerten. Statistiken sind eben Statistiken.

Abgesehen vom Programmieren, ist meiner Meinung nach Teamfähigkeit auch nicht zu unterschätzen. Kenne Programmierer, die wunderbar ihr eigenes Süppchen kochen. Sobald ihnen dann aber einer reinpfuscht mit einem anderen Stil, ist es nicht mehr so spaßig.

Alles andere ist die typische BWLer-Denke "alles ist messbar". Auch wenn ich nicht weiß worum es geht

Edit:
Stimmt Zunra, das habe ich durcheinander gewürfelt.

 

[Zunra]

Das Problem ist nicht nur die Lösung selbst. Das Problem ist auch die Sprache.

Auch das.

Mal zurück zur Anfangsfrage ... Reden wir eigentlich über "Programmieren" oder "SoftwareEntwicklung" ...

Es ist halt ein weites Feld.

Und darum komme ich zu meinem ersten Posting zurück. Man kann es nur um zusammenhang mit anderen Leuten (welche im gleichen Projekt arbeiten) bewerten und selbst da muss man noch fragen warum es läbger oder kürzer gedauert hat.

Denn (noch ein dummes Zitat) "Der Teufel ist ein Eichhörnchen" gerade im bereich Software :-)

Ergänzung (25. September 2011)

Es gibt code metrics, code coverage usw. Da kannst du dir Statistiken auflisten lassen wie das Verhältnis von Kommentaren zu lines of code usw. Ist eine nette Spielerei, die Aussagekraft kann ich nicht bewerten. Statistiken sind eben Statistiken.

So sieht das aus...
Und btw "code coverage" bezieht (meistens) sich auf die Code-Abdeckung von Testfällen.
Das auch noch getestet werden soll war noch gar nicht Thema

Bahh ich rege mich schon wieder zu viel auf, aber diesem Thema habe ich leider zu oft mit BWL Leuten zu schaffen ...

So und nun haue ich mich besser ins Bett ......

 

[Eagle-PsyX-]

Ich denke ebenfalls es lässt sich nicht wirklich messen.

Abgesehen von Leistungsverbrauch, Ressourcen (also Effizienz), Dokumentation und Qualität kann z.B. auch die Kompatibilität oder auch Flexibilität erforderlich sein.
Eine Funktion könnte beim selben Ziel in 50 oder 90 Zielen programmiert sein. Erfüllt das selbe Ergebnis.
Jetzt will ich eine aber eine "kleine" Änderung haben und die 50 Zeilen müssen komplett überarbeitet werden, während bei dem Anderen nur ein andere Parameter übergeben wird - Was ist besser?

Fazit: Es kommt sehr auf die Situation und genaue Aufgabenstellung an. Ein Vergleich wirst du nur haben, wenn du zwei Programmierer es angehen lässt und später mit ihnen auch besprichst, wieso es jeder auf seinem Weg so getan hat (also du solltest ebenso kompetent sein).

 

[Funart]

Allgemein fasse ich noch einmal paar Dinge zusammen die von Bedeutung sind.

• OOP (kurze prägnante Methoden, kapselung, keine Unnötigen Schnittstellen, modular, etc)
• Dokumentation
• Verwenden von gängigen pattern
• Testabdeckung
• Lesbarkeit
• Falls ein GUI oder ähnliches vorhanden ist wie gut ist deren Verwendbarkeit (das kostet am meisten Zeit und zwar WIRKLICH VIEL ZEIT)
• Trennung von Code und Konfiguration, Internationalisierung

Sind einmal ein paar Punkte mit dennen du arbeiten kannst. Wenn man selbst nicht wirklich Programmieren kann fällt die Einschätzung von Qualität schwer. Gibt einfach auch dinge die einen Studierten Informatiker von einem gelehrnten Informatiker unterscheiden sollten.

Um wirklich festzustellen um jemand etwas Arbeitet, kriegt man in der Regel am besten durch ein Meeting raus (sollte kein künstlicher druck aufgebaut werden). Dabei sollte man rauskriegen ob der Programmierer an seine Grenzen stößt, seinen job gut macht, oder vielleicht eine ruhige Kugel schiebt.
Eines sollte man bei Softwareentwicklung immer bedenken, es ist keien akkordarbeit. Dies würde die Kreativität einschränken und zu Betriebsblindheit führen. Teilweise ist man vielleicht selbst mit der Lösung unzufrieden und will es überarbeiten (refaktorn) was dann zusätzliche Zeit kostet aber sich in der Regel auszahlt.

Bin selbst Student und arbeite auch neben der Uni als Programmierer. Hab auf der Uni durch jede Menge Gruppenarbeiten gelernt einzuschätzen, wenn einer ich sags mal direkt Bullshit redet und einfach faul war und seine Arbeit nicht gemacht hat oder aber einfach auch an seine derzeitigen Grenzen stößt und sich weigert sich weiterzuentwickeln. Wäre wohl mittlerweile gut geeignet umMitarbeiter zu bewerten hab einfach sicher schon 20-30 "möchtegern Informatiker" kennengelernt die sich nicht weiterentwickeln wollen.
Wenns um einen konkreten Fall geht vielleicht hab ich ja noch den einen oder anderen Tipp einfach PM

 

[TheCadillacMan]

Softwareentwicklung ist für mich in gewisser Weise ein kreativer Prozess. Entscheidend ist nicht wie viele Zeilen Code ich schreibe sondern ob die entwickelte Lösung zum Problem passt (inkl. aller Randbedingungen wie Wart- und Testbarkeit, Dokumentation etc).
Ein Programmierer der die nur möglichst schnell die erstbeste Lösung "hinrotzt" ohne sich wirklich Gedanken über die Problemstellung gemacht zu haben ist in der Regel nur von geringem Wert für das Projekt.

Ich würde zwei Dinge zu:
1. Code lesen: Lies regelmäßig Code und versuch ihn zu verstehen.
2. Reden: Mach ein regelmäßiges (wöchentlich, oder sogar täglich) Meeting in dem alle(!) Teammitglieder kurz ihren Fortschritt beschreiben.

Beides funktioniert natürlich nur wenn du selbst Programmierer bist und somit die Aussagen auch beurteilen kannst. Ich als Informatiker würde mir ja auch nicht anmaßen z. B. die Arbeit eines Architekten im Detail zu beurteilen.

 

[Fonce]

In C benötigt man generell mehr Zeilen, als in C# oder Java, da der Programmierer sich selbst noch im Dinge kümmern muss, die C#/Java selbst übernehmen (z.B. Garbage Collector)

Das halte ich für ein Gerücht das man bei C immer mehr Zeilen braucht als in C# oder Java.

 

[Whiz-zarD]

Schön für dich

 

[ice-breaker]

Das halte ich für ein Gerücht das man bei C immer mehr Zeilen braucht als in C# oder Java.

da steht ja auch nicht mit einem Wort, dass immer mehr Code gebraucht wird, das ist nur deine Intepretation, um dich auflehnen und C verteidigen zu können
Whiz-zarD schrieb, dass man in C generell mehr Zeilen benötigt, da kann es dann natürlich auch Ausnahmen geben, wenn es gerade in C durch ein Sprachfeature der Code kompakter geschrieben werden kann, aber gleicher Code mit Memory Management wird eben i.R. länger sein als der gleiche Code ohne Memory Management, da ich mir einfach malloc und free Befehle sparen kann.


Ein tolles Beispiel für die Zeilen sagen nichts aus sind Sprachen wie z.B. Scala: Dort lässt sich in wenigen Zeilen ein über hundert Zeilen Java-Pendant abbilden, es ist viel kürzer, aber oftmals alles andere als lesbarer im Vergleich mit der Java-Version.