Zwischenmahlzeit: Kurzvorträge zum Mittag in Karlsruhe, freier Eintritt

Wer mag sich zwischendurch inspirieren lassen? Das ist nämlich am Donnerstag 10. Juni 2010 in Karlsruhe möglich. Leicht verdaubare Happen für den Entwicklergeist statt Suppenkoma bieten nämlich acht Abschlussvorträge eines Rhetoriktrainings.

Von 13:00 Uhr bis ca. 14:30/15:00 Uhr halten die Absolventen des Trainings 10-15 minütige Kurzvorträge in der Albert-Nestler-Str. 10 im Raum Paris des Technologiezentrums bei der andrena objects ag. Hier ein Auszug aus der Themenliste:

• Umstieg von .NET 3.5 auf .NET 4.0
• Deliberation und Gruppenentscheidungen
• Scrum
• eclipse BIRT
• Einblick in die Sprache R

Der Eintritt ist natürlich frei. Die Teilnehmer, meine Trainer-Kollegin Renate Klein und ich freuen uns über jeden, der seine (verlängerte) Mittagspause bei ein wenig geistiger Anregung mit uns verbringt. Es gibt Spannendes zu hören. Und die Teilnehmer profitieren vom unvoreingenommenen Feedback eines größeren Publikums.

Also, wie wärs?

Intensiv, im Team, kostenlos – Das Clean Code Developer Praktikum

  Clean Code Developer (CCD) werden, hat weniger mit Technologien zu tun, als vielmehr mit Gewohnheiten und Konzepten. CCD-Tugenden zu vermitteln stellt daher besondere Anforderungen an Trainer. Wie stellen die dann sicher, dass sie sie erfüllen?

Stefan Lieser und ich haben in den letzten 14 Monaten einige CCD-Trainings durchgeführt und fühlen uns durchaus wohl mit den Ergebnissen. Aber wir hätten die CCD-Initiative ja nicht begründet und auch noch die Reflexion auf den Werte-Schild gehoben, wenn wir selbst nicht danach leben wollten und würden.

Deshalb finden wir es an der Zeit, über unsere Trainings zu reflektieren. Das Feedback aus den bisherigen Trainings haben wir analysiert; daraus konnten wir wertvolle Hinweise ableiten. Aber einige Aspekte lassen sich schwer mit Fragebögen erheben. Wir meinen, dass sich Konzepte, Vorgehensweisen und Didaktik nochmal ganz anders analysieren und reflektieren lassen, wenn sie ganz bewusst von Anfang an Thema sind, wenn sozusagen ein Training in einer “Meta-Atmosphäre” stattfindet.

Für ein solches Training, bei dem wir nicht nur etwas weitergeben, sondern selbst viel lernen wollen, können wir ja aber natürlich kein Geld verlangen. Es wäre auch kein normales Training, sondern eher… tja, was denn? Wir haben es mal Praktikum genannt.

Der Deal

Im Juli bieten Stefan Lieser und ich ein Praktikum an, in dem wir 5 Tage mit 5 “Praktikanten” 1 Projekt nach CCD-Manier durcharbeiten wollen.

Dieses CCD-Praktikum ist kostenlos für die Teilnehmer.

Wir bringen unsere CCD-Erfahrung ein. Die Teilnehmer sollen also etwas lernen. Aber wir wollen das – wie gesagt – auf einem anderen Niveau als in einem üblichen CCD-Training tun. Statt in kleinen Schritten Inhalte zu vermitteln, wollen wir in großen Sprüngen voran. Wir wollen mehr anwenden, als erklären. Denn nur dann kommen wir wirklich weiter bei einigen CCD-Bausteinen.

Die Teilnehmer müssen daher schon ein gewisses Erfahrungsniveau in Bezug auf CCD und .NET-Entwicklung haben. Deshalb erlauben wir uns, ein Auswahlverfahren vorzuschalten. Interessierte bewerben sich durch Lösung von zwei Aufgaben.

Keine Angst, das sind keine schlimmen Aufgaben. Wer es ernst meint mit CCD, wird sie leicht lösen können. Hier ein Beispiel für eine Einreichung zu Aufgabe 1 von Steven Weiß.

Also, wie wär´s? Wer hat Lust und macht mit? Es gibt was zu lernen, es gibt was zu schaffen – und es gibt die Möglichkeit, uns mal so richtig die Meinung zu sagen ;-)

Hier mehr Infos zur Termin und Ort sowie Hinweise zur Bewerbung auf der Seite des Professional Developer College.

Wie sind sehr gespannt auf eure Beiträge!

Coding Dojo Muc Retrospektive

Softwareentwicklung mit Energie – die war wieder mal zu sehen beim Coding Dojo in München. Knapp 30 Entwickler waren zusammengekommen, um sich in geselliger Runde in der .NET Programmierung anhand einer Aufgabe zu üben.

Das Coding Dojo Muc hat sein Format und seinen Rhythmus. Im Fokus steht gewöhnlich die testgetriebene Entwicklung (TDD) einer Funktionalität, die sich mit einer Funktion als API ausdrücken lässt  (Beispiele: FizzBuzz, LOC Counter). Das Motto: Alles denkt, einer tippt.

Doch dieses Mal war vieles anders…

Der Ablauf

Dieses Mal hatte Ilker mich eingeladen, um in das Dojo ein wenig architektonisches Denken hineinzutragen. Das Motto: Alles denkt, keiner tippt ;-) Zumindest nicht die ersten zwei Stunden.

Die Frage nun: hat das geklappt?

Die Aufgabe

Um architektonisches Denken zu üben, musste die Aufgabe natürlich etwas größer ausfallen als Dojo-gewöhnlich. Auf der anderen Seite durfte sie nicht zu groß sein, denn ich wollte ja auch mit Ergebnis mit den Teilnehmern erzielen.

Angemessen erschien mir schließlich eine Spellchecker-Anwendung: Das Programm sollte Texte in verschiedenen Sprachen auf Rechtschreibfehler überprüfen. Wenn man so ein Programm aufsetzen will, sind mehr als eine architektonisch relevante Funktionseinheit nötig; Architektur lohnt sich also.

Der Umfang dieser Aufgabe führte dann gleich zu einer ersten Neuerung bei Dojo: der Anforderungsanalyse. Nicht, dass bisher die Teilnehmer nicht versucht hätten, die Aufgaben zu verstehen. Aber so ein Programm machte eine systematischere Herangehensweise nötig. Die bestand aus zwei Schritten:

1. Featureliste

Im ersten Schritt haben wir die Anforderungen mündlich ventiliert. Da kamen einige Fragen an den “Kunden” zusammen. Und der Kunde blieb keine Antwort, keinen Wunsch schuldig – allerdings konnte nicht alles wirklich in das Backlog übernommen werden. Wir hatten ja nur einen Abend für die Realisierung zur Verfügung. Nichtsdestotrotz war die Diskussion wichtig, um die Gruppe auf das Thema einzuschwingen.

Was am Ende dann realisierbar erschien, haben wir in eine Featureliste übertragen. Wichtig dabei: Nur aus Kundensicht Relevantes ging darin ein.

2. Ubiquitous Language

Die Featureliste hat den generellen Scope der Entwicklung abgesteckt. Sie hat eine Grenze gezogen. Wie sah aber das Terrain innerhalb dieser Grenze aus? Wie sollten Problem und Lösung zusammenfinden?

Um einen Übergang in die Lösungswelt zu finden, haben wir im zweiten Schritt für die Features eine Ubiquitous Language mittels einer Concept Map erarbeitet.

Darin wurden die zentralen Begriffe der Domäne nicht nur gelistet, sondern auch qualifiziert in Beziehung gesetzt. Interessante Erkenntnisse wurden dadurch herausgearbeitet:

1. Um sich unzweideutig über die Domäne unterhalten zu können, ist zwischen Prüfworten und Fehlerworten zu unterscheiden. Prüfworte sind die, die auf Korrektheit geprüft werden müssen; Fehlerworte sind die, die als Inkorrekt erkannt wurden.

Fehlt die Unterscheidung, wird die Rede über die Domäne im besten Fall mühsam, im schlimmsten Fall jedoch Missverständlich.

2. Nachdem das Flipchart schon fast voll war, stellte sich die Frage, wer denn überhaupt die Rechtschreibprüfung vornehmen würde. Ihre Elemente (z.B. Prüfworte, Wörterbuch) waren vorhanden, es fehlte aber eine Instanz, die damit umging.

Diese Instanz war in der Diskussion immer implizit vorhanden. Das Team hatte sich oder das ganze Programm dafür in der Verantwortung gesehen. Das ist aber natürlich ungenügend, weil trivial bzw. impraktikabel. Es gilt vielmehr: Zentrale Domänenaufgaben müssen als “Bubbles” in einer Concept Map der Ubiquitous Language auftauchen.

Und so wurde spät aber doch der Prüfer als Vokabel in die Ubiquitous Language aufgenommen. Er prüft, ob ein Wort im Wörterbuch und damit korrekt oder als Fehlerwort zu melden ist.

Die Architektur

Nach soviel Vorgeplänkel waren die Teilnehmer natürlich gespannt darauf, wie denn aus den Anforderungen eine Architektur entstehen würde.

Einige wollten mit Klassendiagrammen anfangen. Andere wollten Schichten übereinander malen. Doch ich hatte mich entschieden, eine Architektur “nach der neuesten Mode” zu versuchen. Event-Based Components (EBC) sollten es sein.

Da keine Zeit für lange Erklärungen des Konzepts sein würde, fand ich mich mit dem EBC-Ansatz recht mutig. Aber es half nichts: Ich wollte einfach nicht mehr überholte Ansätze wie IBC (Injection-Based Components) widerkäuen. Viel simpler wäre es auch nicht nicht geworden. Womöglich sogar schwieriger, weil sich Abstraktionsniveaus mit IBCs schlechter modellieren lassen.

Also bin ich mit einem System-Umwelt-Diagramm eingestiegen und habe dessen System dann als “Hauptplatine” einer EBC-Architektur verfeinert und bin dann nochmal eine Ebene tiefer in den SpellChecker (SC) hinunter gestiegen:

  

In drei Abstraktionsschritten von den Anforderungen zur Architektur. Das war sicherlich überraschend für einige Teilnehmer.

Interessanterweise gab es aber weder dazu noch zu den “komischen Pfeilen”, die ja nicht wie üblich Abhängigkeiten, sondern Nachrichtenflüsse darstellen, grundsätzlich kritische Kommentare. Puh. Das hat mich erleichtert.

Die Kontrakte

Nach soviel Gerede und soviel Malerei stand dann zum Glück aber etwas Code auf dem Programm. Es galt, die die Kontrakte der ermittelten Komponenten festzuzurren. Trotz EBC bleibt Contract-First Design zentral für eine Architektur, die in der Implementierung nicht erodiert.

Für die Kontrakte (und den weiteren Code) hatte ich schon ein Google Project aufgesetzt und mit einer Visual Studio Solution ausgestattet. In die haben wir die Servicekontrakte für die Funktionalität und die Nachrichtenkontrakte “hineingegossen”:

Je Komponente (Bauteile und Platinen) ein Interface. Interface-Abhängigkeiten gibt es nicht – das ist ja der Trick bei EBCs.

Hier ein Beispiel für einen Servicekontrakt:

Und hier ein Teil des Nachrichtenkontrakts:

Die Vokabeln der Ubiquitous Language tauchen konsequenterweise darin wieder auf.

