@leo's

Und weiter...

...gehts hier. Ich musste diesen Eintrag aufspliten da sonst mein Schlafmanagement durcheinander gekommen währe (und das soll vor Prüfungen nicht so toll sein). Der erste Teil meiner Zusammenfassung zum Fortbildungsseminar 'Pragmatic Programming - Overview!' habe ich noch am Dienstag-Abend geschrieben, hier folgt nun der zweite Teil.

Infrastucture

Den Teil Infrastructure teilte Andy Hunt wieder in drei Kapitel ein, nämlich "Use version Controlling", "Unit Testing". Für die Anwesenden wahr Version Controlling kein Fremdwort, leider scheint diese Praxis in der Industrie immr noch keine vollständige Verbreitung zu finden. Das wirklich alles ins VC-System gehört geht oft vergessen, oft gibt es kleine Scripts (für den Build, die Installation) die so plötzlich verlohren gehen und kein Mensch weiss danach mehr wie man diesen Arbeitsschritt wieder automatisieren kann.

Unit Testing war dann bei weitem nicht so verbreitet. Oft wird der Aufwand für das schreiben des Tests gescheut. Andy Hunt fand jedoch das die Disziplin beim Unit Testing den Code einfacher macht und das Design verbessert.

"Automate everything" löste dann einiges stauenen aus. Jede Stunde eine lauffähige neue Version auf CD gepresst und beschrifftet und das Resultat des Unittests auf einer Lava Lampe ist cool wie nichts. Bei unserem letztem Projekt waren wir aber mit der Hilfe von CruiseControll beinahe schon auf diesem Stand und desshalb erstaunte mich diese Kapitel nicht so sehr wie andere.

Team Practices

Die Kommunikation ist eines der wohl am meisten unterschätzten Themen im Software Engeneering. Die Kommunikation sollte ehrlich und verlustfrei sein, sowie möglichst effizient sein. Dabei brachte er auch das Beispiel das man mal den Kopf ins andere Büro stecken soll anstelle ein eMail zu schreiben. Etwas was ich persönlich feststelle immer wieder nützlich ist. Oft erreicht man durch einen kurzen Fussmarsch ins nächste Büro viel mehr als durch ein eMail ping-pong, gleichzeitig tut man etwas für seine Gesundheit und lernt sich automatisch besser kennen.

Schnelle und effiziente Kommunikation kann man laut Andy Hunt durch folgendes erreichen:

• Gespräche, keine Memos
• Klarheit, nicht Erklährung
• Wikis, keine Dokumentreviewsitzungen
• Standup meetings, nicht Status-Memos

Auf das Standup Meeting ging er dann noch ein bischen weiter ein. Beim Standupmeeting stehen (es ist wichtig das sie stehen, wer nicht sitzt macht automatisch schneller) alle in einem Kreis. Jeder beantwortet drei Fragen:

• Was habe ich gestern erfüllt?
• Was planne ich heute zu machen?
• Was steht in meinem Weg diese zu tuen?

Diese drei Fragen, sonst nichts! Nach dem Meeting kann man an diese Punkte sofern nötig anknüpfen.

Zur Organisation meinte er das man das Team wie den Code organisieren soll (und nicht etwa umgekehrt), keine unnötige Zwischenebenen einschieben soll und den Fokus auf die Kommunikation legen soll.  Intressant war auch  die Geschichte von den Entwickler die in einer Reihe an der Fensterfront arbeiteten. Der Äusserste auf einer Seite erklährte das dass Team einen grossen Server mit einem Thin Client implementiert, jeweiter man nun auf die andere Seite der Tische ging wurde der Server immer einfacher und der Client immer Dicker. Bis am anderen Ende der Tischreihe der Entwickler erklährte das dass Team einen Fat Client mit einem einfachen DB-Server entwickle!

Anforderungen wechseln sich immer. Auch wenn die Anforderungsspezifikation säuberst erarbeitet sind, haben sie pro Monat eine Änderung von gut zwei Prozent. Desshalb ist ein gutes Ausfragen des Kunden (aus meiner Erfahrung: Der Kunde weiss nie was er will) und ein gut änderbares Entwicklungsmodel unumgänglich.

Durch kürzere Iterationen erreicht man besseres Feedback, keine lange nicht gefixte Bugs (Broken-Windows),  kann entscheidungen verschieben, vereinfacht die Kommunikation und man lernt dauernd. Das mit dem Feedback und der vereinfachten Kommunikation wird wohl am besten durch das Beispiel unterstützt in welchem eine Firma ein POS-System entwickelt und erst merkt das die Benutzer sich (Aufgrund von Analphabetismus!)  nicht einmal einloggen können!

