Grundsätzlich bietet Intuition eine Art Abkürzung für die Arbeit eines Softwareentwicklers und kann wesentlich schneller zum Erfolg führen. Das bedeutet, dass man während man sich Schritt für Schritt vom Fehlerbild zur Fehlerquelle durcharbeitet, gern diese Abkürzungen in Anspruch nehmen sollte. Allerdings muss klar sein, dass diese A) ins Nirvana führen können und man damit wieder zurück muss und B) der logische Pfad der Fehlersuche der führende sein muss.

Bei Entwicklern habe ich erlebt, dass diese von einer Abkürzung zur nächsten kamen und damit ohne logischen Leitfaden durch den Code der Applikation mäanderten. Das das fatal und nicht zielführend ist, versteht sich. Richtig eingesetzte Intuition sieht so aus, dass man entlang des logischen Pfades spontane Eingebungen zu Fehlerquellen validiert (!) und bei Miserfolg direkt wieder auf den logischen Pfad springt. Dabei sollte man natürlich nicht jeder Eingebung folgen. Die Validierung dieser ist maßgeblich, da jeder Versuch Zeit kostet und grundsätzlich erstmal ein Schuss ins Blaue ist.

Nicht zu unterschätzen ist, die emotionale Wirkung des Einsatzes von Emotion. Aus eigener Erfahrung weiss ich, dass beim Debugging ständig neue Vermutungen über die Ursache des Fehlers entstehen. Wenn man jeder von dieser folgt, entsteht schnell der Eindruck, dass die Software total unberechenbar (aka crap) ist und sich schwer debuggen lässt. Das frustriert und hat mich nie weiter gebracht.

Weitere Infos, wie Intuition funktioniert finden sich bei Coding Horror.DE. Weiterhin lesbar ist dieser Beitrag über Intuition im Team. Eine allgemeine Übersicht über Intuition hab ich noch in folgendem PDF gefunden.

» maximale Zeilenbreite: 80

» maximale Anzahl Zeilen: zwischen 120 und 2000

» CodeInhalte: saubere Trennung nach MVC bzw. Pattern, nur gültigen Code

» Kommentare: Feste Syntax, Block Komments, 1-6x Umfang des kommentierten Quelltextes

» Struktur: optisch durch Kommentare kennzeichnen

» Dateikopf: Inhalt, Datum, Ersteller/Brarbeiter

» Funktionskopf: Inhalt, Parameter inkl. Beschreibung, Documentor Standards nutzen, Rückgabewerte dokumentieren

» Intendation: maximal 5 Schritte

» Klammern: korrekt intendiert, keine eigene Zeile vs. eigene Zeile

» Leerzeilen: kennzeichnen zusammengehörige Strukturen, einheitliche Verwendung!

» Methodenlänge: <40 bis < 80 Zeilen

» Naming Conventions inkl. Kommentare: einheitlich, nach Projektstandard

» Charset: UTF8

» Tabs/Spaces: Spaces bevorzugt, aber immer einheitlich

» Definition, Deklaration: getrennt, einzeilig wenn identisch

» Code Strukturen (optisch erkennbare Muster): zusammenfassen, wenn identisch oder gleichartig formatieren

Spannende Diskussionen gab es bei zwei Punkten: zum einen stand die Hypothese im Raum, dass wenn immer man innerhalb einer Funktion eine Leerzeile einfügen will, man lieber direkt eine neue Funktion für den folgenden Code schreiben sollte. Darüber hinaus kam das alte Thema Spaces vs. Tabs auf.

Im Zuge des Workshops habe ich ein paar Fragen an die Anwesenden gestellt und war überrascht, dass über 80% der Anwesenden schon umfangreiche Programmiererfahrungen, z.T. auch in grösseren Teams, hatten und dass ca. 50% aller Studenten in ihrem Arbeitsumfeld direkte Coding Guidelines definiert haben. Mein Eindruck nach den verschiedensten Diskussionen mit den Studenten hinterlässt dabei den Eindruck, dass die Mehrzahl der Anwesenden in der Summe einen überdurchschnittlich guten Code schreiben dürfte. Was entweder an der Auswahl der Teilnehmenden oder der Ausbildung der HTW Dresden liegt. Hier darf man spekulieren .

Weiterführende Links zum Thema Code Design liefer ich morgen in einem extra Artikel kurz nach.

