Projektgrösse - Was ist klein, was ist gross?
-
RAM-Verbrauch.
-
Mannjahre
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 ...)
-
!rr!rr_. schrieb:
Mannjahre
Auch schwierig, weil manche Männer einfach Jahre für Kleinkram brauchen während andere in der selben Zeit spektakuläre Welten aufbauen.
Um das loszuwerden könnte man nicht die tatsächlich gebrauchten Mannjahre nehmen sondern die Zeit, die viele Entwickler aus verschiedenen Bereichen durchschnittlich als Entwicklungszeit dafür schätzen würden wenn sie es selbst machen müssten.
Mal abgesehen davon, dass man dafür viele Entwickler braucht, die alle drüber nachdenken, um eine Schätzung abgeben zu können, hätte man dann wieder das Problem, dass manche Themen vielleicht tendentiell eher unterschätzt und andere tendentiell eher überschätzt werden.
-
Dobi schrieb:
Um das loszuwerden könnte man nicht die tatsächlich gebrauchten Mannjahre nehmen sondern die Zeit, die viele Entwickler aus verschiedenen Bereichen durchschnittlich als Entwicklungszeit dafür schätzen würden wenn sie es selbst machen müssten.
Abre es kann sein, dass a-posteriori Projekte am Code geschätzt als sehr schnell implementierbar gelten "sind ja nur 10000 Zeilen Code", aber hinter dem Projekt a-priori ein Problem steckt, für dessen Lösung enorm viel Denkleistung rein gesteckt werden musste.
Der langsame Programmierer könnte am Ende dann doch der sein, der das Gesamtprojekt von Problemstellung bis Programmierung am Schnellsten hin kriegt.
-
!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!