Die Implementation

Nach mehr als 2,5 Stunden war es dann soweit. Die Teilnehmer konnten in die Tasten greifen. Vier kleine Teams gingen daran, die Bauteil-Komponenten zu implementieren. Auch Gastgeber Ilker ließ es sich nicht nehmen, mitzumachen.

Anders als üblich arbeiteten die Teams allerdings still. “Entertainment” hatte es genug gegeben. Jetzt sollte nicht mehr lange (öffentlich) diskutiert werden. Gummi musste auf die Straße.

Um aber nicht nur Gummi bei der Implementation, sondern auch bei der Integration auf die Straße zu bekommen, schlug ich vor, zunächst nur Minimalfunktionalität ohne Tests zu implementieren. Das versetzte mich in die Lage, die Platinen zu prüfen.

Also machte der USB-Stick ein erstes Mal die Runde, um den Teams die Kontrakte zuzuspielen. Und dann ein zweites Mal die Runde zurück zu mir, um ihre rudimentären Implementationen abzuliefern. Darauf aufbauend war meine Aufgabe, die Hauptplatine und die SpellChecker-Platine zu implementieren und alles mit einer kleiner Host-EXE zu starten.

Anschließend gaben die Teilnehmer alles, um ihre Implementationen auszufleischen.

Um 22:17h war es dann soweit: Die Anwendung lief. Texte konnten gegen ein englisches und ein deutsches Wörterbuch geprüft werden. Dabei holperte es noch etwas im UI und die Wörterbücher waren mager – aber “der Kunde” konnte sehen, dass seine Anwendung lief.

Reflexion

Unterm Strich war das Coding Dojo ein Erfolg. Ich bin grundsätzlich zufrieden mit dem Ergebnis. Auch wenn es gedauert hat und wir über Stolpersteine gelaufen sind, gab es am Ende eine lauffähige Anwendung, die von einem verteilten Team realisiert worden ist.

Was ist gut gelaufen?

Ich würde sagen, dass das grundsätzliche Vorgehen gepasst hat. Anforderungen verstehen, Features aufschreiben, Context Map, Kontrakte implementieren: der Fluss war gut. Es gab allerdings Kritik, dass ich dabei zuviel angeleitet hätte. Diese Kritik kann ich gut nachvollziehen, doch ich sehe nicht, wie es hätte anders laufen können.

Wenn bei sonstigen Dojos nach 3 Stunden eine Funktion realisiert ist, dann wäre bei einer ganzen Architektur am Ende kaum etwas Lauffähiges herausgekommen. So schön eine gemeinsame Entwicklung durch die Teilnehmer gewesen wäre – sie hätte nicht mehr als ein gutes Erlebnis produziert. Da bin ich mir sicher. Der Grund: Wenn schon bei der Implementation einer Funktion die Meinung weit auseinandergehen, dann ist das noch mehr der Fall beim Thema Entwurf. Die unterschiedlichen Ansätze, ein leeres Flipchart-Blatt zu füllen, sind dafür der Beweis.

Ziel war nicht, die Gruppe “irgendwie” zu einem Ergebnis kommen zu lassen, sondern einen Weg systematisch zu beschreiten. Das bedarf der Anleitung.

Ich behaupte nicht, dass der Weg, den ich durch den Architekturdschungel “vorgetrampelt” habe, der beste ist. Aber ich behaupte, dass er lohnenswert war, einmal erfahren zu werden. Ich bezweifle, dass viele von den Teilnehmern in ihren Projekten je erlebt haben, wie nach einer sauberen Planung echt parallel und ohne Codekollisionen entwickelt werden kann. Das zu demonstrieren, war mein Anliegen.

Für eine “Diskussionskuschelrunde” mit etwas Architektur hätte Ilker mich auch nicht einladen müssen.

Bei einem nächsten Übungsprojekt wäre es möglich, mehr Arbeit ins Team zu verlagern. Dann würde sich zeigen, ob es etwas vom Vorgehen mitgenommen hat. Bei diesem ersten Mal war jedoch Anleitung in Form eines “fragend entwickelnden Unterrichtsgesprächs” und einem Architekturparadigma nötig.

Gefreut hat mich auch, dass die Concept Map so gut aufgenommen wurde und die Ubiquitous Language sich selbst bei diesem kleinen Projekt als hilfreich herausgestellt hat. Ich hatte mich zunächst gefragt, ob der Aufwand lohnt – doch jetzt bin ich gewiss. Die Concept Map sollte nie fehlen.

Basierend auf der Concept Map habe ich dann auch die Nachrichtenkontrakte gestaltet. Darin kamen im Grunde keine einfachen Typen mehr vor. Statt eines string hat das Frontend ein PrüfTextPaket geschickt. Das hat niemand als Overkill bemängelt. Sehr schön. Ich fühle mich in dem Ansatz bestätigt, zumindest auf Komponentenebene im Grunde keine primitiven Typen mehr einzusetzen. Man vergibt sich mit primitiven Typen nämlich ein Mittel, den Code verständlich zu machen. Aber dazu mehr in einem anderen Blogartikel.

Cool war es zu sehen, wie motiviert alle mitgedacht haben. Soviel Offenheit und Durchhaltevermögen bei Architekturdiskussion! Toll! Und dann auch zu später Stunde noch viel Ehrgeiz bei der Implementation. Wahnsinn!

Was ist weniger gut gelaufen?

Bis zur Implementation ist alles nach Plan gelaufen. Doch dann… Zwar hatte ich den richtigen Gedanken, Integrationsproblemen mit einer “Tracer Bullet” “Kurzimplementation” vorzubeugen. Aber die Ausführung habe ich schlecht vorbereitet.

Das Problem war nicht so sehr, dass Code nur per USB-Stick die Runde machen konnte. Schöner wäre zwar gemeinsamer Zugang mit Mercurial Repository gewesen… doch es ging auch so. Nur langsamer. Viel schlimmer war, dass ich zuwenig über Konventionen gesprochen habe. Denn wo Tools fehlen, müssen Konventionen her.

Die binären Kontrakte haben natürlich die grundsätzliche “Zusammensteckbarkeit” der getrennt entwickelten Komponenten garantiert. Das hat funktioniert. Wir hatten kein wirkliches Integrationsproblem der Assemblies.

Wie der Code aber an mich ausgeliefert wurde, das war ein Problem. Visual Studio kann ja in so unterschiedlicher Weise benutzt werden. Da habe zuwenig erklärt bzw. vorgegeben. Besser wäre es gewesen, ich hätte für jedes Komponenten kurz eine Rumpf-Projektmappe aufgesetzt. Das hätte zwar etwas Zeit gekostet – am Ende wäre dadurch aber so mancher Reibungsverlust vermieden worden.

Lehre #1: Solange Konventionen für die Codeorganisation unbekannt sind oder noch nicht verlässlich eingehalten werden, sollten Komponentenimplementationen als Rahmen vorgegeben werden. Dann gibt es keine Frage, wohin der Output-Path zeigen soll, woher NUnit kommt, wo die Tests zu hinterlegen sind, wie die Bennungen sind, so dass der autom. Buildprozess schlank bleibt.

Kreativität ist ja eine gute Sache – aber sie sollte einen Rahmen haben. Dass z.B. Entwickler die Freiheit haben, Komponenten nicht gem. der Ubiquitous Language zu benennen, ist falsch verstandene Kreativität.

Lehre #2: Die Ubiquitous Language ist heilig. Spaß mit Benennungen mögen Entwickler vielleicht hier und da in ihren Komponenten haben. An den Schnittstellen jedoch und auf Architekturebene ist dafür kein Raum. Verständlichkeit entsteht nur, wenn die gemeinsame Sprache auch wirklich gesprochen wird.

Die Zeit war am Ende knapp. So haben wir alle auf eine erfolgreiche Integration gestarrt. Darunter hat die Codequalität gelitten. TDD im Speziellen war dieses Mal nicht wirklich ein Thema. Und Clean Code Developer Bausteine im Allgemeinen (jenseits der Architektur) auch nicht. So haben sich – wie ein Blick in den Code zeigt – Unschönheiten eingeschlichen. Manche davon waren sogar auf der Projektion zu sehen, weil sie mit dem GUI zu tun hatten.

Lehre #3: Keine Integration ohne Code-Review. Soviel Zeit muss sein. Für den Event war es ok, mal ohne Review zu leben. Es ging ja vordringlich um den Architekturentwurf. Die Implementierung am Ende war Kür und Spaß. Wenn es jedoch etwas ernster wird, dann gibt es kein “Done!” ohne Review.

TDD erleben, ist eine gute Sache. Architekturen mit “parallel rauchenden Köpfen” umsetzen, ist aber auch eine gute Sache. Beides sollten Entwickler öfter tun. Für TDD mag dabei eine Projektion reichen. Beim parallelen Entwickeln ist jedoch erstens ein Coderepository und zweitens ein Zugriff für alle darauf unverzichtbar.

Lehre #4: Das Google Projects Repo war eine gute Sache  - allerdings nur für mich. Das sollte beim nächsten Mal anders sein. Wie könnte das gehen? Mehr Teilnehmer mit einem UMTS-Stick. Oder ein WLAN mit einem Rechner, der ein Repo hostet. Oder ich muss einfach auf dem Zettel haben, dass ich ja einen WLAN UMTS Stick habe, über den ich auch anderen Internetzugang geben kann. Die 4 Rechner hätte der wohl stemmen können.

Schwieriger wird es bei der Versionskontrollsoftware. Viele sind mit SVN oder TFS vertraut. Mit denen würde ich soetwas aber nicht machen wollen. Ein verteiltes Versionskontrollsystem wie Mercurial (oder auch Git) ist viel besser geeignet für verteilte Teams. Da kann jedes Team z.B. in mehreren Commits bis zur Tracer Bullet Implementation kommen, die mit einem Push auf den Server schieben und dann lokal weiterarbeiten, während die Integration sich den Tracer Bullet Stand von allen mit Pull herunterlädt.

Beim nächsten Mal versuche ich es mit TortoiseHg für alle. Das ist einfach zu bedienen. Damit bekommt jeder ein Clone, ein Commit und ein Push hin. Insbesondere ich Mercurial auch sehr tolerant gegenüber Löschungen und Umbenennungen.

Fazit

Trotz einiger Stolpersteine ist das Coding Dojo aus meiner Sicht schön gelaufen. Mein Eindruck war, die Teilnehmer haben etwas mitgenommen. Und sie haben auch Spaß gehabt. Sonst wären sie nicht bis zum bitteren Ende nach knapp 4 Stunden geblieben. Super! Danke an alle fürs Kommen und Mitdenken und Mitmachen.

Und Danke an Ilker für die Einladung. Und Danke an Microsoft für Raum und Annehmlichkeiten. Von mir aus können wir das gern wieder mal machen ;-)

Wem es Spaß gemacht hat und wer tiefer eintauchen möchte in systematischen Softwareentwurf und komponentenorientierte Entwicklung, der kann ja mal überlegen, ob er/sie beim Clean Code Developer Praktikum im Juli mitmachen will. Das bietet 5 Tage Praxis pur – und ist auch noch kostenlos.

Call for Papers: prio.conference – Verteilte Architektur

Am 19. und 20. Oktober 2010 ist es wieder soweit: Die prio.conference (www.prioconference.de) widmet sich einem Thema, das viele Entwickler bewegt. In diesem Jahr ist das “Verteilte Architektur”.

