Projektgrösse - Was ist klein, was ist gross?
-
!rr!rr_. schrieb:
noch besser: Problemkomplexität desjenigen Problems, dessen Lösungsimplementation das Projekt ist. Aber dazu müßte man erstmal die Problemkomplexität des zugrundeliegenden Problems kennen, und das ist bisher nur in wenigen Fällen gelungen (Sortierprobleme, boolesche netze ...)
Wieso sollte ausgerechnet das ein gutes Maß sein? Es gibt Probleme, die lassen äußerst effiziente Algorithmen zu, aber implementieren möchte ich die auf keinen Fall. Mir scheint, das ist kein geeignetes Maß.
-
ich bin mittlerweile an dem punkt, wo ich mich einfach freu, wenn mein derzeitiges 'projekt' fertig ist/wird. es ist so verzwickt, hätt ichs nur mit php gemacht, wär ich schon 10 mal fertig
und das ohne komplexität, besondere algorithmen oder eine neue idee
-
Ich finde, wenn ein Projekt ausreichend "groß" ist, dann gleichen sich die Metriken meist aus... Es ist davon auszugehen, dass in jedem großen Projekt sowohl hochkomplexe Algorithmen sind, die bei wenigen Codezeilen sehr viel Zeit und Hirnschmalz in Anspruch nehmen, als auch viel Code, den man einfach runtertippt und dabei zehntausende von Programmzeilen produziert. Haben wir zumindest in unserem Projekt. Bei meinem Projekten ist es auch meist so, dass die zeilenmäßig größten Teile nicht die meiste Zeit brauchen. Ich kann Klasse mit 1000 Zeilen Code oder mehr an einem Tag runtertippen, aber es gibt auch Tage, da suche ich einfach einen Bug und ändere dabei eine einzige Zeile, oder ich überlege mir eine Lösung für einen Sonderfall.
-
Bill Gates schrieb:
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
-
Jester schrieb:
!rr!rr_. schrieb:
noch besser: Problemkomplexität desjenigen Problems, dessen Lösungsimplementation das Projekt ist.
Mir scheint, das ist kein geeignetes Maß.
wieso? Der Wert einer Lösung richtet sich nach der inhärenten Schwierigkeit des Problems.
Das ist der Idealfall.
-
Dann musst du halt ne Metrik für Problemkomplexität erfinden.
Etwas, womit alle zufrieden sind, wird sich hier vermutlich eh nicht finden lassen. Vielleicht bevorzugen einige von uns ja eh die Metrik, in der sie selbst mit ihrem Projekten am besten abschneiden würden.
Selbst sich auf ein Mittelwertsverfahren zur Kombination vieler Metriken zu einigen, könnte ziemlich schwierig werden.
-
hustenkuchen schrieb:
nman schrieb:
Projektgrößen in Zeilen Code zu messen ist… Eigenartig.
Was ist besser?
Für Schwanzlängenvergleiche in Programmierforen? Dafür passen sowohl Codezeilen als auch Klassenanzahl ganz gut. Besonders wenn man dann noch Binning über die LOC macht, um in "klein", "mittel" und "groß" einzuteilen.
Ansonsten ist es interessanter, sich anzusehen zu welchem Zweck überhaupt die Projektgröße gecheckt werden soll. Eine sinnvolle Metrik, mit der man jedem fachfremden BWLer ein paar hübsche Diagramme in die Hand drücken kann und damit dann ein brauchbares Bild der Projektgröße vermittelt, gibt es wohl kaum.
-
nman schrieb:
hustenkuchen schrieb:
nman schrieb:
Projektgrößen in Zeilen Code zu messen ist… Eigenartig.
Was ist besser?
Für Schwanzlängenvergleiche in Programmierforen? Dafür passen sowohl Codezeilen als auch Klassenanzahl ganz gut. Besonders wenn man dann noch Binning über die LOC macht, um in "klein", "mittel" und "groß" einzuteilen.
Ansonsten ist es interessanter, sich anzusehen zu welchem Zweck überhaupt die Projektgröße gecheckt werden soll. Eine sinnvolle Metrik, mit der man jedem fachfremden BWLer ein paar hübsche Diagramme in die Hand drücken kann und damit dann ein brauchbares Bild der Projektgröße vermittelt, gibt es wohl kaum.
Zuerst so tun, als ob es eigenartig ist und du das beurteilen kannst, weil du anscheinend was besseres weißt und dann kommt doch nur raus, dass du auch nix weißt, außer dass man LOC eigenartig finden muss...
-
hustenkuchen schrieb:
Zuerst so tun, als ob es eigenartig ist und du das beurteilen kannst, weil du anscheinend was besseres weißt
Das ist eine interessante Interpretation meines Posts. Ich brauche keine bessere Idee zu haben, um eine schlechte Idee zu erkennen.
Vielleicht ist es einfach eine dumme Idee, zu versuchen so etwas kompliziertes wie die Frage wieviel Arbeit bereits in einem Projekt steckt und wieviel man noch hineinstecken muss, in eine einzelne Zahl packen zu wollen, die auch fachfremde Menschen leicht verstehen und vergleichen können. Nein, Moment, du hast natürlich Recht, das kann es doch nicht sein…
-
nman schrieb:
hustenkuchen schrieb:
Zuerst so tun, als ob es eigenartig ist und du das beurteilen kannst, weil du anscheinend was besseres weißt
Das ist eine interessante Interpretation meines Posts. Ich brauche keine bessere Idee zu haben, um eine schlechte Idee zu erkennen.
Vielleicht ist es einfach eine dumme Idee, zu versuchen so etwas kompliziertes wie die Frage wieviel Arbeit bereits in einem Projekt steckt und wieviel man noch hineinstecken muss, in eine einzelne Zahl packen zu wollen, die auch fachfremde Menschen leicht verstehen und vergleichen können. Nein, Moment, du hast natürlich Recht, das kann es doch nicht sein…
Darum, wieviel Zeit man noch reinstecken muss, gings nie. Aber egal, schon ab deinem Post mit dem Schwanzlängenvergleich hätte man dich ignorieren sollen.
-
hustenkuchen schrieb:
Darum, wieviel Zeit man noch reinstecken muss, gings nie.
Nein, es ging um überhaupt nichts. Aber irgendwelche Metriken ohne Einsatzzweck definieren zu wollen, ist einfach nicht sinnvoll.
-
!rr!rr_. schrieb:
Jester schrieb:
!rr!rr_. schrieb:
noch besser: Problemkomplexität desjenigen Problems, dessen Lösungsimplementation das Projekt ist.
Mir scheint, das ist kein geeignetes Maß.
wieso? Der Wert einer Lösung richtet sich nach der inhärenten Schwierigkeit des Problems.
Das ist der Idealfall.
Einfache Polygone kann man in Linearzeit triangulieren, das wäre also ein leichtes Problem nach dieser Definition. Sortieren wäre dagegen schon ein bißchen schwerer. Wenn du Lust hast, dann kannst du dir ja mal das triangulierungspaper vonnchazelle anschauen, sind so ca. 40 Seiten und ich glaub nicht, dass das jemals jemand versucht hat zu implementieren. Aber entscheide selbst, was das größere Projekt ist, sortieren (zB mit Quicksort) oder die triangulierung.
Zumindest meine persönliche Einschätzung der Schwierigkeit und des Umfangs dieser Unterfangen sind der Problemkomplexität im algorithmischen Sinne diametral entgegengesetzt.
-
nman schrieb:
Klar kann man Codezeilen zählen; das Problem das ich damit habe ist, dass verdammt viele andere Parameter übereinstimmen müssen, damit die LOC zweier unterschiedlicher Projekte in irgendeiner Form brauchbar vergleichbar sind.
Es geht aber um eine Ordnung, nicht um ein direktes vergleichen. Welche Parameter sorgen denn deiner Meinung nach dafür, dass ich mich bei der Einschätzung, dass ein 100k Zeilen Projekt kleiner ist als ein 6 Mio Zeilen Projekt ist, verhaue?
-
nman schrieb:
hustenkuchen schrieb:
Darum, wieviel Zeit man noch reinstecken muss, gings nie.
Nein, es ging um überhaupt nichts. Aber irgendwelche Metriken ohne Einsatzzweck definieren zu wollen, ist einfach nicht sinnvoll.
Doch, es ging darum Projekte grob der Größe nach zu ordnen. Versuchst du grad dich in eine metadiskussion zu retten?
-
Ich glaube, ein Problem ist, dass viele befürchten, dass die bösen Schlipsträger sofort anfangen würden, irgendeine Metrik, auf die man sich als Entwickler einlässt, in Geld umzurechnen.
-
Jester schrieb:
Welche Parameter sorgen denn deiner Meinung nach dafür, dass ich mich bei der Einschätzung, dass ein 100k Zeilen Projekt kleiner ist als ein 6 Mio Zeilen Projekt ist, verhaue?
Es
ist
ja
die
Frage
wie
genau
die
Zeilen
denn
aufgebaut
sind.
Wann
immer
in
der
Vergangenheit
Manager
auf
die
dumme
Idee
gekommen
sind
Entwickler
nach
der
Anzahl
geschrieber
Zeilen
zu
bezahlen
haben
Programmierer
ihrerseits
schnell
Wege
gefunden
möglichst
viele
Zeilen
zu
produzieren.
Loop
Unrolling
FTW!
-
Dobi schrieb:
Ich glaube, ein Problem ist, dass viele befürchten, dass die bösen Schlipsträger sofort anfangen würden, irgendeine Metrik, auf die man sich als Entwickler einlässt, in Geld umzurechnen.
Das Problem ist, dass die bösen Schlipsträger nicht raffen, dass ich meinen Output bequem auf die Metrik anpassne kann um meinen Geld/Aufwand Quotienten zu maximieren.
Auf TDWTF findet man ab und zu das Resultat solcher tollen Stories. Wie zum Beispiel der Schlipsträger, der SVN-Commits für eine brauchbare Metrik hielt. Auf einmal hatte der SVN-Server nachts eine rege Aktivität zu verzeichnen die sich daraufhin begründete, dass Commits Wort für Wort einzeln durchgeführt wurden.
-
Jester schrieb:
Es geht aber um eine Ordnung, nicht um ein direktes vergleichen.
Wie willst du denn ordnen können, wenn du nicht vergleichen kannst?
Welche Parameter sorgen denn deiner Meinung nach dafür, dass ich mich bei der Einschätzung, dass ein 100k Zeilen Projekt kleiner ist als ein 6 Mio Zeilen Projekt ist, verhaue?
Die Frage ist, zu welchem Zweck du wissen möchtest welches Projekt größer ist. Wieviele Situationen sind dir bis dato in der richtigen Welt begegnet, wo du wissen wolltest, wie groß ein Projekt in Codezeilen ist und wo dich nicht in Wirklichkeit irgendwas anderes interessiert hat.
Und zu deiner Frage: LOC sind so unheimlich stark von Banalitäten wie Programmiersprachen und benutzten Libraries abhängig. Ich hatte es schon mit einigen Projekten zu tun, deren Zeilenzahl um einen Faktor n-zig kleiner war, als die von anderen Projekten und für die mehr Entwickler und Zeit benötigt wurde. Passiert doch ständig, wenn wiedermal irgendwelche Firmen Hunderttausende Zeilen selbstgebastelten Standardlibrary-Ersatz überall hin mitschleifen.
Versuchst du grad dich in eine metadiskussion zu retten?
Kennen wir uns nicht lange genug, um solchen Blödsinn nicht mehr nötig zu haben? Ich wüsste nicht, was ich hier wozu retten sollte. Aber das überrascht dich wohl nicht sonderlich.
-
Jester schrieb:
nman schrieb:
hustenkuchen schrieb:
Darum, wieviel Zeit man noch reinstecken muss, gings nie.
Nein, es ging um überhaupt nichts. Aber irgendwelche Metriken ohne Einsatzzweck definieren zu wollen, ist einfach nicht sinnvoll.
Doch, es ging darum Projekte grob der Größe nach zu ordnen. Versuchst du grad dich in eine metadiskussion zu retten?
Das wird hier etwas zu offtopic. Den Standpunkt von nman kann man durchaus verstehen und der Einwand, dass LOC keine gute Metrik ist, ist auch völlig richtig. Nur braucht man sich an der Diskussion nicht zu beteiligen, wenn es einen nicht interessiert.
Ich persönlich finds durchaus interessant, Projekte größenordnungsmäßig einzuschätzen und die Frage, was große Projekte sind und was nicht, und "wie groß" große Projekte sind hat mich auch beschäftigt, seit ich angefangen habe zu programmieren. Als ich angefangen habe, hatte ich irgendwann ein Projekt geschrieben, das 1500 Zeilen hatte. Ich habe Wochen Arbeit reingesteckt, weil ich keinerlei Erfahrung hatte und erstmal alles austüfteln musste. Ich fand die Codemenge damals sehr beachtlich. Und das war auch die einzige Metrik, die ich mir vorstellen konnte. Dann habe ich von jemandem gehört, der in seiner Firma an einem 20 000 Zeilen Projekt arbeitet und konnte mir so was großes gar nicht vorstellen...
Ich habe in mehreren kleinen Firmen gearbeitet und die meisten Projekte hatten eine Größenordnung 10-50 000 Zeilen. Sowas ist untereinander schwer zu vergleichen. 50 000 Zeilen 0815 Enterprise Anwendung in Java, die fast dasselbe macht wie die anderen Millionen 0815 Enterprise Anwendungen in Java und zu 90% aus Boilerplate besteht, ist nicht besonders anspruchsvoll. Hingegen können 10 000 Zeilen komplexer mathematischer Berechnungen wesentlich anspruchsvoller und aufwändiger sein.
Aber wie ich schon früher geschrieben habe, finde ich, dass es sich bei bestimmten Projektgrößen relativiert. Ein Projekt mit mehreren Millionen Zeilen wird wohl kaum ausschließlich aus hochkomplexen Berechnungen oder ausschließlich aus Boilerplate Code bestehen. Und ich kann mir jetzt kaum ein 100k Zeilen Projekt vorstellen, dass "größer" ist, als ein Multi Millionen Zeilen Projekt. Das ist für mich als Größenordnung durchaus aussagekräftig.
-
@otze: lol, zusammen mit copy-pasta-Programmierung kann man da ziemlich gut scoren. Ich kann mir gar nicht vorstellen, dass jemand sowas ernsthaft als Bewertung ansetzt, solche Stories hört man ja aber immer wieder mal. Gut, dass mein Chef (Mathematiker) zwar nicht wirklich programmieren kann, aber zumindest weiß, dass sowas Quatsch ist.
