Segeltour auf der Ostsee 2012

Nach unserer ersten Segeltour auf dem Ijsselmeer in 2011 sind wir auf den Geschmack gekommen und haben uns dieses Jahr auf ein „echtes Meer“ getraut – die Ostsee. In einer guten Wochen haben wir Heilighafen bis Wiesmar erkundet, Schweinswaale gesichtet und sind in verschiedenen Häfen eingelaufen. Auf dieser Tour sind verschiedene Foto’s entstanden, ein paar davon habe ich im Bereich der Fotoalben eingehangen – zu den Fotos.

Veröffentlicht unter Fotos | Kommentare deaktiviert für Segeltour auf der Ostsee 2012

Caol Ila 12 Jahre

Das schönste an der stürmischen Winterzeit ist wohl der perefkt passende Whisky zu den lauschigen Abenden. So habe ich das aktuelle Sturmtief genutzt und meine Whiskyliste bis auf ein paar Fassabfüllungen auf Stand zu bringen und ein paar Worte zu dem 12 jährigen Caol Ila verfasst.

Der 12 jährige Caol Ila

Veröffentlicht unter Whisky | Kommentare deaktiviert für Caol Ila 12 Jahre

BUILD FAILED – das exit() macht’s

In jedem gut sortierten Softwareprojekt kommt heutzutage wohl ein CI wie Hudson oder CruiseControl zum Einsatz. In meinem Fall setzen wir auf der Arbeit in „Projekt P“ CruiseControl mit der phpUnderControl Erweiterung ein und fahren damit ganz gut.

Weil wir mit dem System so gut fahren haben wir zwei Monitore für den stetigen Blick auf unsere Projektbuilds aufgestellt und da wäre es doch eine super Sache, eigene Funktionen zum Tests von verschiedenen Dingen zu erweitern – top.  Hätte ich vorher gewusst wie zahlreich die Stolpersteine auf dem Weg dahin sind hätte ich mir wohl was anderes überlegt, aber wenn man erst mal auf einer Strasse ist möchte man ja auch nicht umdrehen, nicht aufgeben, nicht abknicken, eben standhaft bleiben.

Relativ einfach bekommt man nach dem gleichen Verfahren wie CodeSniffer, PHPMD oder PHPUnit laufen eigene PHP-Skripte in den Buildprozess eingebunden – der folgende Eintrag in der build.xml zeigt dies.

[xml]





[/xml]

Bei jedem Buildvorgang arbeitet ANT die build.xml ab und mit meinem selbstgebauten PHP-Skript kann ich dabei die Welt erobern, ein BUILD failed auslösen gehört allerdings nicht dazu. Wusstest ihr, dass man dem PHP exit; einen Status übergeben kann? Ich will nicht lange um den heißen Brei reden, man kann exit; einen bzw. bis zu 254 Status übergeben und je nach Status gilt für ANT ein Build als successfull oder failed. Es hat mich einiges an Zeit und Nerven gekostet dies rauszubekommen aber nun kann man PHP-Skript wirklich die Welt erobern.

[php]
// build successfull
exit(0);

// build failed
exit(2);
[/php]

Veröffentlicht unter PHP, phpUnderControl, Softwareentwicklung | Kommentare deaktiviert für BUILD FAILED – das exit() macht’s

Dänemark 2011

Mittlerweile hat es Tradition, dass ich einmal im Jahr in Dänemark verweile. So war es auch dieses Jahr und die besten Bilder die in dieser Woche entstanden sind habe ich als Fotoalbum eingestellt.

Zum Fotoalbum Dänemark 2011

Veröffentlicht unter Fotos | Kommentare deaktiviert für Dänemark 2011

Segeltour auf dem Ijsselmeer

Im Juli 2011 wagten wir uns zu viert auf eine einwöchige Segeltour auf dem Ijsselmeer, wir gespickt mit unendlicher Segelkompetenz. Nach sieben Tag an Board bleiben wunderschöne Erinnerungen an eine schöne Ecke und abenteuerliche Tour – in paar Eindrücke habe ich in Bildform eingestellt.