Wie in den Vorjahren bin ich Technical Chair und suche spannende, wegweisende, lehrreiche Vorträge. Wer seine Erfahrung zum Thema “Verteilte Architektur” weitergeben möchte oder jemanden kennt, der etwas zu sagen hat, der melde sich per Email an techchair (at) prioconference.de.

Der offizielle Call for Papers ist hier: http://www.prioconference.de/Call-for-Papers

Ich bin gespannt auf Ihre Einreichungen…

Ja, wo programmiert er denn? [endlich-clean.net]

Das Jahr beginnt gleich wieder gut: Mit einer Menge Veranstaltungen. Und alle stehen Sie im Zeichen von Clean Code Developer (CCD). Das freut mich sehr, denn gedacht hätte ich das vor 12 Monaten nicht, als Stefan Lieser und ich die CCD Initiative gestartet haben. Irgendwie haben wir damit aber einen Nerv der Entwickler-Communities getroffen…

(Fast) Kein .NET-Event ist heute mehr ohne CCD-bezogenen Vortrag. Das ist toll! Denn damit ist der Beweis erbracht, dass Entwickler nicht nur an neuesten Technologien, sondern auch an Qualität interessiert sind. Es wäre schön, wenn wir uns dadurch als Branche ein wenig von der pessimistischen Sicht Nicolai Josuttis´ entfernten, der die Code-Qualität schon als tot proklamiert hat.

Und wo gibt es nun CCD live zu sehen? Wo können Sie mit Stefan und mir face2face diskutieren?

• Den Anfang macht die OOP in München im Januar. Dort sind wir am 28.1. um 9h frisch und munter auf der Bühne – und verteilen auch eine ganze Reihe “CCD Devotionalien” ;-)
• Im Februar folgt die VSone 2010 – ebenfalls in München, quasi unserem derzeitigen CCD-Hauptquartier. Stefan hält einen Vortrag über Domain Driven Design, das wir nahe an CCD sehen und macht einen TDD Workshop. Und ich spreche über Refactoring von Brownfield-Projekten und machen einen Workshop über… ebenfalls TDD, aber in Verbindung mit dem Thema Architektur. Beides liegt für mich dicht beieinander. “Ralf programmiert” heißt der Workshop, weil mir sehr daran gelegen ist, am Code zu demonstrieren, wie Konzepte und Praktiken zusammen kommen. Wir werden Software entwerfen, im Kleinen wie im Großen. Und wir werden eine Praktik wie TDD üben und die Brille des Flow-Patterns aufsetzen. Ich denke, das führt dann zu fruchtbaren Diskussionen und einigen Aha-Erlebnissen.
• Im März ist lädt dann die dotnetpro zu 3 Tagen voller CCD ein: dem powerday, dem powerworkshop und dem powercoaching. Der powerday ist ein Präsentationstag, der einen Überblick über viele Aspekte von CCD geben soll; die besondere Herausforderung dabei an uns: Wir wollen auf der Bühne Brownfield-Code aus dem Publikum refaktorisieren. Ich bin gespannt, was die Teilnehmer uns da so einreichen. Während des powerworkshops wollen wir dann mit den Teilnehmern einen Ausschnitt an Prinzipien und Praktiken von CCD einüben. Die Themen sind dann nicht so breit, es geht dafür in die Tiefe. Und das powercoaching ist eine Veranstaltung, bei der auch der Chef gern dabei sein kann; denn da geht es um den Review von konkretem Projektcode. Wir wollen uns mit Teams ihre Architektur und den Code-IST-Zustand ansehen. Das passiert ebenfalls auf einer (kleinen) Bühne und ist insofern ein Experiment. Experimentell ist natürlich nicht der Review – der funktioniert garantiert. Aber wir glauben, dass auch ansonsten Unbeteiligte aus so einem Review von Code Dritter etwas lernen können. Deshalb dürfen andere Teams, die ebenfalls zum Coaching kommen, das Coaching anderer verfolgen.
• Mit diesen Veranstaltungen aber nicht genug CCD! Von Januar bis April laufen auch noch zwei CCD-Trainings – natürlich in München ;-) Bei der School of .NET sind da sogar noch 1-2 Plätze frei. Wer also kurzentschlossen noch mitmachen will, der ist herzlich eingeladen.

Wo ich im ersten Quartal programmiere, dürfte damit klar sein :-) Vielleicht haben Sie ja Lust, uns hier oder da zu begegnen. Dann schauen Sie doch vorbei und diskutieren mit uns über Ihre Erfahrungen mit CCD oder löchern uns mit Fragen. Wir freuen uns drauf.

Material zu meinen Vorträgen auf der ADC 2009

Die ADC 09 ist fast vorbei – nur noch morgen ein Workshop zum Thema Architektur. Hat wieder Spaß gemacht. Gute Gespräche, ein interessiertes Publikum, Sedgeway fahren :-) Und: die ersten CCD-Mausmatten haben den Weg in die Community gefunden.

Da ich in guter Tradition meine Vorträge ohne PPT-Folien gemacht habe, um den Aufmerksamkeitsfokus der Teilnehmer nicht vom Wesentlichen, dem Thema, auf irgendwelche Projektionen abzulenken, hier einige Hinweise für die, die sich damit weiter beschäftigen möchten:

• Der Quellcode meiner CCR- und ApplicationSpace-Vorträge steht hier zum Download inkl. Microsoft CCR. Der CCR Space als Wrapper um die CCR ist ein Open Source Projekt bei Google: http://code.google.com/p/ccrspace. Der Application Space ist ebenfalls Open Source, aber bei CodePlex: http://xcoappspace.codeplex.com/
• Die CCR ist Teil des Robotics Studio, dessen Nutzung einer Lizenz unterliegt. Wer die CCR produktiv einsetzen will – und das kann man tun, denn sie ist ausgereift –, sollte sich daher einmal anschauen, welche Lizenz passt. Mit einer MSDN Subscription “hat” man die CCR auch, wenn ich mich nicht irre; ansonsten kann man sie auch als sog. “CCR und DSS Toolkit” für kleines Geld kaufen.
• Literatur zur CCR kann ich leider nicht so recht empfehlen. Es gibt versprengt im Netz einiges – aber das beleuchtet die CCR nur punktuell. Die CCR Doku ist nicht ausführlich. In der dotnetpro habe ich aber zwei Artikel im Jahr 2009 darüber geschrieben; die sind natürlich über das online Archiv hier und hier verfügbar.
• Clean Code Developer ist ausführlich im Wiki beschriebe: www.clean-code-developer.de. Dort gibt es auch Hinweise auf Berichte über CCD inkl. Videos. Wer dann mitdiskutieren will, ist herzlich zu den Foren bei XING und Google eingeladen.
• Über Agile Führung bzw. Soziokratie habe ich schon recht ausführlich hier im Blog geschrieben. Außerdem äußere ich gelegentlich Gedanken dazu in einem eigenen Blog: http://soziokratie.blogspot.com. Dort gibt es auch weitere Hinweise zu Quellen gleich in einem der ersten Beiträge. Und es gibt natürlich auch eine “offizielle Repräsentation” dieses Organisationskonzeptes; das ist in Deutschland das Soziokratische Zentrum: www.soziokratie.org.
• Im Architekturworkshop ging es um die systematische Transformation von Anforderungen in wartbare “Grobstrukturen” und dann deren Übersetzung in konkreten Code. Das Softwareuniversum und Softwarezellen waren Thema. Dazu habe ich schon einiges über die Jahre geschrieben. Hier der Lesestoff in ziemlich chronologischer Reihenfolge:
• Alles beginnt in meinem englischen Blog mit einer Serie über “Software Cells”.
• Dann habe ich meine Darstellung auf Deutsch etwas weniger “bildhaft” in meinem deutschen Blog verallgemeinert unter dem Titel “Software als System”.
• Noch konkreter bin ich dann in einigen Artikeln und Artikelserien in der dotnetpro geworden. Die Artikel stehen alle im online Archiv, worauf die folgende Liste verweist. Allerdings muss man für den Zugriff Abonnent der dotnetpro sein. Das kostet zwar etwas – aber ich glaube, der Abopreis zahlt sich aus.
• Keine Frage der Schicht, 3/06
• Anforderungen systematisch implementieren und testen, 5/06
• Einstieg in den praktischen Softwareentwurf, Beginn einer 8-teiligen Serie in Heft 6/06
• Mustererkennung visualisieren, Beginn einer mehrteiligen Serie in Heft 12/07
• Dann habe ich auch noch einen Anlauf gemacht, meine “Theorie” gezielt in einem Architekturblog zusammen zu fassen; statt Buch sozusagen. “The Architect´s Napkin” ist das leider unvollständige Ergebnis, das aber zumindest aktuelle und etwas ungewöhnliche Visualisierungen bietet.

Auf der ADC habe ich schon einige Fragen zu diesen Themen beantworten können. Doch es ergeben sich im Nachhinein bestimmt noch mehr. Bitte zögern Sie dann nicht, mich per Email (info (at) ralfw (dot) de) oder über die Kommentare hier im Blog zu kontaktieren. Ich bin gespannt auf Ihre Gedanken.

Motivationshappen

Da habe ich angekündigt, dass Teilnehmer von Entwicklerkonferenzen der nächsten Zeit in ihren Taschen Clean Code Developer Mausmatten finden würden – aber ich hab mir keine Gedanken gemacht, wie diese Taschen überhaupt an Teilnehmer kommen. Tststs, wie nachlässig von mir. Das darf ich doch nicht einer unsicheren Chefentscheidung überlassen ;-)

Deshalb hier für die bisher noch Unentschiedenen oder Chefabhängiggen zwei Motivationshappen:

Wer zur ADC 2009 nach Bonn kommen und auch noch meinen Workshop zum Thema Softwarearchitektur besuchen möchte, der kann sich bei mir per Email melden und bekommt einen Promocode, der ihm oder ihr 200 EUR Rabatt gewährt. Die ADC bietet ein breites Spektrum an Vorträgen zu vielen Themen der .NET Softwareentwicklung. Dieser Happen kann bis zum 25.09.2009 geschnappt werden.

Wer hingegen oder ebenfalls nach München zur prio 2009 kommen möchte, um sich speziell rund um das Thema “User Interfaces für .NET Software” auf den aktuellen Stand zu bringen, der kann sich ebenfalls bei mir per Email melden und erhält einen Promocode für 400 EUR Rabatt auf den regulären Veranstaltungspreis. Von diesem Happen sind noch 10 auf dem Teller.

Der Rechtsweg ist für beide Angebote natürlich ausgeschlossen.

Also: Ran an die Email! Ich hoffe, wir sehen uns auf zumindest einer der beiden Konferenzen. Die Mauspads wollen zu euch ;-)

Die Zukunft der IDEs ist hier - Intentional Programming [OOP 2009]

Vor 4-5 Jahren hatte ich die Zukunft schon einmal gesehen. Damals auf der SD West Konferenz in Los Angeles. Jetzt wieder - aber dieses Mal im Internet. Sie scheint nun auch nicht mehr in so weiter Ferne zu liegen. Die Zukunft der IDEs ist für einige nämlich schon hier. Intentional Software - die ambitionierte und geradezu geheimnisvolle Firma von Softwarepionier Charles Simonyi - hat schon die ersten Releases ihrer Intentional Domain Workbench hinter sich. Bisher ist in deren Genuss allerdings nur ein kleiner Kreis von Anwendern gekommen.

