/blog/wvk

Gerade schaute ich mich ein wenig auf koders.com um. Wer die Seite kennt, weiß bestimmt, dass zu den dort aufgelisteten Projekten immer eine kleine Statistik angezeigt wird, die u.A. über den Anteil der im jeweiligen Projekt verwendeten Programmiersprachen, geschätzte Entwicklungskosten etc. informiert. Und da blieb mein Auge mehrfach hängen, als ich (mal wieder) feststellte, welche Kosten da auch für kleine Projekte (ein paar wenige Tausend Zeilen Code) aufgeführt werden. Da packte mich die Neugier: ich installierte mir David A. Wheeler's Programm sloccount. Dieses Programm leistet genau oben Beschriebenes, sprich es zählt die Physical Source Lines of Code (SLOC), also Programmquelltext minus Kommentare minus trivialem wie HTML, SQL, CSS usw., listet eine kleine Statistik über die verwendeten Programmiersprachen auf und wagt einige Schätzungen über den Entwicklungsaufwand anzustellen.

Für meinen bisher im Rahmen der Diplomarbeit entstandenen Code der wäre das also:

SLOC    Directory       SLOC-by-Language (Sorted)
2020    app             ruby=2020
1319    test            ruby=1319
603     db              ruby=603
61      config          ruby=61
4       public          ruby=4
0       components      (none)
0       doc             (none)
0       lib             (none)
0       log             (none)
0       script          (none)
0       templates       (none)
0       tmp             (none)
0       top_dir         (none)
0       vendor          (none)

Totals grouped by language (dominant language first):
ruby:          4007 (100.00%)

Total Physical Source Lines of Code (SLOC)                = 4,007
Development Effort Estimate, Person-Years (Person-Months) = 0.86 (10.31)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 0.51 (6.07)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 1.70
Total Estimated Cost to Develop                           = $ 20,616
(average salary = $10,000/year, overhead = 2.40).

WHOW! sag ich da nur! Bei den Zahlen kriegt man ja locker einen SLOCkauf ;-) -- also mal abgesehen davon, dass die Entwicklungszeit schonmal um bald eine Größenodnung höher angesetzt wird als was ich bisher aufgewendet habe, sind die Entwicklungskosten (wie ich mal mit einem Jahresgehalt von 10'000$ bzw. €) angesetzt habe) von rund 20'000 Währungseinheiten schon beachtlich. Wer bezahlt das am Ende?

Aber mal abgesehen vom Preis: Ich arbeite seit nunmehr rund 1.5 Monaten an dem Programm. Bei meiner tatsächlichen täglichen Arbeitszeit kommt man vielleicht auf 2.5-3 Monate. Das würde also entweder bedeuten, dass ich ein überaus kongenialer Superprogrammierer wäre (oh yeah...!), oder -- vielleicht geringfügig realistischer -- mir das RAILS-Framework bislang rund 7-8 Monate Arbeit abgenommen hat.

Wenn man sich obige Zahlen genauer anschaut, fällt auf, dass für das gesamte app/views-Verzeichnis nicht ein SLOC gezählt wird -- OK, es handelt sich dabei hauptsächlich um HTML, aber hey -- das ist längst nicht alles a) autogeneriert und b) mit einem dubiosen WYSIWYWETG-Programm erstellt! ein [cat find app/views/ | wc -l ] ergab, dass es sich dabei um immerhin 6607 Zeilen handelt, wovon ich mal behaupte, mindestens 1800-2000 Zeilen selber geschrieben (OK, und Copy&Pasted :-)) zu haben. Da fällt eigentlich auch nicht mehr so sehr ins Gewicht, dass von den 1300 Zeilen unter test/ vielleicht nur 350 Zeilen von mir selbst stammen.