Zu den Fotos

Veröffentlicht unter Fotos | Kommentare deaktiviert für Segeltour auf dem Ijsselmeer

Buchrezension: Bessere Software kompakt

Mit seinen rund 100 Seiten ist das Buch durchaus interessant, unter dem Buchtitel habe ich inhaltlich aber ganz anderes erwartet.  Grundsätzlich mag ich diese Buchserie, kurz und knapp werden Themen angerissen und man bekommt einfach neue Denkanstöße – so verhält es sich auch in diesem Buch.

Bei dem Thema „bessere Software“ habe ich Kapitel wie „Was ist bessere/schlechtere Software?“, an welchen Fakten kann man dies festmachen und wie kann man dies optimieren. Weiter vielleicht welche Klassen an Anwendern es gibt und welche Anforderungen diese an Software stellen, welche Rolle spielt die Art einer Softwareeinführung, Oberfläche, Nutzungsarten, … . Das Buch beschäftigt sich viel mehr mit dem Projektmanagement von Softwareprojekten, sprich was muss getan werden um gute Software zu entwickeln. Zum einen gibt es dazu bereits den Band „IT-Projektmanagement“ in der gleichen und würde sie hinter „Das bessere“ Auto ein Buch zum Auto oder zum Entwicklungsprozess des Autos erwarten?

Inhaltlich finde ich das Buch trotzdem sehr gut und konnte für mich ein paar Idee für den Arbeitsalltag entdecken, sowie unbewusst Bekanntes neu reflektieren.

Das Buch bei Amazon

Veröffentlicht unter Buchrezension | Kommentare deaktiviert für Buchrezension: Bessere Software kompakt

Ein Neuer im Team

Ein Neuer im TeamDie Idee zu einer Software beginnt oft mit relativ unspezifizierten Anforderungen, eine Ausgangsbasis die konkrete Planungen zu Zeit, Kosten und Ressourcen schwierig macht. Obwohl wahrscheinlich kein Hobbykoch den Kauf seiner neuen Ikeaküche ohne einen exakten Plan sämtlicher Schubladenknöpfe initiieren wird  beginnt die Entwicklung von neuer Software meist ohne jeglichen Plan und schlängelt sich weiter mit ausreichendem Plan dahin.

Ein nicht vorhandener guter Plan mag im Zeitalter der agilen Entwicklungsmodelle nicht mehr so tragisch wie unter dem großen V-Modell sein, trotzdem muss jedes Softwareprojekt bei allen agilen Analyseschleifen zu einem Zeitpunkt X die Anforderungen Y erfüllen. Die Frage nach „mehr Ressourcen“ scheint da vorprogrammiert nur eine Frage des Wann’s zu sein und musste jüngst wieder von uns beantwortet werden.

Das die Montierung von Reifen fünf und sechs an einem Auto nicht zu einer Geschwindigkeitssteigerung von 50% führen wird scheint klar, ebenso der mangelnde Platz für die zusätzlichen Reifen oder Unsinn einer unorthodoxe Positionierung auf dem Dach – aber an was soll man bei einem „Neuen“ im Entwicklerteam denken? Folgend sollen zwei Punkte mit unseren Erfahrungen reflektiert werden.

Einarbeitungsaufwand

Mit steigender Projektkomplexität muss mit einem gewissen Einarbeitungsaufwand für einen neuen Entwickler gerechnet werden, aber wie hoch ist dieser?

  • 40h gingen auf Einrichtung von Entwicklungsumgebung – Einführung in die örtlichen Gegebenheiten zu Dokumentation, Patching, Entwicklungsprozess, Aufgabenbearbeitung – Erklärung von Terminologie und dem funktionellen Inhalt der Software. Den Zeitaufwand halte ich für nicht minimier bar, da gute Ergebnisse nur mit fundiertem Basiswissen möglich sind.
  • 36h gehen zu lasten der Einarbeitung in die vorhandene Programmierwelt oder anders gesagt, ein routinierter Entwickler hätte in den ersten vier Arbeitswochen die gleichen Ergebnisse mit 36h Programmierstunden weniger geleistet.
  • 80h gehen in die Betreuung der ersten Entwicklungsarbeiten. In unserem Fall war es unablässig, dass in den ersten vier Einarbeitsungswochen für alle Aufgaben ein zweiter Entwickler mit Rat, Tat und Zeit zur Seite stand.

