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

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.

otze

!rr!rr_. schrieb:

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.

Ich kann eine Matrix-matrix Multiplikation mit ziemlich genau 4 Zeilen Code schreiben. Das Problem ist nicht komplex. Aber: meine 4 Zeilen Lösung wird in der Praxis gegen die typischen 500+Zeilen Lösungen verlieren. Die Komplexität des Problems selbst ist gering, aber eine effiziente Implementation zu finden ist sehr aufwendig.

Aktueller Artikel auf TDWTF passt irgendwie ganz gut zum Thema: http://thedailywtf.com/Articles/The-Percent-Conversion.aspx

loks schrieb:

Aktueller Artikel auf TDWTF passt irgendwie ganz gut zum Thema: http://thedailywtf.com/Articles/The-Percent-Conversion.aspx

Ja, für Idioten ist LOC ungeeignet, aber jede andere Metric auch.

PS: Habt ihr nicht auch das Gefühl, dass die hälfte des dailywtf ein Fake ist.

poffoldreffer schrieb:

PS: Habt ihr nicht auch das Gefühl, dass die hälfte des dailywtf ein Fake ist.

Die Frage ist nicht unberechtigt da man sich oft denkt: Hey, so dumm kann man doch nicht sein. Und dann hatte ich vorrübergehend einen Mitarbeiter im Team der mich vom Gegenteil überzeugt hat. Der schaffte es auch für die simpelsten Aufgaben Code zu produzieren der immer um den Faktor 10 Umfangreicher war als nötig.

Beispiel:
SQL-Datenbank mit 3 Tabellen: Order, OrderItem, Produkt.
- Zu einer Order gibt es mehrere Orderitens
- In jedem Order-Item steht die ID des Produkt.

Aufabe: Liste alle Produkte-Namen einer Order einzeln auf.

Meine Lösung: Ein Select-statement über die Tabellem Produkt und OrderItem.

Seine Lösung: ca 100 Zeilen C#-Code mit mehreren Unterfunktionen, 3 oder 4 Dictionaries und einem Ablauf der so kompliziert war das ich fast einen halben Tag gebraucht habe um zu verstehen was er da versucht hat...

otze schrieb:

!rr!rr_. schrieb:

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

Ich kann eine Matrix-matrix Multiplikation mit ziemlich genau 4 Zeilen Code schreiben. Das Problem ist nicht komplex. Aber: meine 4 Zeilen Lösung wird in der Praxis gegen die typischen 500+Zeilen Lösungen verlieren.

dann mußt du die Metrik so modifizieren, daß sie deine Ansprüche widerspiegelt, etwa:

90% * Laufzeiteffizienz + 9% * #sLOC + 1% * #Kaffee

nman

Jester schrieb:

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.

Mein Punkt ist: Wenn du größer als "mehr LOC" definierst, dann klappt das natürlich. Ansonsten muss der Code recht ähnlichen Abstraktionsgrad haben, ähnliche Libraries benutzen, in einer ähnlichen Programmiersprache geschrieben sein, uvm.

Ich habe gerade erst letzte Woche knappe 3000 unnötige Zeilen dummen Java-Code geschrieben, der nur deswegen nötig war, weil mein Analysetool unbedingt ein Plug-In für ein anderes Tool werden musste (dabei keine zusätzlichen Library-Dependencies zum Projekt hinzufügen durfte) und nicht ein Matlab/Octave-Tool bleiben durfte (wie mein ~400zeiliger Prototyp es war). Zugegeben, die Java-Variante hat auch ein bisschen mehr Errorhandling, aber ich bin sicher, dass ich den Matlab-Prototypen noch aufräumen hätte können und samt Doku unterm Strich bei <=500 Zeilen geblieben wäre.

Versteh mich nicht falsch; unterm Strich betrachtet war die Aktion vmtl. für dieses Projekt sogar sinnvoll. Als reiner Java-Shop will man sich einfach keinen Code in irgendwelchen exotischen Non-Java-Sprachen einfangen, den man dann warten muss. Und dank Eclipse und dem Matlab-Prototypen war die Arbeit für mich auch recht einfaches Abtippen (und von Zeit zu Zeit Refaktorisieren), das nicht allzuviel Zeit (und somit Geld) gekostet hat.