Kurze Iterationen fördern also vorallem schnelles Feedback und dauerndes Lernen!

Zum Schluss

Wie schon mal erwähnt, der Vortrag bot wenig neues (für uns Studenten welche pragmatisches Programmieren durch Mister Sommerlad schon bald ein Jahr eingetrichtert bekommen). Vorgetragen waren das ganze aber genial und mit vielen Praxisbeispielen untermauert. Schlussendlich ist es wohl auch wichtig das man all diese Punkte immer wieder aufgedrückt bekommt.

Was ich aus dem Vortrag mitnehme ist das das Wichtigste in Software Projekten (und wohl auch allen anderen) dauerndes Lernen und gutes Kommunizieren ist.

Heute Abend hat Andy Hunt bevor er an die Software Trends in Gersau reist auf Einladung des Institut für Software und der Weiterbildungsstelle noch einen kleinen Abstecher an unsere Schule gemacht.

Wirklich überaschend war die Präsentation nicht, pragmatisches Programmieren gehört heute ja zum Stoffplan einer moderen Hochschule. Denn noch sollte eine regelmässige Portion Pragmatik Pflicht für jeden Programmierer sein. Andy Hunt hat in 90 Minuten die präzis die wichtigsten Punkte angeschnitten.

Nach einer kurzen Einleitung in dem er nochmals auf die grässlichen Zustand von Softwareprojekten einging und einige Zahlen dazu prässentierte. Die Zahlen hatten allerdings keine Quelle und irgendwie war das für mich alles ein wenig aus der Luft gegriffen, im grundsatzt aber sicher richtig. Ging er dann auf die Themen "Personal Practices", "Design Practices", "Team Practices" und "Infrastructure" ein.

Personal Practices

Bei den "Personal Practices"  ging er zuerst auf die Wichtigkeit des Lernen ein. Wöchentlich sollte jeder 2 Stunden in die persönliche Weiterbildung stecken um sein Knowledge Profil zu erweitern. Schlussendlich fand ich auch noch wichtig das er dabei betonte das man klar diversifizieren sollte, eventuell kommt die Technik auf die man hofft dann doch nicht so wie man damit rechnet.

Die Wichtigkeit der Wachsamkeit beim Programmieren erklärte er am Beispiel eines Frosches. Hält man einen Frosch ins heisse Wasser springt er sofort wieder raus, gibt man hingegen in kaltes Wasser und dreht die Temperatur langsam auf wird er ohne es zu merken kochen. Sicher waren wird schon alle mal in der Situation wo wir das warm werden des Wassers erst merkten als es schon (fast) kochte. Um klippen zu erkennen hilft natürlich aktives und unmittelbares Feedback, haben wir das nicht kann es uns wie der Lady gehen die mit dem Messer im Nacken eine Shopping-Tour sellenruhig zu Ende führt. Darum sollte man sich nach Andys Empfehlung beim Programmieren etwa alle 2 Stunden selber fragen. "Warum mache ich das?", "Muss ich das so machen?" und "Muss man das überhaupt machen?". Dabei immer an den Frosch denken und überprüfen ob sich das Wasser nicht erhitzt.

Unter dem Titel "Fix Broken Windows" erklährte er dann die Wichtigkeit eine eingeschlagene Scheibe ebenso wie einen Bug sofort zu reparieren. Und wenn man es nicht reparieren kann sollte man es wenigstens markieren. Das das mit dem später nicht ganz einfach ist steht gross auf einer Folie: "There is no later...". Das Design soll durch Refactoring angepasst werden. Man sollte sich dabei nicht so stark auf die Pläne festschreiben wie beim Hausbau, sondern es eher wie beim Garten planen handhaben oder eben: "Keep software soft!"

Design Practices

"Design Pratices" bot dann relativ wenig neues, das meiste hatten wir in den Software Engineering Fächern bereits. Als wohl oberstes Gebot legten wir mit DRY (Don't reapeat yourself) los und Andy stellte fest das dass kopieren von Code mit dem kopieren von Fehlern gleichgesetzt werden kann. Die Magic Numbers sind heute vielfach Magic Strings gewichen. Weiter gings mit Coupling und High Cohesion, was wenig Überaschungen bot.

Weiter...

Gehts ein anderes mal, ich wollte diesen Teil aber jetzt erst mal veröffentlichen damit wenigstens scho was online ist.