Nach dieser Rechnung gilt es nach einer Einarbeitungsphase 160h Arbeitsstunden einzuholen, diese würden sich meiner Meinung nach ca. 2-3 Monaten zeitlich einspielen.

Koordinierung der Entwicklungsarbeit

Ist die Phase der Einarbeitung abgeschlossen gilt es die zusätzliche Entwicklungskapazität möglichst zielorientiert zu koordinieren. Relativ pragmatisch lässt sich aus der Verteilung unserer Arbeitsstunden ermitteln, dass gut 25% Vorbereitungszeit zu der Entwicklungsarbeit dazu kommen- sprich für 20h Entwicklungsstunden sind organisatorische 5h zu leisten.  Auf vier Entwickler kommt nach dieser Annahme zusätzlich eine volle Arbeitsstelle für die organisatorischen Aufgaben,  dies muss bedacht und passend verteilt werden.

Fazit

Mehrwert und Handelbarkeit von einem „Neuen“ im Entwicklungsteams sind im Vorfeld schwer abzuwiegen. Die angeführten Eckwerte halte ich in dieser Form aber für sehr interessant und warte auf die Möglichkeit diese weiter zu belegen und auszubauen. So oder so, einen fünften Reifen werde ich mir zumindest in den Kofferraum legen und schauen was mein Dach hergibt.

Veröffentlicht unter Softwareentwicklung | Kommentare deaktiviert für Ein Neuer im Team

Warfleth bei Ebbe

Warfleth bei EbbeWenn man in Norddeutschland aufgewachsen ist sind Ebbe und Flut etwas selbstverständliches,  wir bemerken kaum wie tief der Wasserstand sinkt um kurz danach wieder zu steigen.  An einem nebeligen Tag hab ich ein paar heimische Vögel vor die Linse bekommen, die die unendlichen Weiten der Ebbe für Erkundungen nutzen.

Zu den Fotos

Veröffentlicht unter Fotos | 1 Kommentar

Gin, ein Whisky für Ungeduldige

Gin, ein Whisky für UngeduldigeLetzten Samstag konnte ich unerwartet in einer urigen „Eckkneipe“ Gin verkosten. Eins vorweg – meine uneingeschränkte Leidenschaft gebührt dem Whisky, an dieser Tatsache kann ein aromatisierter Agraalkohol mit Nichten etwas ändern.
Offen für Überraschungen habe ich zwei verschiedene Ginsorten pur und danach als Gin-Tonic probiert, im Ergebnis eine klar positive Überraschung. Ketzerisch könnte ich nun auf die primitive Art der Geschmacksanreicherung durch Aromatisierung anspielen. Fehlt den Engländer n gegenüber den Schotten die nötige Ruhe Geschmacksnoten durch einen längeren Reifeprozess entstehen zulassen, können wir bei Gin von einem Whisky für Ungeduldige sprechen? Diese Ungeduld zeigt sich bereits während des Herstellungsprozesses. Ein Gin wird schlicht gebrannt, ein Vorgang den wahrscheinlich jeder in seinen Endschuljahren im Chemieunterricht durchgeführt hat und der damit nicht von ausgeklügelter Komplexität zeugt. Die Herstellung von Whisky ist um Faktor drei anspruchsvoller, hier kommen wir vom Mälzen über das Gären zum Destillieren.
Ich wollte hier jedoch keine Bloßstellung des Gin’s gegenüber dem Whisky vollziehen, eingangs sprach ich von meiner Begeisterung. Ignorieren bzw. Akzeptieren wir die Aromatisierung des Gin’s ergibt sich eine fast unendlich Geschmacksvielfältigkeit, vor allem in der sehr erfrischenden Form des Gin-Tonic habe ich diesen putzigen Engländer für mich entdeckt