Nach Jahren der eher verschlossenen Türen und vorsichtigen Äußerungen sucht Intentional Software nun jedoch vermehrt den Kontakt zur Entwicklergemeinde, wie es scheint. Selbst auf einer so kleinen Konferenz wie der SET 2009 war Charles Simonyi mit seinen Mitarbeitern, um ihre Vision von der Softwareentwicklung der Zukunft vorzustellen.

Das Bild oben skizziert, worum es geht: Software ist nurmehr eine abstrakte Beschreibung einer Problemlösung, die viele Darstellungen haben kann. Sie ist sogar so abstrakt, dass ihre "wahre Form" in der IDE nicht direkt bearbeitet wird. Für Visual Studio ist Software letztlich der Quelltext, den wir schreiben. Für die Intentional Domain Workbench ist es hingegen ein interner Baum. Und diesen Baum projiziert die Workbench als ganzes oder in Teilen so, wie es für den Anwender am besten passt. Programmierer sehen ihn z.B. als C#- oder Ruby-Code, Domänenexperten als Tabelle oder Graph oder Diagramm.

Und wo ist der Unterschied zu den domänenspezifischen Sprachen samt Werkzeugen wie Oslo, die gerade en vogue sind? Wo ist der Unterschied zum Model Driven Development?

Die Schnittmenge ist natürlich die domänenspezifische Darstellung. DSLs, MDD, Intentional Software bringen das Programm näher an den Domänenexperten. Der Transfer von Formulierungen in der Domänensprache in einem Anforderungsdokument in Code soll leichter werden. Oder noch besser: Domänenexperten sollen im Idealfall selbst programmieren.

Dass das möglich ist, haben Tabellenkalkulationsprogramme wie Excel schon für viele Problemdomänen gezeigt. Vor Excel bzw. VisiCalc mussten Anwender entweder den Taschenrechner bemühen oder ihre Kalkulationen Programmierern erklären, die sie dann z.B. in C oder Fortran umgesetzt haben. Heute greift der Domänenexperte selbst zu Excel oder - um ein anderes Beispiel zu nennen - MATLAB.

In ihrem Lösungsansatz für die "Domänenprogrammierung" unterscheiden sich DSLs, MDD und Intentional Software jedoch. Die Intentional Domain Workbench profiliert sich dabei aus meiner Sicht durch zweierlei:

• Abstrakte Repräsentation: Der Quellcode von Software hat nichts mehr mit einer Ausführungsplattform oder Problemdomäne zu tun. Er ist wirklich abstrakt, also nicht mehr textuell.
• Perspektivenvielfalt: Quellcode soll auf viele verschiedene Weisen im Ganzen oder in Ausschnitten dargestellt und bearbeitet werden können. Alle Sichtweisen sind gleichberechtigt. Quellcode kann daher auch gleichzeitig verschiedene Problemdomänen repräsentieren.
• Fließende Darstellung: Die vielen Perspektiven auf den Quellcode fließen in der Workbench umeinander. Sie müssen sich nicht zwischen der einen oder der anderen entscheiden, sondern können nebeneinander oder ineinander immer wieder anderen Perspektiven einnehmen.

Schauen Sie sich einmal dieses Video einer Präsentation der Workbench an. Für einen schnellen Eindruck von der Dynamik dieser visionären IDE empfehle ich allerdings den Download der WMV-Datei; spulen Sie darin vor bis zu Minute 14. Da gehts los mit der Demo, aus der die Screenshots oben stammen. Bis zu Minute 45 ist dann die Zukunft der IDEs schon auf Ihrem Desktop. Seien wir gespannt, wann sie schließlich als öffentliche Beta materialisiert. Aber warten Sie nicht darauf! Intentional Software hatte schon viel Zeit und wird wohl auch noch weiter Zeit haben. Man scheint auf Qualität bedacht statt Hype. Eine wohltuende Haltung in Zeiten sich überschlagender CTPs.

SET 2009 CCR Beispiele

Gestern auf der SET 2009 in Zürich habe ich einen Vortrag über die Concurrency Coordination Runtime (CCR) von Microsoft gehalten. Leider standen mit nur 45min zur Verfügung :-( Dennoch glaube ich, dass die Botschaft, die Zukunft liege bei asynchronen Komponenten, um Multicore Prozessoren auszureizen, bei den Teilnehmern angekommen ist. Der Raum war jedenfalls voll und alle schienen am Ende zufrieden. Vielleicht waren sie aber auch nur noch benommen vom Codefeuerwerk, dass ich abgebrannt habe? ;-) Denn ich habe neben 1-2 Flipchartblättern nur Code mit CCR-Beispielen gezeigt. Den gibts hier auch zum Download. Da asynchrone Programmierung für viele neu ist, mögen die Konstrukte auf die Schnelle nicht immer einfach zu verstehen gewesen sein, auch wenn ich mich auf die CCR-Grundlagen beschränkt habe. In jedem Fall freue ich mich, dass am Ende noch 10 Minuten "Überziehungszeit" war, um auch noch die transparente Verteilung von CCR-basierten asynchronen Komponenten demonstrieren. Denn: Wer schon lokal asynchron programmiert, hat es viel einfacher, skalierbare verteilte Architekturen aufzusetzen.

Blaues Wunder VSone 09

Das war sie wieder, die VSone 2009, die Frühjahrsentwicklerveranstaltung von ppedv. In München, am gewohnten Ort im Forum des Deutschen Museums - aber mit viel mehr Teilnehmern als in den letzten Jahren! Knapp 500 sollen gekommen sein. Es war eine gemütliche Atmosphäre in der Kinolobby unter dem ehemaligen IMAX-Kino.

Das Vortrags- und Workshop-Programm war gewohnt vielfältig, die Sprecherriege gemischt. Aus dem fernen Seattle war aber sogar Chris Sells angereist, um Microsofts Oslo vorzustellen.

Wer allerdings geglaubt hatte, zwei Tage lang eine ruhige Kugel bei Technologievorträgen schieben zu können, der erlebte sein blaues Wunder! Am Abend des ersten Konferenztages gab es kein Halten mehr: die Karneval-Narren waren los. Ja, sogar in München. Neno Loje, mich, Jürgen Kotz und Christian Wenz traf es wie alle anderen Teilnehmer. Auf der Abendveranstaltung galt "Hutpflicht":

Entschädigt für diese "Verunstaltung" unserer Charakterköpfe wurden wir dann jedoch zum Glück durch schmissige Darbietungen der Tanzgruppe des Karnevalsvereins Dorfen. Soviele Frauen waren bisher selten zu sehen auf Entwicklerveranstaltungen ;-)

Diesermaßen motiviert, waren die restlichen zwei Tage dann eine Kleinigkeit. Die Teilnehmer konnten sogar meinen Vortrag über die Concurrency Coordination Runtime (CCR) ohne Powerpoints ertragen und waren am Freitag von 9h bis 17h superaufmerksam in meinem Workshop zum Thema Anwendungsarchitektur und Parallelprogrammierung. Als im Workshop dann auch noch die Premiere des Xcoordination Application Space tadellos lief, war ich endgültig überzeugt von der VSone als gelungener "Kessel Buntes" Veranstaltung für .NET Entwickler und Sharepoint-Profis.

Beispielcode und Flipchart-Fotos des Workshops können hier heruntergeladen werden: http://www.ralfw.de/download/VSone09Workshop.zip. Es ist auch eine Vorabversion des Application Space dabei. Dessen Zweck ist es, Anwendungen sehr, sehr einfach von synchronen lokalen Komponenten über asynchrone lokale bis zu verteilten asynchronen Komponenten zu skalieren. Der Application Space ist Architekturinfrastruktur, die es wesentlich einfacher machen soll, in die Multi-Core- und Multi-Tier Programmierung einzusteigen. Aber davon ein andermal mehr.

Softwarearchitektur kompakt - prio.conference 2008

Als wie relevant das Thema Softwarearchitektur inzwischen in der Community wahrgenommen wird, hat die prio.conference der dotnetpro am 10./11. November gezeigt: mehr als 260 Teilnehmer hatten den Weg nach Baden-Baden ins Kurhaus gefunden. Das ist eine Zahl, die mich als Content Manager der prio sehr gefreut hat - und ich hoffe, dass nicht nur das Oberthema im Großen, sondern auch meine Auswahl von Vortragsthemen und -referenten im Kleinen dazu einen Beitrag geleistet hat.

Erstes Feedback stimmt mich da aber positiv. So ist zum Beispiel die Keynote des (wahrscheinlich) einzigen wirklichen Architekten vor Ort sehr gut angekommen. Prof. Dr. Christian Kühn aus Wien hat einen interessanten Bogen von seinem Metier der Bauarchitektur zur Softwareentwicklung geschlagen. Denn wenn sich schon die Pattern-Bewegung der Softwareentwicklung auf bauarchitektonische Patterns bezieht, ist es angezeigt einmal zu beleuchten, welche Relevanz die denn eigentlich haben. Und so haben die Anwesenden nicht nur erfahren, wie die Patterns schon vor Erich Gamma et al. ihren Weg in die Softwarebranche gefunden hatten, sondern auch, wie Prinz Charles mit Patterns verbunden ist.

Nach solchem Blick über den Tellerrand ging es dann aber mit "echten" Softwareinhalten los. In 30 Sessions haben die Referenten den Bogen vom Konzeptionellen wie der Definition von Architekturrollen und Dokumentation über eher unbekannte Technologien wie Microsofts CCR oder PostSharp bis zu handfesten Tipps zum Transport von veränderlichen Objekten per WCF gespannt.

Besonders haben mich die Kommentare zum Thema Jabber gefreut. Die Teilnehmer waren hocherfreut zu erfahren, dass es solch coole Kommunikationstechnologie gibt - und gleichzeitig erstaunt, dass sie bisher davon noch nichts gehört hatten. Denn Jabber kann vieles schon lange, was Microsoft erst heute mit seinem Communication Server anfängt zu realisieren. Und dabei ist Jabber bzw. seine Server und Clients vielfach kostenlos und reifer.

Ebenfalls über den Horizont der vielfach Microsoft-lastigen Welt der .NET-Community hinaus hat Referent Markus Völter mit seinen Vorträgen zum Thema Domänenspezifische Sprachen (DSL) geblickt. Er hat vorgeführt, wie auf der Basis der oAW Plattform mit Eclipse (!) schon heute eigene textuelle Sprachen inkl. Codegeneratoren realisiert werden können. Wer also nicht auf Microsofts Oslo warten will, der kann jetzt loslegen.

Die prio hat somit nicht nur viele Facetten des Themas Softwarearchitektur beleuchtet, sondern bewusst weiter geblickt als die üblichen Microsoft-lastigen Events. Softwarearchitektur hat zwar immer mit Entwicklungsplattform zu tun, sollte sich von ihr aber nicht unnötig beschränken lassen. Relevante und interessante Entwicklungen gibt es jenseits von Linq, Entity Framework, WPF, Silverlight oder dem sich schon zur Welle hebenden OsloAzureWindows7.

Aber nicht nur das Fachliche hat Spaß gemacht. Der Abend stand wieder ganz im Zeichen der Heimat der dotnetpro: alle Teilnehmer trafen sich im Löwenbräu zu einem nah ans Oktoberfest-Original heranreichenden bayrischen Abend. Der war ausnehmend gemütlich - auch wenn er Sprecher und Veranstalter sich nicht nur entspannen konnten. Wie schon im Vorjahr galt das Motto der englischen Offiziersakademie Sandhurst: serve to lead - dienen, um zu führen. Und so bedienten Sprecher und Chefredakteur die Teilnehmer vor und hinter dem Thresen.

