About

This page contains a single entry from the blog posted on November 12, 2007 1:56 PM.

The previous post in this blog was ActiveRecord::BaseWithoutTable.

The next post in this blog is Rails Helper v0.2.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.31

« ActiveRecord::BaseWithoutTable | Main | Rails Helper v0.2 »

Wenn die Arbeit fließt

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.

TrackBack

TrackBack URL for this entry:
http://www.innoq.com/movabletype/mt-tb.cgi/2875

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)