Insgesamt war der Workshop optimierungsfähig. Die einzelnen Gruppen mit Vorschlägen zum Thema Code Design hatten zu viel Redezeit, so dass sich sicherleich diverse Anwesende schnell langweilten. Andererseite war die Beteiligung deutlich über meinen Erwartungen, so dass die Gruppengrösse tiefere Diskussionen (ich wäre gern auf bestimmte Details näher eingegangen) verhindert. Fazit: Es bringt nichts, wenn die Hälfte der Leute sich nach 1,5 Stunden langweilt und man dennoch zu flach auf der Oberfläche der Themen kratzt. Hier werde ich mir also zur nächsten Veranstaltung etwas einfallen lassen.

Die Folien finden sich hier zum Download: 11-2009 Allgmeine Praesentation TTS HTW – Neue Werkzeuge.pdf

Das Fazit: die Präsentation kam sehr gut an. Habe ein nettes Kompliment von einer anwesenden Professorin zum Vortrag erhalten . Darüber hinaus geb es ne Menge Fragen und ich musste nach 50% Inhalten und 75% Zeit den Turbo einschalten. Alles in allem hoffe ich, dass es die Erwartungen erfüllt hat und einen Einblick in aktuelle Trends und die Arbeitsweise von Tschitschereengreen vermittelt hat.

Die vielfältigen Fragen waren sehr spannend und wären es sicher wert tiefere Diskussionen hierzu zu führen. Hier ein paar Beispiele:
* In der sich so schnell verändernden Welt der Webtechnologien: welche Rolle wird Java hier zukünftig spielen? Vor allem jetzt wo Google, das im den Web Toolkits verwendet, wird es da einen neuen Aufschwung geben?
* Was bedeutet diese schnelle Veränderung für die Lehre? Was ist wenn, die heute vermittelte Inhalte in 3-4 Jahren, wenn die Studenten fertig sind, nicht mehr relevant sind? (Grossartige Frage eines Professors/Professorin)
* Wie passen die aktuellen Web-Sprachen mit Java-Enterprise-Applikationen zusammen?
* Was passiert, wenn in Ihrem Unternehmen ein Entwickler ausfällt?
* etc… spannend, spannend die Themen

Zum Abschluss habe ich noch wie versprochen, zwei Veranstaltungen vorgestellt, welche wir weiterführend umsetzen könnten. Das Interesse war vor allem für das Seminar: Code Esthetics am grössten. Die erste Veranstaltung wird daher am 3.12.2009 um 17.00 stattfinden und je nach Bedarf aller 2 Wochen wiederholt.

Unsere Zusammenarbeit sah in etwa so aus: er zeigte mir ein Stück Code und erklärte mir was es tat. Dann stellte ich Fragen zum Verständnis und liess mir die erwartete Funktionsweise erklären. Anschliessend prüften wir gemeinsam, ob der Code wirklich zu 100% ausführte, was wir erwarteten. Das ganze wiederholte sich 4-5 Mal, während sich folgendes abspielte.

Mein Mitarbeiter zeigte mir den Code, erklärte mir die Funktionsweise und hatte einen Aha-Effekt. Er brach mitten im Satz ab und Zitat: “Ich habs! Wart!” – woraufhin er sofort in eine andere Datei springen wollte… Ich stoppte Ihn lies mir seine Gedanken erklären. Hierbei äusserte er seine Vermutung (jedes mal eine andere), welche sich nach meiner Auffassung nicht direkt kausal aus dem eben betrachteten Code herleiten liess. Daher bestand ich darauf, dass wir erstmal die korrekte Funktionsweise von ebendiesen diskutieren. Dabei prüften wir eine Funktion, erhielten daraus logische Hinweise auf die Fehlerquelle in einer anderen Funktion. Prüften diese erneut und sprangen zur nächsten Funktion. Am Ende konnten wir damit den Fehler an einer anderen, ganz unerwarteten Stelle nachweisen.

Im Nachgang daran habe ich mir gestern und heute ziemlich viel den Kopf verzbrochen, was da eigentlich passiert ist und was wir daraus für die Zukunft lernen können. Folgende Fragen stellen sich mir dabei: was lernen wir daraus? Können wir das in unserem Entwicklungsbetrieb nutzen? Welche Vorteile lassen sich dadurch erzielen? Meine Gedanken hierzu werde ich in den nächsten Tagen hier niederschreiben.