Das hat Laune gemacht und wieder ganz neue Einblicke in die Community gegeben :-)

Im nächsten Jahr wird die prio solche Gemütlichkeit jedoch nicht mehr "exportieren" müssen. 2009 findet die prio.conference in der dotnetpro Heimatstadt München statt. Das Thema steht auch schon fest. Es wird um "User Interfaces" gehen. Und es wird natürlich wieder technisch und praktisch und konzeptionell werden. Von Usability bis DataBinding Best Practices gibt es viel zum Thema zu sagen. Immerhin sind User Interfaces das Aushängeschild unserer Anwendungen.

Aber zur Softwarearchitektur wird die dotnetpro bis dahin sicher auch nicht stumm bleiben. Stay tuned!

Qualität hat keinen Preis mehr - so scheint es

Zwei symptomatische Geschichte:

Es ruft ein Kompetenzträger bei einem Konferenzveranstalter an und fragt, ob der für die nächste Konferenz an Vorträgen zu einem Thema interessiert wäre. Der Veranstalter freut sich nach Rücksprache mit dem Content Management mitteilen zu können, dass die angetragenen Vorträge gut ins Programm passen würden. Eine Kleinigkeit sie vorher allerdings noch zu klären: der Umfang des Sponsorenpaketes, das der Kompetenzträger buchen möchte.

Ein andermal ruft die Redaktion eines unserer Fachmagazine zur Einreichung von Artikelvorschlägen auf. Auf Nachfrage, wie hoch denn das zu erwartende Autorenhonorar sei, antwortet man, dass ab der dritten Heftseite eines Artikels 40 EUR/Seite gezahlt würden. Für die Seiten 1 bis 3 sei den Autoren jedoch ein sehr warmer, in nicht näher spezifizierten Naturalien ausgedrückter Dank des Verlages gewiss.

Zwei Geschichten, eine Reaktion: Traditionelle Inhaltsplattformen wollen kein Geld mehr für ihre Inhalte ausgeben. Sie wollen das, was ihren Wert ausmacht, weder produzieren noch die Produktion bezahlen.

Sind im Web oft für die Konsumenten kostenlos, so kehrt sich dies scheinbar gerade bei den für die Branche relevanten traditionellen Medien Zeitschrift und Konferenz um. Da bezahlen die Konsumenten und die ureigentlichen Produzenten gehen leer aus oder sollen gar noch Geld mitbringen.

Eine merkwürdige Welt ist das.

Mit dem, was ich einmal auf der Schule gelernt habe, hat das nicht viel zu tun. Da galt nämlich, dass Angebot und Nachfrage den Preis regeln. Ist das Angebot groß und die Nachfrage klein, dann ist der Preis für das Angebot niedrig. Kommt dann die Nachfrage dem Angebot näher, zieht der Preis an. Maximal wird der dann bei einem Monopol.

Daran hat auch das Web nichts geändert, würde ich mal sagen. Wenn die Artikel bei Codeproject für Leser kostenlos sind, dann liegt das daran, dass das Angebot an Content im Web so riesig ist. Die Nachfrage pro Contentanbieter ist deshalb klein und der Preis niedrig bis nicht existent. Wenn Codeproject dennoch überleben kann, dann liegt es an Werbeeinnahmen und good will der Contentproduzenten. Die verschenken ihr Wissen für... ja, für was eigentlich? Für das gute Gefühl, der Community etwas zurückgegeben zu haben:

"Everything on the site may be freely used. All we ask in return is that you contribute something back to the community." (CodeProject FAQ)

Ob das genug Lohn der Mühe ist, muss jeder für sich entscheiden. Dass die Qualität solcher Gratisinhalte oft zu wünschen übrig lässt, ist hingegen wenig zweifelhaft.

Aber einerlei. In den zwei obigen Geschichten geht es nicht um Codeproject. Es geht auch nicht ums Web. Es geht vielmehr um traditionelle Medien, die mittlerweile schon traditionell nicht aus dem Klagen herauskommen, die Nachfrage bei ihnen sei so schmerzvoll gering.

Was tun sie aber in der Lage: sie senken weder den Preis, noch erhöhen sie die Qualität. Sie drehen vielmehr an der Kostenschraube. Sie geben den Druck, der auf ihnen lastet, an die weiter, die eigentlich erst ihre Existenz berechtigen. Denn ohne Inhalte kein Medium zu ihrer Verbreitung.

Es gibt natürlich kein Recht auf Honorar für Kompetenzträger. Und so finde ich es ganz legitim, wenn Medien wie das MSDN Magazine kein Honorar zahlen. Auch sie leben nach den Gesetzen des Marktes: Das Angebot ist beschränkt, die Nachfrage ist hoch, also ist auch der Preis hoch. In diesem Fall meine ich allerdings das Angebot an Platz für den Inhalt und die Nachfrage von Autorenseite. Pro Ausgabe erscheinen nur ca. 15 Artikel von denen einige schon fest an Kolumnenautoren vergeben sind. Für die verbleibenden gibt es eine lange Schlange an willigen Autoren - also erlaubt sich das MSDN Magazine, kein Honorar zu zahlen. Dort zu veröffentlichen hat für die Autoren soviel Wert (Ruhm oder Sichtbarkeit + Aufträge), dass sie diese Politik akzeptieren.

Wieder zurück zu lokalem Konferenzveranstalter und Zeitschriftenverlag. Die haben nun dieselbe Politik wie das MSDN Magazine installiert - aber bieten bei weitem nicht denselben Nutzen für die Inhaltsproduzenten. Die Konferenzen des Veranstalters sind klein, die Auflage der Zeitschrift auch. Das beklagen beide.

Es erscheint mir daher widersinnig, eine solche Politik im Umgang mit den Wertproduzenten zu installieren. Was verspricht man sich davon? Beide handeln gegen das simpelste Gesetz des Marktes: Keine Nachfrage bei dem Abnehmern, aber der Preis bleibt konstant und der Wert wird nicht erhöht. Keine Nachfrage bei den Inhaltslieferanten, aber der Preis für die Lieferung wird erhöht, indem das Honorar gesenkt wird.

Denn so sieht es leider aus: die Inhalte der Konferenzen und der Zeitschrift sind nicht herausragend. Kompetenzträger, die fachlich gut und stilistisch angenehm vortragen oder schreiben, sind einfach Mangelware. Wer dann nichts dafür, sondern alles dagegen tut, die eigene Inhaltsplattform attraktiv für solche ohnehin raren Inhaltslieferanten zu machen, der darf sich nicht wundern, wenn die Qualität sinkt. Einige sehr gute und auch beliebte Inhaltslieferanten sind denn auch schon nicht mehr zu sehen oder zu lesen; sie haben besseres zu tun, als auch noch Geld für die Wissensweitergabe auszugeben.

Was ist unzweifelhaft der Effekt, wenn Kompetenzpräsentationen nicht nur nichts einbringen, sondern sogar kosten sollen? Sie geraten zu Verkaufsveranstaltungen. Es präsentieren die sich, die es nötig haben, weil sie nicht nur die Investition der Präsentation wieder hereinbekommen müssen, sondern auch noch darüber hinaus mit ihr Profit durch nachfolgende Aufträge generieren müssen.

Oder es sind die zu sehen, die sich zeigen müssen, weil ein System es so will ("publish or perish") bzw. der Chef.

Alles in allem ist - wie überall, wo Werbung ins Spiel kommt - aber nicht damit zu rechnen, dass durch solche Politik die Qualität im Allgemeinen und Ehrlichkeit/Authentizität im Besonderen steigen. Nach beidem fragen aber Teilnehmer wie Leser. Im Dschungel heutiger Technologien brauchen sie nichts dringender als vertrauenswürdige Quellen. Präsentatoren in Wort oder Schrift, die für die Präsentationsmöglichkeit zahlen mussten, sind das allerdings eher nicht.

Ergo: Die Nachfrage nach diesen Inhaltsplattformen kann nur abnehmen. Die schon jetzt beklagte negative Tendenz verschärft sich. Die, die gut aufbereitete Informationen dringender denn je nötig haben, wandern weiter ab ins Web, um dort viel Mühe für die Filterung von Inhalten aufzuwenden.

Schade. Denn die Plattformen haben einen Namen. Nun verspielen sie ihn.

Früher war platte Werbung. Da konnten wir Inhalt und Beschönigung auseinander halten. Dann kam das Advertorial. Sofern gekennzeichnet, konnten wir immer noch Inhalt und Beschönigung trennen, doch es war schwieriger geworden. Nun kommt ungekennzeichneter bezahlter Content. Den können wir nicht mehr von Content unterscheiden, der nicht primär verkaufsinteressengeleitet ist. Statt für unser Geld vertrauenswürdieg Informationen zu bekommen, sehen und lesen wir im Zweifelsfall vor allem eines: Werbung.

Eine verhängnisvolle Entwicklung, die letztlich allen Inhaltsanbietern Schaden zufügt. Wer sich da beklagt, dass es mit der Nachfrage nicht stimmt und auf das Web zeigt, der hat leider weder die Befindlichkeit der Branche noch die Gesetze des Marktes begriffen.

Dabei wäre es doch so einfach, die Nachfrageentwicklung umzukehren. Die Zauberworte lauten - wie immer - Innovation und Investition. Wer das nicht glaubt oder sich inspirieren lassen möchte, der lese "Alles, außer gewöhnlich". Dessen Autoren haben sicherlich auch ein Honorar für ihre Arbeit bekommen.

PS: Es geht mir übrigens bei dieser Betrachtung nicht darum, ob mir oder jemand anderem die Geschichten widerfahren sind. Ich stelle nur eine bedenkliche Tendenz fest. Nicht nur für jeden, der daran denkt, doch mal sein Wissen weiterzugeben, sondern für alle, die vertrauenswürdiges Wissen suchen.

Warum ich Vortragsagendas nicht mag [OOP 2009]

Ein Vortrag soll mit einer Agenda beginnen - so will es... ja, wer eigentlich? So ist es zumindest. Oft, meistens, wenn man Vorträge auf Entwicklerkonferenzen sieht. In irgendeinem Rhetorik-Lehrbuch mag das mal gestanden haben und jedes Buch mit Inhaltsverzeichnis scheint das zu unterstreichen.

Aber ich halte davon gar nicht. Und so sage ich es denn auch immer wieder den Teilnehmern der Rhetorikseminare des Professional Developer College. Die reagieren dann mit Überraschung, Unglauben, Skepsis. Das könne doch nicht sein. Man müsse doch dem werten Publikum einen Überblick geben, bevor man mit dem Eigentlichen des Vortrags beginnt.

Nun, dann möge man hier einmal hineinschauen:

Das ist ein absolut typischer Vortrag auf einer Entwicklerkonferenz. So beginnt er denn auch mit einer Agenda. Der Sprecher zeigt, wie er sich den Vortrag in thematische Abschnitte gegliedert denkt. Und er spricht darüber. Damit er sich an die Struktur erinnert, hat er das kanonische Agenda-Slide an den Anfang der Vortragslides gesetzt.

