Projektgrösse - Was ist klein, was ist gross?

Dobi

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.

nman

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

nman

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.

nman

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.

Jester

!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.

Jester

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?

Jester

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?

Dobi

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!

otze

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.

nman

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.

Mechanics

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.

Dobi

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

nman

Mechanics schrieb:

Nur braucht man sich an der Diskussion nicht zu beteiligen, wenn es einen nicht interessiert.

Der Vorwurf stimmt natürlich. Sorry, keine Ahnung, was mich da geritten hat, normalerweise schaffe ich es ganz gut, mich aus Sachen rauszuhalten, die ich uninteressant/dämlich finde.

Alles Varianten die mir schon begegnet sind.

Eine Zeile Code

for( int i=0; i < 100; ++i) printf("%d", i);

Zwei Zeilen Code

for( int i=0; i < 100; ++i) 
   printf("%d", i);

Drei Zeilen Code

for( int i=0; i < 100; ++i) {
   printf("%d", i);
}

Vier Zeilen Code

for( int i=0; i < 100; ++i) 
{
   printf("%d", i);
}

Fünf Zeilen Code

for( int i=0; i < 100; ++i) 
{
   printf("%d",
           i);
}

Sechs Zeilen Code

for( int i=0; 
     i < 100; 
     ++i)
{
   printf("%d", i);
}

Sieben Zeilen Code

for( int i=0; 
     i < 100; 
     ++i)
{
   printf("%d",
   i);
}

Mechanics

Grad für sowas gibts mehr oder weniger einheitliche Zählweisen. Eine geschweifte Klammer in einer Zeile zählt nicht als eigene Zeile usw. Ich würde die Anzahl der Zeilen natürlich nicht mit einem wc -l zählen. Aber wenn man sich darauf eignet, keine künstlich aufgeblähten Konstrukte zu zählen, dann ist zumindest dieses Argument keins mehr.

Jester

nman schrieb:

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?

Ich will einfach nur feststellen, ob ein Projekt deutlich größer ist als ein anderes. Projekte die nah aneinander sind kann ich damit nicht vergleichen und enthalte mich daher einer Aussage.

Da große Projekte üblicherweise ne halbwegs vernünftige Formatierung verwenden (nicht etwa ein Schlüsselwort pro zeile) und ich Projektgrößen anschauen möchte und nicht die Produktivität eines Programmierers abschätzen möchte, der dann möglicherweise extra aufbläst, scheinen mir eure Einwände bis jetzt am Kern der Sache vorbeizugehen.

Aber okay, wir können natürlich auch sagen, dass projekte ganz grundsätzlich garnicht vergleichbar sind. Ist ja auch total subjektiv und das müsste man dann von Fall zu Fall am besten basisdemokratisch entscheiden.

Ich bleib dabei, die Größenordnung kann man damit schon einschätzen, sieht man imo bis jetzt auch an den genannten beispielen (abgesehen von den leicht unkonkreten "einigen Projekten", die du jetzt ins Spiel gebracht hast). Alles was weniger als Faktor 5 auseinander liegt würde ich nicht ordnen wollen, aber bei Faktor 10 oder mehr wäre ich doch recht zuversichtlich.

viel Spaß noch beim Diskutieren

Wie schon geschrieben, der inhärente Wert einer Lösung richtet sich nach der Komplexität des Problems.

in implementationsabhängige Metriken fließt aber die Komplexität der Lösung ein, und die kann fernab der Komplexität einer optimalen Lösung (= Problemkomplexität) liegen.

zum Vergleich:

Kaum jemand würde auf die Idee kommen, einem 6-Stunden-Marathonläufer dreimal so viel Preisgeld zu bezahlen wie einem 2-Stunden-Marathonläufer, obwohl der erstere dreimal so lange "arbeitet".

Der 2-Stunden-Läufer löst ein viel schwierigeres Problem als der 6-Stunden-Läufer, und wird daher zurecht viel besser bezahlt.