Interessehalber hab ich auch mal ein mittlerweile verabschiedetes Projekt von vor 1-3 Jahren (eine Vereins-Internetplattform in PHP) in sloccount gefüttert. Unter dem Strich kamen da fast runde 24'000 Zeilen Code, 67 Monate Entwicklungsaufwand und ca. 107'000 € Entwicklungskosten bei heraus (mit Jahresgehalt für Studi = schlappe 8'000 EUR gerechnet) -- Kann man sowas eigentlich als Spende von den Steuern absetzen? ;-) (interessanterweise wurde die Plattform innerhalb von rund 3.5 Jahren entwickelt -- 67 Monate entsprechen aber mehr als 5 Jahren ... also doch Superkräfte? :-D)

Was sagen hier die erfahrenen Entwickler von InnoQ zu? Wie schätzt ihr euren Aufwand ab? Sind diese Zahlen reine Fantasie? Der eine oder andere wie auch immer geartete Kommentar würde mich da schon interessieren.

Ich denke jeder kennt das: man sitzt vor dem Rechner, muss an irgend einer Software irgend etwas schreiben und man kommt einfach auf keinen grünen Zweig. man trinkt einen Kaffee nach dem anderen, scrollt sich durch den Quelltext, schaut sich das halbfertige Produkt im Browser an, sieht dass da Dinge nicht funktionieren, und ... kommt einfach trotzdem zu nichts.

Solche Tage habe ich üblicherweise 2-3 Mal pro Woche. An und für sich genommen denke ich, dass sie ein Zeichen sind, dass ich auch mal was anderes tun sollte, und wenn es nur ein anderes Nebenprojekt ist (abgesehen davon dass ich vielleicht auch viel zu viele, unwichtige, Nebenprojekte betreibe...). Üblicherweise aber -- egal wie wenig Schlaf ich hatte oder wie träge ich tagsüber war -- beginnt immer ab rund 0:00 Uhr eine hellwache, sehr konzentrierte Arbeitsphase. Es fällt mir schwer, nicht jeden Tag um 5:00 Uhr ins Bett zu gehen und erst um 14 Uhr wieder aufzustehen. Dann brauche ich auch üblicherweise 1-1.5 Stunden um vollständig aufzuwachen, aber die Produktivität Nachts macht das eigentlich wieder wett.

Gestern Nacht (also eigentlich heute Morgen) wurde ein lokaler Spitzenwert der Produktivität erreicht. Philipp und ich arbeiten gerade an einem sehr attraktiven Projekt, wo innerhalb einer Woche eine durchaus ansehnliche Webapplikation aus dem Boden gestampft werden musste. Heute war Deadline für eine brauchbare Beta, und somit war diese Nacht nicht ganz ohne Arbeitsdruck. Ich fasse zusammen, welche Eindrücke ich u.A. hieraus gewonnen habe:

• Ohne konkreten, kurzfristigen Termindruck läuft bei mir so gut wie nichts.
• Mit konkreten Vorgaben, wie das ganze am Ende auszusehen hat (das CI/Design stand schon) und was (und vorallem: was nicht) das Programm können soll, kann man sich auf die Funktionalität konzentrieren und wird nicht durch Einbinden von "Schnörkeleien" abgelenkt. OK, die wurden zwar trotzdem auch realisiert, aber ich merkte sehr deutlich wie ich nicht anfing herumzuspielen.
• Mit einem festen Stundensatz und einem strikten Bugdetlimit schränkt man das Spielen und Ausprobieren weiter ein
• Permanente Kommunikation mit dem Kunden und Mitentwickler über Skype steigert den Arbeitsdurchsatz enorm
• Der Einsatz von Subversion zur Datensynchronisation untereinander sowie zum deployment auf den Server ist eine Arbeitserleichterung wie ich sie selten erlebt habe (warum habe ich nicht schon vor einem Jahr SVN genutzt?!?). Einfach auf den Rechner auschecken wo man gerade arbeiten will, Änderungen vornehmen, Einchecken -- unverschämt einfach und hochproduktiv.
• (heute dazu gekommen:) Ein Bugtrackingprogramm (bei uns Mantis) senkt den Stress auf das Maß, wo die Arbeit am leichtesten fällt: Wenn alle Bugreports über Skype reinkommen, verliert man zu schnell den Überblick. Mit einem Bugtrackingprogramm kann man die Dinge erledigen sobald Zeit dafür da ist. Außerdem hat gegenseitiges Testen und Dokumentieren der Fehler etwas Kompetitives: man versucht möglichst seine eigenen Bugs zu beheben bevor der andere sie eintragen kann -- und umgekehrt natürlich! ;-)

Im Wesentlichen waren das meine Beobachtungen. Neben den projektbezogenen Sachen bich ich auch endlich dazu gekommen, einige Design-Entscheidungen, die ich für meine Diplomarbeit getroffen habe (Verzicht auf Single Table Inheritance bzw. Aggregation statt Vererbung, Vererbung statt Typ-Parameter -- in Rails eigentlich gleichbedeutend...) mal anders auszuprobieren. Einiges hat mir davon sehr gut gefallen, anderes bereue ich. Aber da es ein kleines Projekt ist (OK, es hätte auch locker für eine Diplomarbeit gereicht, aber den ganzen Schreibkram-Overhead haben wir hier jetzt nicht), kann man diese Fehlentscheidungen notfalls auch schnell umschmeißen (sprich refactorn :)).

Jedenfalls hat mir dieser kleine Projektexkurs ein paar gute Ideen und Praktiken für die Diplomarbeit gebracht und ich hoffe dass die Produktivität auch da weiter steigen wird.

Was außer dem was ich neulich schon einmal gepostet habe ist dem produktiven Coden zuträglich? Ein paar weitere Kleinigkeiten:

• Die Gewissheit, dass einem keiner Mails schreibt (Mailprogramm zumachen reicht nicht!). Für Telefonate gilt das gleiche.
• Raumtemperatur über 19°C (bei 18° sind meine Finger definitiv zu steif zum schnellen Tippen)
• eine große Kanne Tee (oder Kaffee...), bevorzugt mit irgend einer Warmhaltevorrichtung (wenn man nach zwei Stunden feststellt, dass das Getränk kalt ist, reißt einen das schnell aus dem Flow...)
• Irgendwelcher Knabberkram (Schokolade und Gummibärchen) in der obersten Schublade hilft über Denkpausen hinweg und sorgt für konstanten Zuckernachschub
• die passende Musik -- leider kann ich noch nicht sagen, welche Musik zu welcher Zeit mit welcher Art von Problemstellung am besten funktioniert. Ich weiß nur, dass Pianokonzerte das Tippen sehr gut begleiten. Aber Metal oder Electronic sind auch oft gute Begleiter. "Einfache" Popmusik, Blues oder Techno hingegen eher nicht. Sicher ist das vom persönlichen Musikgeschmack abhängig -- vielleicht komplizierte Musik bei komplizierten Problemen?
• Was mir beim Programmieren von Ruby auffällt ist, dass es sich schneller programmieren lässt als viele andere Sprachen, die mehr "Interpunktion" aufweisen: Dadurch, dass man im Wesentlichen ganze Wörter und nicht kryptisch abgekürzte Namen und Sonderzeichen eintippen muss, empfinde ich das "Tipp-Erlebnis" als fließender -- fast wie beim Schreiben eines normalen Textes.

Die restlichen, üblichen Ergonomieempfehlungen kann man jedem entsprechenden Standardwerk entnehmen, denke ich. Diese Punkte waren mir nur persönlich für mich aufgefallen...