Ja, genau, damit der Sprecher sich erinnert, deshalb ist dieses Slide dort. Kein anderer Grund scheint mir plausibel. Warum? Weil der Referent die Punkte abliest. Er liest den Text vor und fügt nichts hinzu. Warum sollte er das tun, wenn er sich seiner Vortragsstruktur erinnerte? Dann würde er nämlich nicht dieselben Worte benutzen, die jeder Zuschauer auch lesen kann.

Was habe ich nun als Zuschauer davon, dass der Referent 1. eine Agenda zeigt und 2. diese Agenda nur vorliest, wie es meistens der Fall ist? Nichts. Mir wird dadurch nichts klarer. Ich baue keine Vorfreude auf, ich bin nicht überrascht, ich fühle mich nicht erhellt. Denn dass ein Vortrag mit dem Titel "Architecting for Latency" am Anfang Latenz generall thematisiert, um sicherzustellen, dass alle dasselbe darunter verstehen, dann weiter geht zu den Gründen, warum ihre Berücksichtigung sinnig ist, anschließend die Schwierigkeiten beleuchtet und am Ende - hört, hört! - Lösungen aufzeigt... nun, das (!) erwarte ich, wenn ich auch nur 30 Sekunden über das Thema nachdenke.

So hat die Agenda keinen Nutzen. Sie langweilt nur. Wie üblich. Ihr Informationswert ist Null. Darüber hinaus nimmt sie einem Vortrag jede Spannung. Wer würde schon zu Beginn eines Krimis dessen Agenda gern kennenlernen? Nichts anderes als ein "kleiner Krimi" sollte ein Vortrag aber sein: er sollte Spannung erzeugen. Die Zuschauer sollen sich in jeder Minute fragen, wie es wohl weitergehen mag in Richtung Lösung. Sie sollen emotional gefesselt sein, mitfiebern, Interesse haben. Dafür ist eine Übersicht allerdings denkbar ungeeignet.

Aber Columbo war doch auch immer Spannend, obwohl man schon zu Anfang wusste, wer der Bösewicht ist. Ja, das stimmt. Aber Columbo hat nie am Anfang verraten, wie er (!) das herausfindet. Die Spannung bestand darin, eben nicht (!) zu wissen, wie er das für uns Offensichtliche langsam erarbeitet. Columbo mag eine eigene Agenda, eine Methode gehabt haben - verraten hat er sie uns aber nicht.

Also: die Agenda am Anfang eines Vortrag hat keinen Nutzen für die Zuschauer. Entweder haben sie ohnehin schon die Erwartung, dass es so, wie der Referent beabsichtigt, durchs Thema geht. Oder sie kennen das Thema nur wenig - dann verstehen sie nicht, was der Referent da überhaupt in der Agenda nacheinander listet. Sollte schließlich beides nicht stimmen und die Zuschauer toootal von der Agenda überrascht sein... tja, dann hat der Referent sein Pulver im Grunde verschossen. Dann hat er schon am Anfang verraten, dass er eine Überraschung für das Publikum hat. Wie langweilig.

Ein Inhaltsverzeichnis, eine Agenda ist nur sinnvoll, wenn der Zuschauer mit ihrer Kenntnis Entscheidungen besser treffen kann. Welche Entscheidung soll er aber bei einem 60min Vortrag treffen? Bei einem Buch kann er nach Lektüre des Inhaltsverzeichnisses zu einem für ihn besonders interessanten Kapitel springen. Im Vortrag muss er im schlechtesten Fall bei vollem Bewusstsein 50min ausharren, um dann in den letzten 10min zu hören, was ihn interessiert. Die Agenda hat ihm Hoffnung und Überraschungseffekte genommen.

Bei einem mehrtägigen Training mag es sinnig sein, am Anfang kurz den Verlauf des Trainings zu skizzieren, damit Teilnehmer ihre Ressourcen einteilen können. Doch auch in dem Fall bin ich skeptisch, dass das mehr bringt als eine diffuse Beruhigung. Denn wer trainiert werden will, der hat naturgemäß wenig Ahnung vom Thema. Was nützt also einem Trainingsteilnehmer bei einem .NET Grundlagenseminar die Information am 1. Tag, dass er am 4. die Weihen der WinForms UserControl Programmierung empfangen wird? Soll er damit Vorfreude aufbauen? Hm...

Dass (!) ein Thema behandelt wird, ist natürlich wichtig zu wissen. Ohne diese Information würde man ein Training kaum buchen. Aber in welcher Reihenfolge die Inhalte vermittelt werden... was nützt diese Information? Sie macht es dem Referenten sogar schwer, während der Stoffbehandlung den Weg durchs Thema zuschauerbezogen zu wählen.

Bottom line: Wer noch eine Agenda am Anfang seines Vortrags hat, streiche sie ersatzlos.

Besser als eine Agenda ist ein knackiger Einstieg, der das Publikum ohne Verzug "abholt" und auf eine spannende Fahrt durch das Thema mitnimmt.

Networking pur - Der .NET Open Space Event in Leipzig

Wer den Erfahrungsaustausch sucht, interessante Leute aus der DACH-Entwicklergemeinde kennenlernen will oder etwas rund um .NET lernen will, der ist mit dem .NET Open Space Event gut bedient. Zum ersten Mal fand der am vergangenen Wochenende in Leipzig statt - und wird dort hoffentlich auch in Zukunft seine Heimat haben. Ich freue mich jedenfalls schon auf den nächsten.

Anders als bei den üblichen Entwicklerkonferenzen, wo ein Content Management die Themen und Referenten plant, organisiert sich ein Open Space Event selbst. Die Agenda ist offen, nur das Oberthema - hier: .NET - steht fest, damit sich grundsätzlich Gleichgesinnte zusammenfinden.

Und dann gehts los! Sind die Gleichgesinnten "auf einem Haufen", hat jeder die Möglichkeit, ein Thema vorzuschlagen, über das er gern sprechen möchte. Dabei ist es egal, ob er oder sie kompetent zum Thema ist oder nicht. So habe ich z.B. am 2. Tage das Thema "Funktionale Programmierung" vorgeschlagen, ohne Experte darin zu sein. Mich hat einfach der Meinungsaustausch gereizt und vielleicht die eine oder andere Meinung eines unter den Gleichgesinnten anwesenden Experten. Dass dann da keiner war, sondern wir eher alle nur Einäugige oder Blinde, hat dem Erfolg jedoch keinen Abbruch getan.

Stefan Lieser leitet die Themenfindung. Foto: Kurt Häusler.

Wenn ein Thema genügend Interessenten findet, finden die sich bei einem Open Space Event in einem von den Organisatoren bereitgestellten Raum zusammen und diskutieren einfach. Das war´s. Keine weiteren Vorgaben, keine Verpflichtungen, kein großes Regelwerk.

Interesse an einem Thema und Lust auf Gespräch in einer mehr oder weniger großen Runde, das ist alles. So waren die Runden manchmal klein (wie beim Thema Parallelverarbeitung, wo wir zu knapp zehnt waren), ein andermal groß (wie beim Thema Testen, an dem alle knapp 90 Teilnehmer mitdiskutiert haben).

Bei großer Teilnehmerzahl und vielen Meinungen kann der Austausch durch einen "Fishbowl" moderiert werden. Drei Diskutanten sitzen vorne und tauschen sich aus - bis sie durch Zuhörer, die etwas beitragen möchten, abgelöst werden. Foto: Kurt Häusler.

Zu jeder Zeit konnten max. 4 Themen gleichzeitig in Gruppen besprochen werden. Das hat manches Mal für Frust gesorgt, weil es mehr als ein interessantes Thema gab. Aber es war ok. Breit interessierende Themen wurden deshalb als "general session" alleinstehend behandelt, entweder in einem Raum oder in mehreren Gruppen.

Der Wert des .NET Open Space war für jeden Teilnehmer damit proportional zu seinem Engagement: Wer ein Thema dringend behandeln wollte, hat es für ein Gruppengespräch vorgeschlagen. Wer in einer Gruppe etwas fragen/sagen wollte, hat einfach den Mund aufgemacht. Es gab keinen Rückzug darauf, dass da ja ein Sprecher nur sein Wissen loswerden wollte, um anschließend in einer Speaker Lounge zu verschwinden. Jeder war Zuhörer und Sprecher gleichzeitig - wenn er/sie wollte. So ergab sich ganz natürlich ein intensives Networking, wie man es auf keiner üblichen Konferenz findet.

Networking at its best im Foyer des Veranstaltungsortes. Foto: Kurt Häusler.

Rundum also ein innovativer Event, der mir etwas gebracht hat. Ob der Technical Summit von Microsoft im November das auch leisten wird, weiß ich hingegen noch nicht. Manchmal ist weniger Aufwand eben mehr. Denn der .NET Open Space war bescheiden ausgestattet, da er keine weitläufigen Show Floor mit Ausstellerbuden oder Handouts oder Giveaways zu bieten hatte. Macht aber nichts. Alles war völlig ausreichend. Vor allem das Caterin mit süßen Sachen :-)

Das süße Catering war sehr verführerisch. Der schlanken Linie der Open Space Besucher wären ein paar mehr Gemüsesticks beim nächsten Mal zuträglicher ;-) Foto: Kurt Häusler.

Der .NET Open Space hat zum ersten Mal stattgefunden. Open Spaces als Eventformat sind aber nicht neu. In England und den USA hat die Alt.Net Gemeinde sie schon länger für sich entdeckt. Und anno 2001 hatte sogar Microsoft in Deutschland schon einmal einen Open Space im Anschluss an den Technical Summit veranstaltet. Damals aber nur offensichtlich wenig memorablem Erfolg, da ich keinen getroffen habe, der sich daran erinnern konnte. Nun, so haben manche Ideen eben ihre Zeit. Die für Open Spaces scheint nun endlich gekommen. Lange überfällig und deshalb gut so.

Gerade deshalb ist natürlich auch noch nicht alles perfekt gelaufen in Leipzig - wenn denn das überhaupt ein Kriterium ist. Die Themenfindung könnte schneller laufen und lief auch am zweiten Tag schon schneller. Ein wenig mehr "Moderation" könnte sein, damit auch "schwächere Stimmen" einmal Gehör finden oder Sessions nicht so einfach "ins Normale" abdriften. Denn wenn aus dem Gespräch ein - wenn auch wohlmeinender - Monolog wird, der Raum dunkel ist und mehr als eine Stunde Powerpoint den Takt angibt, dann... ja, dann ist der Abstand zum Üblichen zu gering. Dann verlagert sich das Gespräch wieder ins Zufällige und in die Pausen.

Doch das sind Kleinigkeiten. Unterm Strich hat mit der Event sehr gut gefallen. Ich habe auch ansonsten nur positive Stimmen gehört. Gratulation und Dank an das Event-Team Alexander Groß, Stefan Lieser, Torsten Weber!

Die Teilnehmer können es nicht lassen. Auch nach Stunden des Networkings während der Gruppendiskussionen setzen sie die Gespräche bei der Abendveranstaltung in einer gemütlichen Leipziger Kneipe fort. Foto: Kurt Häusler.

ADC 08 - Runden auf einem runden Event

Das hat Spaß gemacht! Runden drehen auf der ADC 2008. Mit einem Segway! Zuerst im Schildkrötenmodus mit nur 9km/h, dann mit 20km/h. Huiiii... das ging ab auf dem Parkplatz des Veranstaltungsortes in Frankenthal. Eine Leichtigkeit des Fahrens, die man nicht vom Fahrrad oder Auto kennt. Denn ein Segway-Gefährt lässt sich so einfach Steuern wie die eigenen Beine: total intuitiv. Eine kleine Gewichtsverlagerung in die Wunschrichtung und schon ändert der Segway seinen Kurs. Vor, zurück, auf der Stelle - und dann auch Treppen runter :-)