Ein anderes Beispiel ist eine Firma, bei der ich letztes Jahr war. Die wollten von einem RDBMS auf ein anderes umstellen. Konnten mir allerdings nicht sagen, wieviele ihrer Stored Functions eigentlich noch in Verwendung sind. Nach einem halben Jahr Logging und ein paar Wochen Arbeit eines Praktikanten wussten wir dann: Knapp die Hälfte ist toter Code. Der aber natürlich die LOC gewaltig nach oben trieb.

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.

Nein, das vergleichen an sich finde ich ja sehr spannend. Aber normalerweise vergleiche ich, weil ich mir ein Bild von der Komplexität machen möchte. Davon, wie schwierig es wäre, etwas auszutauschen. Davon, wieviele Leute bis jetzt daran verschlissen wurden, wieviele Leute sich mit dem Code auskennen, wieviele Leute es weiterhin brauchen wird, um eine Library vernünftig zu erweitern, wieviel Aufräumarbeiten nötig sind, um auch projektfremde Leute effektiv daran arbeiten zu lassen, etc.

Das sind doch alles Aufgaben, denen man ständig begegnet. Aber keine mir bekannten Metriken helfen dabei sehr gut.

Klar, solange du zB. ausschließlich simple .net-GUI-Projekte mit ein bisschen Business-Logik in C# miteinander vergleichst, wird in der Regel die LOC-Sache größenordnungsmäßig recht gut funktionieren. Aber wenn sich die Projekte stärker unterscheiden, wird sowas wirklich schwierig.

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.

Faktor 10 funktioniert mit einigen Einschränkungen (siehe oben) vmtl. Aber wenn Anfänger in Programmierforen nach LOC fragen und selbige vergleichen, dann ist zumindest eine dieser Einschränkungen definitiv verletzt. Wir haben doch in jungen Teenagerjahren alle wochenlang pro Tag Tausend Zeilen dummen Code produziert und waren dann sehr stolz auf unsere Projekte, die zigtausend Zeilen Source-Code toll waren. (Nicht? Vielleicht war das auch nur eine Krankheit bei mir und in meinem damaligen Umfeld. )

Mechanics

@nman: ich seh das aber nicht als Gegenbeispiel. Das war eben Teil der Anforderung und damit nötig. Du hast ja nicht gesagt, dass du 3000 Zeilen überflüssigen Codes geschrieben hast. Der Code war nötig, um die gestellte Aufgabe zu lösen. Nicht das Kernproblem der Aufgabe, sondern die ganze Aufgabe. Und wenn es nötig ist, ist es eben nötig. Sonst könntest du auch sagen, ich hab das Problem in 100 Zeilen gelöst, aber weil der dumme Benuter ein Programm mit GUI haben wollte, und auch noch das Ergebnis sehen wollte, musste ich 5000 Zeilen schreiben. Alle Rahmenbedingungen gehören dazu.
Interoperabilität ist ein häufiges Problem und ich geh bei den meisten größeren Projekten davon aus, dass es dazugehört. Und das ist oft nicht der Teil, wo viel Code prodziert wird. So ein Problem hatte ich heute. Habe den ganzen Tag debuggt, und am Ende eine einzige Zeile geschrieben, die für die Lösung des Problems nötig war.
Außerdem bin ich immer noch der Meinung, dass bei vielen Codezeilen viele Argumente gegen die LOC Metrik zumindest abgeschwächt werden. Was spielt es bei einem Multimillionen Zeilen Projekt noch für eine Rolle, ob jemand die Matrizenmultiplikation in 100 oder 500 Zeilen gelöst hat? Irgendwo wird es Codestellen geben, die viel zu viel Code enthalten, andere Stellen werden sehr elegant und kompakt sein. Und zwar bei jedem großen Projekt, somit sind sie wieder vergleichbar

loks schrieb:

poffoldreffer schrieb:

PS: Habt ihr nicht auch das Gefühl, dass die hälfte des dailywtf ein Fake ist.

Die Frage ist nicht unberechtigt da man sich oft denkt: Hey, so dumm kann man doch nicht sein.

Ne, bei dem Code fällt mir auf, dass Early Out verwendet wird, was man bei so schlechten Programmierern selten findet. Und der Code schaut einfach viel zu generiert aus.

otze

poffoldreffer schrieb:

Ne, bei dem Code fällt mir auf, dass Early Out verwendet wird, was man bei so schlechten Programmierern selten findet. Und der Code schaut einfach viel zu generiert aus.

paid by the line nennt man das dann wohl.