Veröffentlicht unter Whisky | Kommentare deaktiviert für Gin, ein Whisky für Ungeduldige

Softwareentwicklung ist komplizierter als Fußball

Softwareentwicklung ist komplizierter als FußballIhr habt schon mal an einem Softwareprojekt mitgearbeitet? Scheinbar gehört zu jedem guten Softwareprojekt die ungesunde Arbeitsmenge im Verhältnis zu Ressourcen und Projektziel ebenso wie ein Elfmeter zum Fußball. Schlimmer, ein stetiges Rumgerangel und Ärger auf dem Feld weisen direkte Parallelen zu Konflikten bei Anforderungsanalayse gepaart mit Komplikationen im Projektumfeld auf.

Albern, was soll so ein Vergleich? Ich glaube bei der Softwareentwicklung müssen wir über den Teller schauen und in allen Gefilden prüfen, ob wir nicht aus „ähnlichen“ Problemen lernen können. Fußball hat einen großen Vorteil gegenüber der Softwareentwicklung. Es gibt eine schier unendliche Menge an Hobbytrainern die dem Spielverlauf folgen können und viele sinnige, mäßige bis schwachsinnige Optimierungsideen für das Spiel haben. Für Softwareprojekt gilt dies leider nicht, selbst für direkte Beteiligte des Projektes ist die Erfassung des Projektumfeldes schwierig – Software ist physisch nicht greifbar, Probleme damit nicht klar sichtbar. Veränderungen am Projektgeschehen lassen sich wenn überhaupt nur sehr langfristig in Zahlen fassen. In Softwareprojekten können wir einen ambitionierten Stürmer nicht für eine Woche in der Verteidigung auflaufen lassen, maschinennahe Programmierung ausführen lassen und die Woche drauf für die GUI Optimierung tüfteln lassen – oder?

Da bleiben folgende Thesen:

  • Profispieler haben jeden Tag Training, ich hätte gedacht die könnten schon spielen? Tatsächlich wird wohl vielmehr das Zusammenspiel, als das individuelle Können geübt. Programmieren können hoffentlich alle Beteiligten an einem Softwareprojekt – Ausnahmen bestätigen die Regel – aber die Zusammenarbeit zwischen den Programmieren, dass Passen, hier bedarf es Mechanismen zur kontinuierlichen Steigerung. Weiter müssen Schwachstellen erkannt werden, auf dem Feld sieht jeder sofort einen Fehlpass und wie steht das bei der Softwareentwicklung? Schwieriger, merkt ihr selber oder?
  • Positionswechsel, ein guter Trainer weiß wo seine Spieler optimal per formen und wo nicht. Jeder Entwickler wird gute und schlechte Tage haben, unterm Strich bleiben trotzdem Bereiche die einem mehr oder weniger liegen. Theoretisch direkt übertragbar auf ein Entwicklungsteam, nur leider sieht man hier einen Topscorer an der Datenbank nicht so klar wie einen Helden im Luftraum. An welchen Tatsachen erkennen ich die Stärken eines Entwicklers?
  • Als dritte These habe ich mir die spannendste aufgehoben. Das Ziel eines Fußballspieles ist „das Runde muss ins Eckige“, super das wusste schon Beckenbauer. Ich kann in fünf Worten das Ziel von Fußball ausdrücken, versucht das mal für eurer Softwareprojekt und ihr werdet kläglich scheitern.

Super, mit dieser bitteren Erkenntnis und der Gehaltstabelle unserer Fußballhelden habe ich morgen einen Termin beim Chef … ich bin gespannt wie er gegen eine Anpassung meines Gehaltes an das von Ribery argumentiert – immerhin ist meine Aufgabe komplizierter und zusätzlich ist Fußball nur ein Spiel, mein Job ist bitterer ernst

Veröffentlicht unter Softwareentwicklung | 2 Kommentare