Mit dem Segway hatte Hannes Preishuber als Veranstalter der ADC 2008 ein glückliches Händchen für einen Hingucker, ein Gimmick, das Techis begeistert. Weiter so! Auf der ADC 2009 sollte es ein paar mehr Segways geben und einen Parcours zur Entwicklung der Fahrgeschicklichkeit...

Doch nicht nur die Runden mit dem Segway haben die ADC 2008 zu einem runden Event für mich gemacht. Die Stimmung der Teilnehmer war gut, der Abendevent launig - mit einem Quiz, bei dem angesichts des ganzen Neuen auch mal solide Kenntnisse frührerer Technologien wie GWBASIC gefragt waren.

Das Fachliche kaum auch nicht zu kurz. Keine Sorge. Neno Loje und Bernd Marquardt hatten in bewerter Manie ein solides Programm zusammengestellt - das zeitgemäß einiges in punkto Parallelprogrammierung zu bieten hatte.

Dazu habe ich auch beigetragen mit einem Vortrag zum Thema Microsoft Concurrency Coordination Runtime. Asynchrone Programmierung liegt mir grad sehr am Herzen. Der zweite Vortrag drehte sich um Unit Tests mit Attrappen (Mock Objects). Und dann habe ich spontan noch die Herausforderung angenommen, die Keynote zu halten. Neno hatte mich am Wochenende angerufen, ob ich für den kurzfristig verhinderten Frank Fischer von Microsoft einspringen könnte mit einem architekturorientierten Thema. Auch wenn ich dafür dann etwas improvisieren musste, bin ich doch ganz zufrieden mit dem Vortrag. Er gab mir die Chance, die Notwendigkeit zu einem Bewusstseinswandel vom synchronen zum asynchronen Denken bei der Planung von Software darzustellen. Keynotes sollen ja nicht so technisch sein ;-)

Wer mag, kann sich den Beispielcode der Attrappen- und CCR-Vorträge hier herunterladen. Enjoy!

Nachtrag:

Hier der Beispielcode der Architektur-Workshop Tage zum Download:

• Workshop am Mittwoch, 15.10.2008
• Workshop am Donnerstag, 16.10.2008

Mehr Warum statt Wie - Vom Wert der Informationen aus erster Hand [OOP 2008]

Was macht eigentlich den Einstieg in neue Technologien oft so schwierig? Ja, da ist natürlich immer ein Zeitproblem. Unter Projektdruck sich auch noch mit Neuem zu beschäftigen, ist schwierig. Aber wenn wir davon einmal absehen, nur für einen Moment... denn Projektdruck macht ja alles schwierig.

Also: Was macht den Einstieg in Neues oft schwierig? Ich glaube, es liegt daran, dass die, die das Neue verkünden, sich zuwenig Zeit für das Warum nehmen. Sie sind viel mehr daran interessiert, das Wie darzustellen. Die Gründe dafür sind vielfältig: Das Wie ist schillernder, positiver, als das Warum, bei dem ja immer das Problem mitschwingt. Das Wie ist womöglich auch leichter zu verstehen und/oder zu vermitteln. "So geht das mit ADO.NET!" ist doch viel simpler als "Das sind die Probleme beim Datenbankzugriff bisher und in naher Zukunft, deshalb muss der neue Weg folgende Eigenschaften haben..." Und schließlich will das Publikum doch eh nur das Wie kennen, um endlich mit dem Neuen auch besser zu werden - oder?

Das sind alles plausible Gründe, so scheint mir, warum wir immer mehr vom Wie hören, statt vom Warum. Aber ist das denn auch gut? Nein. Das Neue - die nächste Datenzugriffstechnologie und das nächste Kommunikationskonzept usw. - erfordert ja immer Veränderung. Bisheriges muss zugunsten des Neuen aufgegeben (oder zumindest verändert) werden. Bei Veränderungen wollen Menschen jedoch ein Wörtchen mitreden. Sie wollen sich nicht herumkommandieren lassen. Sie wollen verstehen, sie wollen abwägen, sie wollen es sacken lassen, sie wollen auch selbst entscheiden können.

Wer da aber vor allem das Wie predigt, ignoriert diese Bedürfnisse. Das Wie transportiert nur versteckt das Warum und behindert somit das Verständnis. Das Wie lässt keinen Raum für Alternativen und beschneidet somit den Wunsch nach Entscheidungsspielräumen. Und so bietet das Wie wenig Wachstumanreiz für die Motivation zur Veränderung.

Wer zu Veränderungen anregen will, der beginne also immer mit dem Warum, mit dem Problem. Je klarer er das Problem kommunizieren kann, je mehr Verständnis für das Problem im Publikum ist, desto wirksamer später die Präsentation der Problemlösung, des Neuen. Das ist mir gerade auch nochmal bei Lektüre von "The Art of Change" deutlich geworden.

Vor einiger Zeit hatte mich diese Erkenntnis allerdings schon einmal umgetrieben; damals war sie allerdings noch etwas dumpfer, intuitiver. Da habe ich nämlich überlegt, was mir in der Ausbildungslandschaft fehlt. Wie würde ich gern etwas lernen? Wie würde ich z.B. in eine Evaluation eines Konzeptes oder einer Technologie einsteigen? Und die Antwort auf diese Fragen war: Ich möchte natürlich am Ende das Wie erfahren, aber ich möchte vor allem zuerst mehr über das Warum erfahren.

Wenn ich schon mehr zu einem Konzept oder einer Technologie hören möchte, dann habe ich zwar schon ein grundsätzliches Problembewusstsein. Sonst würde ich ja keinen Drang verspüren, etwas darüber zu lernen. Aber ist mein Problem denn wirklich auch das Problem, welches Konzept bzw. Technologie lösen? Vielleicht wünsche ich mir das ja nur, aber missverstehe sie. Also sollte ein Lehrer nicht einfach mein selbstverständliches Wie-Bedürfnis stillen, sondern zunächst (bzw. auf Wunsch) ausführlich alle Facetten des Warum dahinter (er)klären.

Was ist das Problem hinter ADO.NET? Warum sieht dieses oder jenes bei ADO.NET so und nicht anders aus? Was ist das Problem hinter der Microsoft CCR? Warum sieht sie dann so und nicht anders aus? usw.

Wer könnte nun aber am besten das Warum erklären? Wer könnte am besten die Notwendigkeit zur Lösung von Problemen rüberbringen? Wer könnte die Beweggründe hinter den konkreten Ausprägungen des Wie optimal darlegen? Effizientes lernen - die ewige Anforderung derjenigen unter Projektdruck - fordert ja, dass man von den Besten lernt. Wer sind also die Besten, um nicht nur das Wie, sondern auch das Warum zu erklären?

Von wem würde ich also gern lernen? Das war damals die Frage, die mich im Anschluss umtrieb. Als Antwort sind mir dann Daniel Düsentrieb und Doc Brown von "Zurück in die Zukunft" eingefallen. Die sind vielleicht ein bisschen spinnert - aber sie sind genial und wissen es am besten. Eine Erfindung möchte ich mir am liebsten vom Erfinder erklären lassen. Er soll mir Rede und Antwort stehen. Er kennt das Problem auf dem Effeff, denn sonst hätte er keine Lösung erfunden. Und er weiß, warum die Lösung so aussieht, wie sie aussieht, sonst hätte er sie nicht so gestaltet.

Zwar ist der Erfinder auch immer stolz auf seine Erfindung, aber das macht nichts, finde ich. Soll er auch sein. Denn dann ist er mit Energie dabei, die auf mich überspringen kann. Ich höre mir also zunächst einmal lieber einen Erfinder an, als einen Übersetzer. Unabhängigkeit und Außensicht sind auch wichtig; aber wenn ich erstmal etwas verstehen möchte, dann brauche ich Einsicht und Tiefblick - wenn es irgend geht. Und die bietet mir vor allem der Erfinder höchstpersönlich.

Daraus ist dann eine Idee erwachsen, die inzwischen sogar umgesetzt ist. Aus dem Wunsch heraus, von den Besten, von den Erfindern zu lernen, habe ich mir sozusagen mindestens für mich selbst, aber natürlich auch für alle anderen, die an Einsicht und Tiefblick interessiert sind, eine Workshop-Reihe kreiert. Sie heißt - soviel Englisch muss schon sein in unserer Branche, oder? - "Straight from the Horse´s Mouth" (SFHM), was soviel bedeutet wie "Informationen aus erster Hand". Im Microsoft-Umfeld ist diese Redensart immer dann in Gebrauch, wenn man z.B. für eine Konferenz darüber nachdenkt, einen Referenten von Microsoft aus Redmond einzufliegen. Das Argument dafür lautet dann "Da hören wir es dann straight from the horse´s mouth, das hat doch besonderen Wert für die Teilnehmer."

Warum aber immer nur Microsoft? Außerdem ist es schwer, Erfinder von Microsoft-Technologie zum Reden zu bringen. Erstens passiert dort viel in Teams, zweitens sind die Teams groß, drittens sind Erfinder heißbegehrt und damit oft nicht verfügbar.

Es muss auch nicht immer Microsoft sein. Es gibt soviele Konzepte und Technologie, die nicht von Microsoft stammen und dennoch oder gerade deshalb Wert sind, einen näheren Blick drauf zu werfen. Und so finden sich in der Workshop-Reihe bisher gerade keine Microsoft Produkte, sondern solche, denen ich a) mehr Aufmerksamkeit wünsche und bei denen b) der Erfinder oder Chefentwickler selbst klar erkennbar ist und sich auch noch mitteilen will und kann. Bei Professional Developer College haben wir die Reihe also mal begonnen mit:

db4o ist ein objektorientiertes Datenbanksystem, Open Source und meiner Meinung nach bei zuwenigen Projekten auf dem Radar, wenn es um Objektpersistenz geht. Deshalb ein SFHM-Workshop für db4o.

Vanatec bietet mit OpenAccess (VOA) einen ausgereiften O/R Mapper quasi der ersten Stunde. Auch wenn jetzt Microsoft mit Linq to Sql uns alle überrollt, ist ja aber die Microsoft-Lösung nicht der Weißheit letzter Schluss. Es lohnt sich also, die Alternativen zu evaluieren. Und warum dann nicht einen soliden Mapper anschauen, der viele Konzepte bietet, die Linq to Sql nicht in petto hat - und dann auch noch mit dem Chefentwickler selbst sprechen? Deshalb ein SFHM-Workshop für VOA.

Ranorex ist ein Automatisierungswerkzeug für UI-Tests. Nicht-visuellen Code automatisch mit NUnit & Co zu testen, hat inzwischen ja schon ziemlich die Runde gemacht. Viele tun es schon. Aber UI-Tests zu automatisieren, das ist nochmal ein anderer Schnack. Aber Ranorex kann das. Und zwar ziemlich intuitiv gerade für .NET-Entwickler. Ranorex erzeugt nämlich Testscripte in .NET-Sprachen bzw. ermöglichst die UI-Fernsteuerung aus .NET-Code heraus. Sehr cool! Und dann entwickeln das auch noch Leute in Österreich. Vater und Sohn - und inzwischen mit einem ganzen Team. Deshalb ein SFHM-Workshop für Ranorex, bei dem der Erfinder und Chefentwickler das Tool selbst erklärt.

