@leo's

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.