Ich glaube fest daran, dass - woimmer es geht - die Information aus erster Hand erstmal die beste ist. Mit der sollte man Anfangen. Sie vermittelt ein Maximum an Hintergrundinformationen, Problemstellung und Warum. Deshalb SFHM. Und dann... später, ja, später kommen dann unabhängige Meinungen dazu. Das ist gut und wichtig. Aber davon haben wir ja genügend zu den meisten Themen.

Ich bin froh, dass ich die Chance ergriffen habe, eine Erkenntnis so in eine Tat umzusetzen. Nun bin ich gespannt, ob das auch anderen nützt...

Die Steigerung des Superlativs - oder: Rekursive Veranstaltungsprofilierung

Gerade flatterte mir der Flyer der nächsten Auflage eines bekannten deutschen .NET-Entwicklerevents ins Haus. Dass es in 2008 noch andere Veranstaltungen neben dem Hypermegasuperevent von Microsoft Deutschand anlässlich des Launch von VS2008 & Co geben könnte... das hatte ich schon fast nicht mehr auf dem Zettel.

Und auch der Veranstalter schien Mühe zu haben, sich mit der "Übermacht" zu arrangieren. Was bleibt denn auch noch zu sagen, wenn Microsoft drei Tage lang ein Feuerwerk zu .NET 3.5, VS2008, SQL2008, Windows Server 2008 und auch noch Sharepoint abfackelt? Da fällt die Profilierung auch eines etablierten technologieorientierten Events schwer.

Aber... der Veranstalter hat für sich einen Weg gefunden. Gibt es doch nichts Gutes, was nicht noch besser werden könnte, oder? In der Vergangenheit hat das ja auch schonmal funktioniert. Früher, in den 1990ern, da ging es bei Entwicklerveranstaltungen "nur" um Technologien und vielleicht mal um "Tipps und Tricks". Das war dann in den Jahren nach 2000 nicht mehr genug. Mehr Events stellten mehr Technologien vor. Wie also sich profilieren? Klar, Technologien kann jeder - aber nicht jeder kann sie auch wirklich gut einsetzen, hat wirklich, wirklich Erfahrung mit ihnen. Wohl also dem, der die besten (!) Wege zu ihrem Einsatz vermittelt. Und schon waren nicht mehr einfach nur Technologievorträge auf den Entwicklerveranstaltungen angesagt, sondern "Best Practice"-Demonstrationen. Ging es vormals um den Einsatz oder vielleicht sogar guten/richtigen Einsatz von Technologien, so zeigte man nun nicht weniger als ihren besten! Auf gut folgte also nicht besser, sondern gleich am besten. Wer will sich auch schon mit dem Komparativ abgeben, wenn man doch den Superlativ in der Tasche hat?

Nur, was kommt nach dem Superlativ? Früher wurde der Begeisterung mit Qualifikationen wie "toll" und "super" Ausdruck verliehen. Darauf folgte dann in den 1990ern "mega". Für die Zukunft bieten sich "giga", "tera" und "peta" an ("hyper" ist nicht wirklich salonfähig, oder?); um 2057 werden die Medien deshalb wohl vom "Peta Musikevent des Jahrtausends" berichten, wenn die altersgreisen Jungs (?) von Tokio Hotel auf die Bühne gerollt werden - oder so.

Die Veranstaltungen für die .NET-Community dürfen diese Entwicklung natürlich nicht an sich vorüberziehen lassen. Profilierung tut Not. Mit Microsoft Elefantenevent und auch ohne. Mit einem simplen "giga", "tera" usw. zur Qualifikation des eigenen Programms ist es aber natürlich nicht getan. Das wäre für diese Branche zu naheliegend. Der findige Veranstalter, dessen Flyer ich ins Haus bekam, hat sich daher eine ganz andere Strategie zur Steigerung einfallen lassen.

Seine Agenda enthält nicht mehr nur "Best Practice"-Vorträge. Nein, bei ihm gibt es jetzt... "Best of Best Practices"! Der grammatikalische Superlativ wurde durch eine Anwendung auf sich selbst auf eine neue Ebene gehoben: Das Beste vom ohnehin schon Besten wird es zu sehen und zu hören geben!

Welch ein Einfall! Er ist der Branche wahrlich würdig! Denn die Anwendung des Besten auf das Beste ist ja quasi eine Rekursion: p2008 = Best(Best(p2007));

Damit ist auch die ultimative Formel für alle Zukunft gefunden. Es gibt nun kein Profilierungsproblem mehr. Denn die Formel lautet für 2009 ganz einfach: p2009 = Best(Best(Best(p2007))); Ende nächsten Jahres werde ich also wohl einen Flyer im Postkasten haben, auf dem steht "Best of Best of Best Practices". So ist man Microsoft - und allen anderen - immer einen Schritt, äh, eine Rekursion voraus. Brilliant! Beneidenswert!

Oder...

Vielleicht auch nicht. Denn eine (grammatikalische) Steigerung bedeutet ja auch immer eine Filterung. Die Menge des Besten - wie z.B. in Best Practice - ist immer eine Untermenge des Vorhandenen oder des schon Guten. Wenn dann vom Besten wieder nur das Beste genommen wird... dann schrumpft die Menge weiter.

Was bedeutet das für einen Event, der im Umfang ja aber nicht schrumpfen will und kann? Es bedeutet, dass er eben nicht wirklich dem Motto "Nur das Beste vom Besten" treu sein kann. Schade.

Schade, dass die Profilierung nur über eine Steigerung versucht wird. Das ist wie bei den "Rabatt" und "Sonderpreis" und "Sale" Schildern in den Schaufenstern allerorten heutzutage. Nur der Preis zählt. Nur die besten Best of Best Practices zählen. Als gäbe es nichts außer Best Practices - von denen wir ja übrigens schon seit knapp 3 Jahren zum Thema VS2008 aka Oracs hören. Irgendwann müssen sie doch mal alle vermittelt worden sein die Best Practices und damit auch die Best of der Best Practices, oder?

Aber ich verstehe schon. "Best Practices" hört sich ja auch für die Zielgruppe immer wieder, immer noch höchst attraktiv an. Wer will denn schon selbst durch die Niederungen des Technologiekompetenzerwerbs gehen? Besser, man kann auf dem Erfahrungsniveau von Best Practices einsteigen. Und noch besser, man kann bei den Best of Best Practices einsteigen. Oder?

Am Ende aber... können auch Best of Best of Best of Best of Practices die eigene Erfahrung nicht ersetzen. Und sie leisten auch immer noch nicht den Transfer auf das eigene Projekt. Denn gewöhnlich werden selbst die Best Practices relativ zusammenhanglos, eben technologieorientiert dargestellt.

Ich würde also sagen: "Best Practices" sind genug. Der Superlativ darin reicht aus. Auf sie nochmal ein "Best of" zu setzen, ist unnötig und verwirrend. Es leistet einem quantitativen Denken Vorschub, das wir hinter uns lassen sollten. Wir brauchen nicht mehr, sondern Anderes. Wir brauchen neue Qualitäten, nicht größere Mengen. Innovationen stecken also leider nicht in "Best of Best of...".

Impressionen von der prio 2007

Nun ist sie gelaufen, die prio conference. Seit dem Frühsommer hatte ich mich gedulden müssen, ob die von mir ausgesuchten Sprecher und Themen vom kritischen Publikum für gut befunden würden. Würde die prio 2007 als Konzeptkonferenz an den Erfolg im Vorjahr anschließen können?

Aber jetzt bin ich entspannt. Das Konzept der prio ist wieder aufgegangen. Schon am ersten Tag bekam ich spontan sehr positives mündliches Feedback von den Teilnehmern. Und auch nach der Konferenz wurden die Teilnehmer über ihre Feedbackbögen hinaus nicht müde, ihrer Begeisterung Ausdruck zu verleihen:

• "Erstmal Glückwunsch zur wirklich gelungenen Konferenz. Die Vorträge die ich gesehen habe fand ich alle gut bis sehr gut.", Boas Enkler
• "Mir hat diese Konferenz viel Spaß bereitet wie auch viel neues Wissen vermittelt und interessante Anregungen gegeben.", Andreas Hönick
• "Die Vorträge und die Organisation waren super.", Jürgen Wäldele

Puh. Da fällt mir ein Stein vom Herzen. Sprecher und Inhalte sind bei den Teilnehmern gut, nein, sehr gut angekommen. Mit der Wahl des Konzeptthemas "Softwarequalität" haben wir also richtig gelegen. Das hat dann zwar nicht ganz die 300 vom Veranstalter Penton gewünschten Teilnehmer anziehen können... aber das hatte ich persönlich auch nicht erwartet. Sich mit "Softwarequalität" zu beschäftigen, erscheint einfach nicht so lohnend wie mit den neuesten Hype-Technologien. Doch die anwesenden Teilnehmer haben deutlich gemacht, dass die prio zurecht darauf gesetzt hat, dass es genügend Entwickler mit Weitblick und Professionalität gibt, die über den Tellerrand der tagesaktuellen Technologien schauen und nach Wegen suchen, die Qualität ihrer Software nicht nur durch ein neues Tool zu steigern.

So sind denn auch eher theoretische Vorträge wie "Architect to test" von Stephan Maier (links) und "Softwarequalität durch das richtige Vorgehen steigern" von Christian Bunse (rechts) gut angekommen, die sich auf den üblichen technologieorientierten Entwicklerveranstaltungen nicht finden.

Das galt übrigens auch für den Softskill-Vortrag, den Renate Klein und ich zusammen gehalten haben. Im letzten Vortragsslot des ersten Konferenztages haben wir ganz untechnisch 75min darauf verwandt, harten Softwareprofis die Wichtigkeit "weicher Kompetenzen" nahezubringen. Mit Erfolg, wie sich herausstellte. Niemand hat den Saal verlassen und wir bekamen anschließend einiges ausdrücklich positives Feedback.

Neben in der .NET Community eher unbekannten, nichtsdestotrotz aber guten Sprechern - als besonders kompetent (wenn auch manchmal angesichts seines sehr französischen Akzents schwer verständlich) habe ich Patrick Smacchia empfunden, der sein Architekturbewertungswerkzeug NDepend vorgestellt hat -, waren aber natürlich auch genauso gute wie beliebte Sprecher wie Christian Weyer (links) oder Dominick Baier (rechts) mit von der Partie.

Das Engagement der Sprecher endete aber nicht - wie sonst üblich - mit ihren Vorträgen! Nein, bei der prio waren die Sprecher auch noch nach der fachlichen Teil der Konferenz für die Teilnehmer da. Bei der Abendveranstaltung am ersten Konferenztag legten sie sich beim Ausschank und beim Servieren im Baden-Badener Löwenbräu mit Bierschürze hinter und vor der Theke ins Zeug.

dotnetpro-Autor Jörg Neumann (link) war sogar eigens für diesen Einsatz angereist. Und Neno Loje (rechts) war - wie man sieht - auch ganz in seinem Element.

Tilman Börner - Chefredakteur der dotnetpro und "Schirmherr" der prio - und ich waren denn auch sehr zufrieden mit dem Einsatz der Sprecher bei Tag und bei Nacht.

Nach der prio ist aber natürlich vor der prio ;-) Und so stürzen wir uns denn auch umgehend in die Planung der nächstjährigen Konferenz. Seien Sie gespannt auf´s Thema... Ich hoffe, wir sehen uns dort.