Synchronizität - Die gläserne Decke der Softwareentwicklung

Im Grunde kann man alle Probleme durch synchrone und sequenzielle Verarbeitung lösen. Das dauert dann manchmal zwar ein wenig, aber es geht. So bringt es uns auch jeder Programmierkurs bei. Ein Befehl folgt auf den anderen. Ein Unterprogramm ruft das nächste und wartet auf dessen Ergebnis, bevor es selbst weitermacht. Unterprogramme sind insofern fast nur syntactic sugar, denn ihr Code könnte auch am Aufrufort eingesetzt stehen. Compiler tun auch genau das, wenn es ihnen angemessen erscheint. Das heißt dann Inlining.

Was aber, wenn so eine sequenzielle Verarbeitung zu langsam ist? Na, dann macht man sie halt schneller, indem man den Algorithmus verbessert (z.B. Quick Sort statt Bubble Sort) oder einen schnelleren Prozessor kauft. Das ist dann so, als würde man einen schmächtigen Maurer ins Fitnessstudio schicken, damit er in Zukunft schneller Steine schleppen kann. Oder man ersetzt ihn gleich durch ein Förderband.

Wie effizient kann eine Implementation aber werden? Irgendwann ist der beste sequenzielle Algorithmus implementiert. Wie schnell können Prozessoren werden? Irgendwann ist da eine physikalische Grenze erreicht - wie es gerade so um die 3-6 GHz zu sein scheint.  Genauso ist es mit der Kraft bei Maurern und der Schnelligkeit von Föderbändern. Da gibt es einfach ein Ende der Fahnenstange. Dann hilft nicht mehr Quantität. Nein, dann muss sich die Qualität ändern.

Angekommen ist das in der Programmierausbildung aber eher noch nicht, würde ich sagen. Denn es herrscht immer noch das Denken in synchronen und sequenziellen Abläufen vor, die man eben versucht durch quantitative Einflussnahme zu beschleunigen. Weniger Instruktionen oder schnellere Prozessoren stehen als Wunschvorstellung hinter den Klagen darüber, dass mal wieder der Aufbau eines Fensters zu lange dauert oder die Datenbank zu langsam ist.

Dabei wussten schon die alten Ägypter, dass man Pyramiden nicht schneller baut, indem man die Arbeiter erstmal ins Bodybuilding-Studio schickt. Die Pyramiden wurden von normalen Einwohnern Ägyptens gebaut. Genauso wie der Otto Versand vor allem Durchschnittsmenschen zur Bewältigung aller durch Menschen durchzuführenden Tätigkeiten einstellt. Sowohl die Ägypter wie der Otto Versand müssen halt damit leben, dass es vor allem normale Menschen gibt. Das liegt in der Definition von normal. Exzeptionelle Menschen - besonders starke, schnelle oder kluge - gibt es nur vergleichsweise wenige. Man kann sie daher nicht in größerer Menge rekrutieren und schon gar nicht bezahlen.

Die Lösung für Geschwindigkeitsprobleme liegt daher nicht im scale-up, in der Effizienzsteigerung von etwas Einzelnem, d.h. einem Arbeiter, einem Förderband, einem Rechner.

Die wahre Lösung liegt vielmehr in der Parallelisierung. "Normale" Ressourcen gleichzeitig an einer Aufgabe arbeiten zu lassen - z.B. viele normale Ägyptische Bauern an einer Pyramide oder Hamburger Bürger beim Otto Versand -, ist letztlich der weiter führende Weg, um dauerhaft schnell zu sein.

Beim scale-out stehen viele billige Ressourcen nebeneinander und arbeiten parallel an der Bewältigung einer Gesamtaufgabe. Statt viel Zeit in die Optimierung von Algorithmen zu stecken oder viel Geld in eine noch schnellere Hardware, sollten Sie überlegen, inwiefern die abzuarbeitenden Schritte in Ihrer Software parallelisierbar sind.

Das geht nicht, glauben Sie, weil Sie keine riesige ERP-Software für komplexe Geschäftsprozesse schreiben? Sie entwickeln doch nur ein kleines CRM - bei dem allerdings der Programmstart und auch der Wechsel zwischen Bearbeitungsmaske und Suchdialog an Performance zu wünschen übrig lassen.

Aber warum soll den nicht auch in solcher Software, die scheinbar nur aus sequenziellen, synchronen Verarbeitungsschritten besteht, etwas Parallelität möglich sein?

• Beispiel Programmstart: Alles, was beim Programmstart nicht visuell ist (z.B. das Laden von Lookup-Daten), kann parallel zur Anzeige eines ersten Dialogs im Hintergrund passieren.
• Beispiel Suchen: Abfragen können im Hintergrund laufen, während das User Interface weiterhin bedienbar bleibt. Abfrageergebnisse können häppchenweise ans UI geliefert werden; niemand sollte darauf warten müssen, dass auch noch der tausendste Datensatz dem Grid hinzugefügt ist, bevor er weiterarbeiten kann.
• Beispiel Bearbeitungsende: Wenn am Ende der Bearbeitung Daten zu speichern sind, dann kann das parallel zur weiteren Bedienung geschehen. Warum sollte ich als Anwender darauf warten, dass die Daten auch vollständig und korrekt in der Datenbank angekommen sind? Das ist doch selbstverständlich.

Falls Sie diese Beispiele nicht überzeugen, biete ich an, dass ich Ihre Anwendung daraufhin untersuche, wo es Parallelisierungspotenzial gibt. Ich bin sicher, da gibt es einiges zu entdecken.

Warum nutzen wir das große scale-out Potenzial denn aber nicht in unseren Anwendungen? Gelegentlich mag es daran liegen, dass sich ein Algorithmus nicht so leicht parallelisieren lässt. Das halte ich aber für ein Detailproblem. Vor allem sehe ich den Grund nämlich in einem Mangel an 1. Bewusstsein und 2. einfacher (!) Technologie.

Sie können Programmteile heute selbstverständlich parallel machen. Asynchronizität ist natürlich möglich. Aber sie ist trotz aller Bemühungen der .NET-Framework-Entwickler noch nicht wirklich, wirklich einfach. Auch sind die Lösungen verteilt: ein bisschen steckt in System.Threading, ein bisschen in der CCR, ein bisschen in WCF usw.

Ich halte daher eine Konsolidierung für geboten. Das, was an Technologieschnipseln vorhanden ist, sollte unter einem intuitiven, einfach einzusetzenden Dach zusammengefasst werden. Dazu müsste dann aber wohl noch etwas Theorie kommt. Wir müssen Software erstmal aus grundsätzlich asynchronen Bausteinen zusammengesetzt denken.

Aber ich sehe Licht am Horizont... :-) Mit einem Architekturansatz wie "Systemorientierten Programmierung" (SOP) und einer Zusammenführung von DI Frameworks mit Enterprise Service Bus (ESB) und Space Based Computing/Architecture (SBC/SBA) könnte es besser werden. Bei SOP stehen Softwarezellen als asynchrone und verteilte Codeeinheiten am Anfang, so dass das Denken in Richtung mehr Parallelität und flexibler Architekturen geleitet wird. Und eine Vereinigung von EDA-Konzepten (Event Driven Architecture) könnte das Hosting und die Kommunikation von Softwarezellen vereinfachen - im Großen wie im Kleinen (innerhalb von Prozessen).

Aber davon ein andermal... Einstweilen Achtung vor der gläsernen Decke "Synchronizität"! Synchrone Verarbeitung durch scale-up zu beschleunigen, führt nicht immer so weit, wie Sie denken mögen.

Neues Blog zum Thema Softwarearchitektur - The Architect´s Napkin

So, nun kann ich es nicht länger aufschieben. Ich muss einfach mal meine Ideen zum Thema Softwarearchitektur zusammenfassen. Immer wieder fragen mich meine Beratungskunden, ob ich nicht ein Buch für sie hätte, in dem sie das, worüber wir sprechen und was wir gemeinsam üben, nachlesen könnten.

Nicht, dass ich nicht schon über meine Ideen oder gar meine "Methode" geschrieben hätte. In meinem englischen Blog hatte ich die Softwarezellen eingeführt, hier im deutschen Blog dann "Software als System". In der dotnetpro beschreibe ich auch immer wieder Aspekte der Softwarearchitektur. Allein ein Ort, an dem alles gesammelt zu finden ist, fehlte bisher. Das soll nun mit meinem neuen Blog The Architect´s Napkin - "Des Architekten Serviette" anders werden. (Sorry, ich sah mich genötigt, es auf Englisch zu verfassen, da ich nur so die Chance habe, eine größere Leserschaft zu finden, die vielleicht mit mir auch über dieses wichtige Thema und meinen Ansatz diskutiert.)

In dem Blog entwickle ich meine Ideen nochmal von Grund auf, fasse zusammen, was ich bisher schon geschrieben habe und füge dann natürlich auch Neues, Unveröffentlichtes hinzu. Die Reihenfolge ist dort lose - Theorie und Praxis werden sich abwechseln -, aber der Fokus ist klar. Ich habe sozusagen meine Blog-Aktivitäten ein weiteres Mal partitioniert bzw. refaktorisiert. So steigt die Kohäsion, die thematische Nähe in den jeweiligen Blogs.

Unmittelbaren Anstoß für diese Aktion war die Lektüre von "The Back of the Napkin", das mit klar gemacht hat, wie wichtig Visualisierungen sind und wie wichtig darüber hinaus einfache Visualisierungen sind. Denn Architektur scheint auch immer schwieriger als nötig wahrgenommen zu werden, weil eine diffuse Angst herrscht, ob man denn auch alle Darstellungsansprüche erfüllen kann.

Dem und jedem anderen Nimbus von Softwarearchitektur als Elfeinbeinturmkunst werfe ich deshalb mit einer sehr konsequent minimalistischen Darstellungsweise entgegen: alle Architekturdiagramme finden Platz auf einer Serviette.

Das sieht dann z.B. so aus

oder so

Des Gedanke dahinter: Wenn etwas nicht auf eine Serviette in übersichtlicher Weise passt, dann ist es schon zu kompliziert. Architekturdiagramme sollen nicht nur gezeichnet, sondern vor allem verstanden werden. Deshalb sollten Softwarearchitekten darauf achten, ihre Gesprächspartner nicht mit visuellen und konzeptionellen Details zu überfordern.

So meine These, die ich versuchen werde, mit meinem Blog zu bestätigen. Ich würde mich freuen, wenn Sie mitlesen und mitdiskutieren würden. Bis bald bei...

The Architect´s Napkin

Ich würd so gern, aber... - 4 Gründe gegen das "aber" zum Schreiben

Auf mein gestriges Posting für mehr Klarheit und Nutzen bei Zeitschriftenpublikationen hat mir ein allseits bekannter "Community Thought Leader" betroffen und zerknirscht wie folgt geschrieben:

... die alte Leier... wie gerne würde ich mehr schreiben - ich (und andere freilich auch) habe so viel zu erzählen (Bezug nehmend auf dem Kommentar von Haggy).
Nur fehlt inmitten der Projekte einfach die Zeit qualitativ hochwertiges Material zu produzieren. Und mit dem (auch von Dir angesprochenen) Vergütungsmodell haut das eh' nicht hin.

Und die Artikel bzw. Autoren, die derzeit schreiben (also ich überfliege die dnp derzeit nur), kann man leider echt in der Pfeife rauchen (prominente Ausnahmen bestätigen diese Regel ;)).
Warum? Weil die "anderen", etablierteren scheinbar damit beschäftigt sind, Licht ins Dunkel all dieser auftretenden Fragen zu bringen - und zwar vor Ort in den Projekten, nicht im WORD Doc.

Glaube, ich denke oft drüber nach, wie man hier einen Kompromiss finden könnte - ich bin (noch) zu keiner Lösung gekommen.

Mich hat es sehr gefreut, dass da jemand sofort reagiert hat, den ich also Kompetenzträger und auch als Autor sehr schätze. Das ist doch schonmal ein Ansatz. Ihm ist die Situation nicht egal, aber er sieht keinen Ausweg. Das System scheint unveränderbar. Eine sehr nachvollziehbare Haltung. Wenn sich alles so schnell bewegt, wie soll man da innehalten und den Kurs neu bestimmen. Schon das, geschweige denn zu schreiben, kostet wertvolle Projektzeit.

Nachstehend meine Antwort an den Experten, mit der ich ihm in dieser eingefahrenen Situation einen Impuls geben möchte, um etwas zu verändern. Ich publiziere sie nun auch hier, weil ich denke, dass andere ebenfalls ein solches Dilemma spüren. Vielleicht kann ich auf diese Weise mehr Experten ermuntern, es mit der Publikation (wieder) zu versuchen. Und auch mehr ist möglich. Wir können uns auch zusammen tun, um konzertierter etwas zu bewegen. Mag altmodisch klingen, so nach 19. Jahrhundert ;-) Aber ist in Zeiten von Web und Flash Mob eigentlich hoch aktuell.

Also, hier meine Gedanken als Antwort auf die obige Email:

Freut mich, dass du dir diese Gedanken machst.
Und glaub mir, ich kann verstehen, dass du immer wieder so entscheidest, wie du es tust: für das Projekt, gegen den Artikel.

Aus mehreren Gründen halte ich das dann aber doch für die zweitbeste Entscheidung :-)

1. Erfolg: Publikationen bringen Sichtbarkeit. Sichtbarkeit bringt Aufträge.
Nun kannst du sagen, dass du mehr Aufträge nicht gebrauchen kannst. Aber deine Firma ist ein Unternehmen, dass früher oder später wachsen will und/oder muss.
Das ist dann leichter, wenn alle oder wichtige Mitglieder von deiner Firma breit sichtbar sind.

2. Effektivität und Skalierbarkeit: Publikationen verbreiten die Frohbotschaft. Sie nutzen dem guten Thema.
Wenn du von einem Thema überzeugt bist und gar noch denkst, dass andere darüber ungenügend berichten, dann kann dir nur am Herzen liegen, darüber zu publizieren. Du erreichst einfach mehr Menschen. Publikation ist effektiver als referieren oder gar in einem Projekt zu sitzen.
Solltest du also ein Sendungsbewusstsein haben, dann kommst du an Publikationen nicht vorbei, um es zu befriedigen.

3. Qualitätssicherung: Publikationen dienen nicht nur dem Lehren, sondern auch dem Lernen.
Wie in meiner letzten dotnetpro Sandbox ausgeführt, lernst du bei Publikationen immer selbst etwas. Du selbst wirst durch das Publizieren besser. Du denkst nach, du ordnest, du forschst. In projekten oder für vorträge tust du das auch. Publikationen sind aber ein Mittel, mit dem du dich noch weiter bringen kannst. Darin formulierst du aus, du legst dich also mehr fest, als in einem Vortrag. Das hat Wert für die Sicherheit deiner Aussagen. Du gehst nämlich bewusster mit ihnen um. In einem Vortrag mal etwas ausprobieren und "so daher sagen" ist gut. In einer Publikation "gewählter sprechen" ist aber auch gut. Der Mix machts.

4. Ganzheitlichkeit: Schreiben führt zu einer ausgewogeneren persönlichen Entwicklung Der Mensch ist mehr als Körper und Arbeit. Deshalb lieben wir die Romantik und die Freizeit. Aber auch innerhalb der Arbeit ist der Mensch mehr als Technik. Wenn du dich durch Lesen und Ausprobieren und Projekte weiterbildest, dann ist das gut und unverzichtbar. Du nimmst auf und produzierst. In Vorträgen und Diskussionen gibt du dann weiter. Ohne Bilder oder Texte bleibt das aber doch recht einseitig. Du arbeitest vor allem linkshemisphärisch. Das funktioniert wie wir sehen ;-) Mit einem Ausgleich würde es aber - so meine These - noch besser sein. Es würde sich besser anfühlen, befriedigender sein. Du wechselst ja auch zwischen Schreibtisch, Sport, Familie. Warum nicht auch zwischen analytischer und kreativer Arbeit wechseln? Programmieren ist auch kreativ. Aber Bilder finden - gezeichnete oder beschriebene - wie bei der Arbeit an einem Text, das ist noch anders kreativ. Das ist eher rechtshemisphärische Arbeit. Mit mehr Publikationen würdest du also auch innerhalb deiner Arbeit ganzheitlicher leben. Das kann nur von Vorteil sein, meine ich. (Ist es nicht verwunderlich, dass viele (oder gar die meisten?) Exzellenten in ihrem technischen/abstrakten Fach auch eine ausgeprägte musische Seite unterhalten (haben)? Schreiben gehört auch auf diese musische Seite.)

Na, wie ist das als Motivation, doch mal wieder mehr zu schreiben? Wir alle würden uns freuen.

Und was das Finazielle angeht... ja, das ist vergleichsweise unmotivierend. Aber auch da lässt sich was machen:

a. Wenn du die obigen Vorteile in Anschlag bringst, ist ein monetärer Lohn der Mühe vielleicht nicht mehr sooo ausschlaggebend, um dir das Schreiben schmackhaft zu machen. Vielleicht kannst du (erstmal) mit einem Kompromiss leben.

b. Die Autorenhonorare sind unterschiedlich und verhandelbar. Bücher werden schlechter als Zeitschriftenartikel bezahlt. Also dann vielleicht mehr in Magazinen als in Büchern publizieren? Und Zeitschriftenhonorare sind verhandelbar. Vielleicht also mal verhandeln.

c. Jenseits einer individuellen Verhandlung kann sich das System ja auch vielleicht verändern. Autoren könnten sich zusammen tun und mehr Honorar fordern. Leser könnten bessere und mehr Autoren fordern und bereit sein, mehr zu zahlen (statt immer nur wieder nach Gratisangeboten zu googlen). Feedback könnte zu Publikationen erfragt werden, um Honorarforderungen zu rechtfertigen oder zu entkräften.

Ich denke, das Honorarsystem muss nicht so bleiben, wie es ist. Bis zum Beweis des Gegenteils glaube ich, dass Leser bereit sind, guten Content auch zu bezahlen. Produziere also gute Publikationen, dann bekommst du auch ein angemessenes Honorar. Früher oder später ;-) Lass uns gern mal über Strategien reden.

Irrweg Advertorial oder: Wo bleiben Nutzen und Klarheit?

Grad hab ich das aktuelle dot.net Magazin 7/8 2008 gelesen und will meine Verstimmung doch einmal äußern. Verstimmt hat mich nämlich der Artikel "Geschäftsregeln für alle" auf Seite 110. Sein Thema ist die Rules Engine ILOG Rules 3.0. Autor ist Jochen Reinelt. Und Jochen Reinelt ist... Angestellter des Herstellers von ILOG Rules, der Firma ILOG.

Nicht, dass das dot.net Magazin diesen Umstand verheimlicht hätte. Die Autorenbeschreibung zeigt das Eigeninteresse des Autors an einer positiven Produktdarstellung auf. Dennoch verstimmt mich der Artikel. Das hat mehrere Gründe:

• Zum einen ist die Darstellung eines Produktes durch den Hersteller immer Werbung. Werbung ist ansonsten in Publikationen immer klar erkennbar oder zumindest gekennzeichnet. Wo sie die Grenze zum redaktionellen Inhalt überschreitet - was legitim ist -, ist sie sonst gewöhnlich mit "Advertorial" überschrieben. Im OBJEKTspektrum gibt es dafür viele Beispiele. Gegen solche Inhalte vom Hersteller ist erstmal auch nichts zu sagen - nur eben halte ich sie für kennzeichnungspflichtig. Der flüchtige Leser bekommt sonst den falschen Eindruck sowohl von der Produktdarstellung wie von der Publikation.
  
• Dann ist da noch der Hub. Grundsätzlich finde ich es nicht schlimm, wenn Hersteller über ihre Produkte sprechen. Wir alle hören gern Microsoft O-Töne. Warum also nicht von anderen Herstellern auch O-Töne? Es verstimmt mich deshalb auch nicht ein O-Ton von ILOG, sondern die Art des O-Tons. Er ist nicht gekennzeichnet - aber vor allem addiert er nichts zu einem Prospekt des Produkts hinzu. Das, was in dem Artikel steht, kann ich auch online lesen. Der Artikel hat damit keinen Hub; er hebt mich nicht über das hinaus, was ich mir auch ohne Probleme anderweitig an Informationen beschaffen kann. Ein kleiner Kasten mit zwei Links zu schon vorhandenem Material auf den ILOG-Seite hätte denselben Effekt gehabt. Und das halte ich für symptomatisch bei Advertorials.

Wenn ich ein unabhängiges Medium wie das dot.net Magazin, die dotnetpro, iX oder OBJEKTspektrum lese, dann wünsche ich mir Klarheit und Nutzen. Ich möchte klar wissen, welche Interessen die Autoren haben, warum sie also sagen, was sie sagen. Bei einem Autor aus dem Hause des Herstellers lese ich dann anders als bei einem unabhängigen.

Vor allem wünsche ich mir aber Nutzen durch die Lektüre. Der ist aber bei Advertorials gewöhnlich und womöglich sogar absichtlich gering. Advertorials sind und bleiben Werbung. Da hilft auch kein längerer Text im Vergleich zu einer herkömmlichen Werbung.

Liefert mir ein Advertorial keinen Nutzen, dann verschwendet es meine Zeit. Je weniger kenntlich der Werbecharakter - wie im aktuellen dot.net Magazin - desto schlimmer. Eine Werbung überblättere ich und wenn nicht, brauche ich 15 Sekunden, um zu entscheiden, ob ich am Produkt interessiert bin. Das Advertorial kommt anders daher.

Wie gesagt, ich bin nicht gegen herstellereigene Aussagen. Wenn z.B. Andreas Kerl in der dotnetpro 6/2008 über den Windows Installer schreibt, dann ist das auch eine Herstelleraussage, denn Andreas ist Angesteller bei Microsoft. Das macht aber nichts, weil er mit seinem Artikel echten Nutzen über übliches Marketing hinaus bietet. Oder beim Professional Developer College ist der Hersteller O-Ton sogar Programm: in der Seminarreihe "Straight from the Horse´s Mouth" kommen nur Chefentwickler und Erfinder von Technologien zu Wort. Ganz bewusst, denn dort liefern sie Insiderinfos. Sie bieten also sehr großen Hub.

Ein Advertorial jedoch, das Nutzen bietet, habe ich noch nicht gelesen. Nicht im dot.net Magazin, nicht im OBJEKTspektrum. Die dotnetpro ist natürlich auch nicht ganz frei von solcherlei. In Ausgabe 7/2007 schrieb Daniel Zientek von InterSystems über das hauseigene Produkt Caché. Der Artikel ist für mich an der Grenze. Er liest sich nicht ausschließlich wie ein Marketingprospekt, auch wenn er daraus Abbildung bezieht. Die Menge an Code spricht für seinen Willen, anwendbaren Nutzen zu bieten. Dennoch ist zu kritisieren, dass auch hier nicht klar sichtbar gemacht wurde, wer Urheber ist.

Unterm Strich: Advertorials halte ich per se für einen Irrweg. O-Töne sind legitim und sogar wichtig - aber dann bitte schön mit echtem Nutzen und auch ein wenig Distanz. Selbstreflektion und auch Selbstkritik stehen dem Hersteller einer Technologie immer gut zu Gesicht. In jedem Fall sollten O-Töne als solche gekennzeichnet sein. Dann kann es nicht zu Missverständnissen kommen.

Microsoftdämmerung

Ich habe nichts gegen Microsoft. Ich habe sogar alles für Microsoft. .NET 3.5 ist cool. VS2008 ist cool. F# ist cool. VSTO und SharePoint sind cool. Sicher, da gibt es Bugs und Imperfektionen, aber was soll´s? Wer im Glashaus sitzt, wirft besser nicht mit Steinen.

Im Großen und Ganzen fühle ich mich in Bezug auf Microsoft also positiv gestimmt und dennoch unideologisch. Pauschal gegen Microsoft bin ich nicht, wie das Bisherige deutlich machen sollte. Microsoft ist nicht auf der "dunklen Seite der Macht". Pauschal für Microsoft bin ich aber auch nicht. Es gäbe viel zu verbessern am Existierenden, es gäbe viel zu tun, was Microsoft (noch) nicht tut.

Aber auch wenn ich den Eindruck von mir selbst habe, recht neutral zu sein (mal abgesehen von meiner grundsätzlichen Plattformentscheidung für .NET und gegen Java oder C++, was aber nur mit meiner Unfähigkeit zu tun hat, mehr als eine Plattform ausreichen gut zu kennen), so merke ich in diesen Tagen doch, dass ich es de facto nicht bin. Ich leide nämlich an Microsoft Bias.

Microsoft Bias ist eine Erkrankung der Wahrnehmungsorgane.  Sie engt das Blickfeld ein, lässt alles, was Microsoft produziert größer und im Vordergrund erscheinen, andere Entwicklungen erscheinen kleiner, unscharf und nur am Rande. Der Microsoft Bias ist eine schleichende Erkrankung, die insbesondere Entwickler befällt, die über längere Zeit ausschließlich Software mit Microsoft-Werkzeugen entwickeln. Besonders häufig ist der Microsoft Bias bei denjenigen, die ihre Entwicklertätigkeit auf der Microsoft-Plattform vor dem Jahr 2000 begonnen haben.
Der Microsoft Bias ist eine im Regelfall gutartige Erkrankung mit gut Aussichten auf Heilung. Gelegentlich allerdings entwickeln sich daraus Extremformen wie Microsoft Hörigkeit oder Microsoft Hass. Beides sind Persönlichkeitsstörungen, die ein fast kompletter Verlust des peripheren Sehens charakterisiert; damit einher geht die für Persönlichkeitsstörungen typische Krankheitsuneinsichtigkeit gepaart mit unbewussten Abwehrmechanismen wie Rationalisierung und Intellektualisierung. Bei der Microsoft Hörigkeit ist der Erkrankte ganz auf Microsoft fixiert und blendet andere Informationsquellen komplett aus; beim Microsoft Hass ist der Erkrankte ganz auf Technologien und Informationsquellen außerhalb Microsofts fixiert und blendet Microsoft aus.

Microsoft Bias also. Ich nehme vor allem wahr, was Microsoft so tut und sagt. Oder etwas allgemeiner: Ich nehme vor allem wahr, was in der Microsoft nahen Entwicklergemeinde so getan und gesagt wird. Tatsächlich lese ich recht wenig Microsoft O-Ton auf MSDN Online, sondern eher Blogs und Zeitschriften und Bücher, die sich mit Microsofts Ideen und Technologien beschäftigen.

Das ist nun, wie ich festgestellen muss, beschränkend. Nicht wirklich gefährlich also, sondern nur einengend, den Horizont verkleinernd. Bis in die ersten Jahre des neuen Jahrtausends war Microsoft Bias noch nicht als Krankheit diagnostiziert, sondern nach Wahl der Microsoft-Plattform für die Softwareentwicklung quasi ein normaler und unausweichlicher Gesundheitszustand. Rauchen galt ja auch über Jahrhunderte nicht als Sucht, sondern als Vergnügen und Ausdruck aller möglichen positiven Eigenschaften von Geselligkeit über Intellektualität bis zu Tatkraft.

Nun haben sich die Zeiten aber gewandelt. Das Rauchen ist unzeitgemäß geworden. Es lebt der Mensch nun allgemein so lang, dass die Folgen des Rauchens nicht nur ihn, sondern auch die Krankenkassen belasten.

Und genauso unzeitgemäß ist ein Microsoft Bias als Haltung für die Softwareentwicklung selbst auf der Microsoft-Plattform. Es sind die Applikationen bzw. die Anforderungen an den Application Lifecycle so umfangreich, dass Microsoft bei allem guten Willen einfach nicht mehr tonangebend sein kann und sollte. Toll, was Microsoft alles macht und versucht zu stemmen. Aber wo zum Beispiel Phoenix noch im Forschngsstadium ist, da bieten Cecil und PostSharp schon lange produktionsreife Wege, um IL-Code zu verändern. Anderes Beispiel: Microsoft hat keine wirkliche Botschaft zu einem etablierten Thema wie Aspektorientierte Programmierung (AOP) - aber es gibt Tools, die PostSharp oder Spring.NET. Oder noch ein Beispiel: Unit Testing. Inzwischen hat Microsoft Unit Test Features sogar in die Pro-Edition von Visual Studio gepackt - aber das war erstens sehr spät im Vergleich zu den Open Source Alternativen und zweitens ist diese Integration unvollständig. Unvollständig insofern, als dass Unit Testing ohne Code Coverage Analyse schnell ein Lippenbekenntnis bleibt. Mit den VS2008 Pro-Features allein ist also ein Start nicht zu empfehlen. Viel umfassender ist da die Unterstützung z.B. durch TestDriven oder TestMatrix. Beide umfassender als VS2008 Pro in Bezug auf Unit Tests, beide billiger als der Upgrade auf VSTS Developer mit mehr Unit Test Features.

Noch mehr Beispiele gefällig? Wie wäre es mit O/R Mapping? Da wo Microsoft heute mit Linq to Sql ist, waren die Alternativen wie Open Access oder Wilson O/R Mapper oder LLBLGenPro schon vor Jahren. Und es geht noch einfacher wie z.B. Persisor .NET oder db4o zeigen.

Oder wie stehts mit Dependency Injection? Erst in neuester Zeit (April 08) hat Microsoft hier wirklich Brauchbares in Form von Unity geliefert. Andere boten Gleichwertiges schon lange.

Oder wie stehts mit anerkannten Konzepten wie SEDA oder CEP? Von Microsoft ist nichts zu hören. Die CCR ist nur ein Ansatz einer kleinen Truppe, die um Aufmerksamkeit ringt. Was der Markt ansonsten zu bieten hat, erfahren die an Microsoft Bias Erkrankten nicht.  Dabei gibt es ein Entwicklerleben jenseits von Enterprise Services, WCF, WF und BizTalk. Schonmal von NServiceBus oder NEsper oder Jabber gehört? Wo die CCR nur über simple Joins komplexe Events "erzeugen" kann, öffnet NEsper als Event Stream Prozessor ganz neue Möglichkeiten. Da wo die BizTalk Services noch im Teststadium für die Verbindung von Diensten durch Firewalls sind, da ist Jabber schon lange produktionsreif - und Open Source.

Oder als letzte Stichworte statische Quellcodeanalyse und automatische Produktion. Microsoft bietet FxCop und TFS. Das ist nett. Aber viel weitreichender und dynamischer ist z.B. NDepend. Und CC.NET konnte die automatische Produktion schon lange vor TFS. Und FinalBuilder ist viel intuitiver als MSBuild. Oder wie stehts mit Trac oder OnTime? Können die womöglich dasselbe oder gar mehr? Vielleicht nicht so integriert wie TFS, dafür aber zu kleinerem Preis, unabhängig, mit mehr Features und früher als ein Produkt von Microsoft?

Soll ich weitere Bereiche aufzählen, in denen Microsoft nichts oder nur spät etwas bietet, Alternativen aber existieren,  die die "Microsoft Community" - oder sollte ich sagen: die Microsoft Bias Krankengemeinde? -nur wenig weiß? Es gäbe noch einige... Aber einerlei. Die entscheidende Frage ist doch, wie mit dieser Erkenntnis, der Krankheitseinsicht umgehen?

Es ist ja nicht schlimm, dass Microsoft der Entwicklung auch mal hinterherhinkt oder einfach keine Antwort geben will. Das ist völlig legitim. Microsoft ist ein Unternehmen mit wirtschaftlichen Interessen. Die mögen jedoch eben nicht (!) immer mit denen der Entwicklergemeinde übereinstimmen. Wenn Microsoft die eine oder andere Technologie pusht oder das eine oder andere Konzept proklamiert, dann heißt das nicht (!), dass dies dann auch das beste Angebot oder state-of-the-art ist. Kann sein, muss aber nicht. Und ist in Zukunft wahrscheinlich immer seltener der Fall.

Das hat aus meiner Sicht mit der schieren Komplexität des Metiers zu tun. Auch Microsoft kann bei aller Größe eben nicht (!) alle Aspekte der Softwareentwicklung in gleicher Qualität abdecken. Microsoft ist ein Riese, der immer noch einer zentralen Führung bedarf. Solche zentrale Führung ist aber quasi per definitionem nur zur Bewältigung einer gewissen Komplexität fähig. Deshalb wird ja auch die freie Marktwirtschaft in so hohen Tönen gelobt: Sie hat keine Führung und ist daher am flexibelsten. Microsoft agiert nun zwar in einer recht freien Marktwirtschaft, ist aber selbst kein freier Markt. Deshalb kann Microsoft allein eben nicht in allen Bereichen "das beste" bieten. Dafür ist viel mehr Flexibilität nötig, d.h. weniger Direktive und weniger Altlast. Das, was Microsoft auszeichnet - Rückwärtskompatibilität und Verzahnung - ist gleichzeitig auch Microsofts wachsender Hemmschuh.

Wie gesagt: das ist weder gut noch schlecht. Es ist halt die Natur der Sache. Microsoft halt keine Schuld an der Verbreitung des Microsoft Bias. Die Erkrankung ist eher eine, hm, Art Autoimmunerkrankung oder iatrogen. Entweder fügen wir sie uns selbst schleichend zu. Oder sie wird durch die Medien, die eigentlich unabhängig sein und beim Überblick auch jenseits von Microsofts Angeboten helfen sollen, verursacht.

Hier setzt denn auch meine Kur an. Geheilt werden wir vom Microsoft Bias nur durch einen bewusst weiten Blick, sozusagen Augentraining. Immer wieder sollten die einschlägigen Medien und Plattformen ihre Autoren und Referenten motivieren, nicht nur Microsofts Botschaft wiederzukäuen, sondern darüber hinaus zu blicken. Bücher über Linq to Sql oder BizTalk oder TFS gibt es. Warum aber keine oder deutlich weniger über Open Access, NServiceBus oder CC.NET und FinalBuilder? Das Gewicht der Berichterstattung ist stark zugunsten von Microsoft verlagert. Ein Übelstand, der der Entwicklergemeinde nicht gut tut.

Die recht neue Alt.Net "Bewegung" ist ein Ausdruck des Willens zur Gesundung. Gut so. Aber wir brauchen mehr Blicke über den Tellerrand hinaus. Ich habe mir deshalb vorgenommen, in Zukunft vermehrt über Technologien und Konzepte jenseits der Microsoft Botschaft zu berichten. Warum soll ich mich auch in den Chor der VSTS Verkünder einreihen, wenn TestDriven dasselbe oder gar mehr bietet - sogar für VS2008 Standard Anwender? Warum soll ich ins BizTalk Services Horn stoßen, wenn Jabber viel interessanter und vor allem hier und jetzt ist?

Damit will ich nicht sagen, was Microsoft tut, sei schlecht. Ich will nur mehr Entwicklern Alternativen aufzeigen, denen sie Beachtung schenken sollten. Wenn die Schnellen die Großen schlagen, warum soll ich dann nicht heute eine ordentliche non-Microsoft Implementation eines Konzeptes einsetzen, statt auf eine Lösung von Microsofts Gnaden dermaleinst zu warten? Ich bin dann lieber heute schneller, als morgen vielleicht etwas besser.

Je länger ich auch drüber nachdenke, desto eher bin ich bereit, Integration zu opfern für mehr Wahlfreiheit. Best-of-Breed mit suboptimaler Integration heute hat für mich mehr Reiz als bessere Integration in der Zukunft, bei der ich wahrscheinlich mehr zahlen muss.

Insofern sehe ich Microsofts Hauptaufgabe da, wo es um die Schaffung von Plattformen geht. Allen voran Visual Studio und .NET. Da ist es wichtig, dass Microsoft einen guten Job macht, um diese Plattformen erweiterbar zu halten. Die Visual Studio Shell ist für mich ein Zeichen in dieser Hinsicht (auch wenn Eclipse immer noch um Längen voraus ist).

Die "Gottgleichheit" Microsofts, die Definitionsmacht, die Bestimmung der Entwicklerschicksale sehe ich hingegen am Schwinden. Das mag sich nicht in direkt und sofort in den Verkaufszahlen von Office und Windows und SQL Server ausdrücken. Aber letztlich kann Microsoft einfach in Relation zu dem, was wir Softwareentwickler brauchen, nicht alles "wuppen". Microsoft als one stop tool provider hat ausgedient, muss ausgedient haben. Wer sich nicht vom Microsoft Bias erholt (ohne zum Microsoft Hasser zu werden) vergibt sich einfach Chancen. Die Welt ist bunter und bietet mehr, als Microsoft uns vorbetet und vormacht.

Das ist schon heute so - es muss nur eben die Entwicklergemeinde in ihrer Breite sehen. Das zu erreichen ist Aufgabe der Medien. Es liegt an ihrer Themenselektion, was die Augäpfel der Entwickler erreicht und was als "salonfähig" gilt. Wenn sich die formal unabhängige Berichterstattung und Präsentation dann aber auch wirklich unabhängig verhält, dann wird sich Microsofts Sonne dem Horizont nähern. Dann wird es zur Microsoftdämmerung kommen - einer notwendigen Dämmerung, wie ich meine. Denn so wichtig eine Sonne als Lebensspender und Leitstern ist, sie kann bei zu großer Strahlkraft auch blind machen und verdörren.

Microsoft ist ein Player am Markt wie jeder andere. Gut so. Das müssen wir nur noch auf breiter Front zu unser aller Nutzen wirklich verinnerlichen. Es gibt viele Alternativen, die eine Chance verdienen. Möge die beste gewinnen!

UI-first Design ganz ohne schlechtes Gewissen

Endlich sagt es mal einer deutlich: Softwareentwicklung beginnt beim UI. Jeff Atwood spricht es in seinem Coding Horror Blog deutlich aus: Programmierung ist "UI-First Software Development".  Zwar wussten wir das irgendwie schon seit 17 Jahren - aber es ist gut, wenn es endlich auch mal jemand so deutlich sagt. Microsoft hat es uns zwar im Grunde nie anders demonstriert - von VB 1.0 bis WPF, AJAX und Silverlight. Aber ein Unbehagen blieb dennoch. Denn seit mindestens 10-12 Jahren gibt es auch genügend Stimmen, die immer wieder mahnen, dass das UI nicht so wichtig sei, dass man damit doch nicht die Softwareentwicklung beginnen solle. Ja, ja, ja... aber... hm...

Diese Unsicherheit löst sich auf, wenn wir das unselige Akronym RAD ersetzen durch RUID. Denn was VB 1.0 und Delphi und WinForms und Expression usw. bieten, ist nicht Rapid Application Development. Rapidly kann man damit zwar arbeiten - aber RAD war nie (!) dazu gedacht, bei der Architektur zu helfen. Design von Strukturen - denn dafür könnte das D in RAD auch stehen - war nie Sache der RAD-Tools. Nur das visuelle Design, die Oberfläche war gemeint. Eigentlich. Doch dann hat jemand zwischen R und D ein A für Application gesetzt und damit das Kind in den Brunnen geworfen. Bei RAD sollte es um alles gehen, um ganze Anwendungen.

Damals mögen Anwendungen vielleicht noch entweder so simpel gewesen sein, dass man keine weitere Struktur gebraucht hat als die, die sich durch Platzierung von Steuerelementen und Auswahl ihrer Events ergab. Oder Anwendungen waren doch kompliziert, wobei das wirklich Komplizierte sich jedoch in einem DB-Server abspielte und nicht weiter vom Entwickler "designt" werden musste. Was blieb war der (kleine) Anteil der Applikation, mit der der Benutzer interagiert.

Letztlich ist es aber einerlei. RAD für mehr als eine Hilfe beim Entwurf des Aussehens (!) einer Anwendung anzusehen, war immer schon falsch oder zumindest ein Missverständnis. Und das wurde eigentlich auch relativ bald bemerkt. Dadurch geriet dann RAD bzw. das UI in Verruf. Schade. Denn in einer Hinsicht hatte die missverstandene RAD-Botschaft Recht: Das UI muss am Anfang der Softwareentwicklung stehen. Ja, "muss", denn das UI ist ein Kontrakt.

UI-first für den Kunden

Jeff bringt es auf den Punkt: "Remember, to the end user, the interface is the application." Für den Kunden ist Software vor allem durch das UI greifbar. Von dem, was dahinter steht, hat er noch weniger eine Vorstellung als von dem, was hinter einem Armaturenbrett ein Auto wirklich ausmacht. Wo aber Unwissen herrscht, da ist Unsicherheit nicht weit. Und Unsicherheit ist wiederum der beste Nährboden für Konflikte. Wer also Konflikten aus dem Weg gehen möchte, der versuche nicht, den Kunden über die Interna der von ihm bestellten Software aufzuklären. Solche Wissensvermittlung kommt schnell an ihre Grenzen und interessiert den Kunden auch nicht wirklich. Er empfindet sich als vom Wesentlichen ablenkende Belehrung. Viel effektiver beugen Sie Konflikten vor, indem Sie mit dem Kunden darüber reden, wozu er einen unmittelbaren Bezug hat: das UI.

In einem Projekt möglichst früh mit dem Kunden ausführlich über das UI zu sprechen, ist aber nicht nur eine vertrauensbildende Maßnahme und beugt Konflikten vor, sondern hat darüber hinaus konkreten Nutzen. Die Arbeit am UI definiert nämlich den wesentlichen Kontrakt zwischen Mensch und Software. Ohne hohe Usability ist alle grundsätzlich vorhandene Funktionalität nutzlos. Das werden Sie bestätigen, wenn Sie schon einmal in einem Land waren, dessen Sprache Sie nicht beherrschten, und dort in einem guten Restaurant speisen wollten. Solange das Restaurant die Menükarte nicht in einer Ihnen verständlichen Sprache bereitgehalten hat, war sein guter Service für Sie nutzlos oder zumindest nicht kontrollierbar. Die Usability des Restaurants war bei aller Qualität seiner "Funktionalität" niedrig.

Damit Ihrem Kunden das nicht mit Ihrer Software passiert, sollte UI-Design am Anfang der Implementierung stehen. Um den Aufwand dafür klein zu halten, hat Jeff dafür z.B. Papierprototypen vorgeschlagen:

Quelle: Jeff Atwood, www.codinghorror.com

Ob Sie nun aber Papier benutzen oder Powerpoint oder Visio oder andere Demowerkzeuge, das ist egal. Hauptsache der Kunde bekommt möglichst früh das Gefühl, das am Ende Ihrerer Arbeit wirklich benutzbare Software herauskommt. Und Sie bekommen möglichst schnell ein Gefühl dafür, was der Kunde wirklich will. Denn Kunden können meist nicht gut abstrakt beschreiben, was Sie sich wünschen. Dafür sind sie jedoch sehr gut darin zu erkennen, ob etwas so ist, wie sie es sich vorgestellt haben. Mit einem UI-Prototypen nun geben Sie Ihrem Kunden etwas zum Erkennen. Die Software wird für ihn greifbar. Und das auch noch sehr früh und für Sie quasi ohne Risiko.

UI-first Design reduziert also Konfliktpotenzial, dient dem Verständnis beider Seiten, was eigentlich zu erreichen ist, verspricht höhere Usability und reduziert den Frust durch Änderungen später im Software-Lifecycle. Damit aber nicht genug...

UI-first für den Entwickler

Der Nutzen von UI-first Design reicht über Vertrauensbildung, Anforderungsverfeinerung und Usability-Steigerung hinaus. Wichtig beim UI ist nämlich nicht nur das Aussehen und die grundsätzliche Dienstleistung, wichtig sind die Trigger, der Event-Fluss, die konkreten Funktionen, die ein Benutzer anstößt. Das UI ist nicht nur ein Kontrakt mit dem Kunden, der menschenlesbar beschreibt, was wie getan können werden soll mit einer Software. Das UI ist auch ein maschinenlesbarer Kontrakt innerhalb der Software. Genau wie ein Kontrakt zwischen zwei Komponenten:

Während ein "normaler" Komponentenkontrakt allerdings meistens aus Interfaces besteht, definiert den UI-Kontrakt meist ein WinForms-Formular. Seine Eventhandler-Methoden beschreiben die Funktionalität eines Dialogs. Interaktionen mit dem Benutzer finden immer über solche Methoden statt, die der Benutzer durch Tastendrücke oder Mausaktionen oder auch Spracheingabe triggert.

Was eine Service-Komponente nun für Funktionen bieten sollte, bestimmen ihre "Kunden". Im vorstehenden Bild ist der "Kunde" von M die Komponente L. Der Kunde von L ist K, der von K... ist der Benutzer. Die Funktionalität von M, ihre Funktionen sind damit mittelbar abhängig vom... Benutzer. Wenn Sie effizient arbeiten wollen, d.h. nicht potenziell unnötige Funktionalität in M implementieren möchten, dann tun Sie gut daran, die Kontraktdefinition nicht mit M zu beginnen, sondern mit L, nein, mit K, also dem UI. Denn aus den Funktionen des UI ergibt sich erst, welche Leistungen K von L benötigt. Und daraus ergibt sich erst, welche Leistungen M bieten muss. Lean Software Development entwickelt nur das, was unbedingt nötig ist. Das aber finden Sie heraus, indem Sie Ihren Entwurf beim Benutzer mit dem UI beginnen.

Dafür ist eine gestaltungsorientierte Darstellung wie sie Jeff sie skizziert hat eigentlich schon zu detailliert. Vor allem ist sein Bild zu statisch. Es zeigt nur einen Schnappschuss des Zustands eines UI. Funktionalität im Sinne von "Was kann ich jetzt tun?" ist daraus nur mühsam ablesbar.

Deshalb sollten Sie beim UI-first Design nicht nur über die Gestaltung sprechen, sondern auch die Interaktionsmöglichkeiten explizit festhalten. Welche Funktionen stehen einem Anwender zur Verfügung? Das Programm von Jeff erlaubt einem Anwender anscheinend, sich zu authentifizieren und etwas zu suchen. Der rote Login-Dialog liegt allerdings nur platt auf der Suchmaske. Welche Trigger dieser Kontrakt bietet, ist nicht zu erkennen. Hier zwei Beispiele, wie die Skizze von Jeff verstanden werden könnte:

Der "maschinenrelevante" Kontrakt des UI besteht danach vor allem aus den Funktionen:

• Open() des Hauptfensters bzw. des Login-Dialogs
• Login() für die Anmeldung
• Search() zum Suchen

Mit diesen Funktionen (für ein K) in der Hand kann nun die Frage gestellt werden, welche Funktionen nachgeschaltete Komponenten (wie L und M) bieten sollten.

Ohne ein explizites UI-Design würde solche Überlegung viel schwerer fallen. Sie müssten dafür quasi in die Glaskugel blicken. Sie könnten nur spekulieren, was von einer Komponente wie M oder L gefordert sein könnte. Das ist bottom-up oder inside-out Entwicklung, die leicht zu sehr allgemeinen Lösungen führt - und damit unnötig ineffizient ist.

Outside-in, d.h. beim UI beginnend, kommen Sie zu Kontraktdefinitionen mit minimal nötiger Funktionalität. Das ist produktiv.

UI-first Design dient nicht nur weichen Faktoren wie Usability oder Vertrauen, sondern harter Architektur. Wenn Sie mit dem UI beginnen, müssen Sie in Zukunft also kein schlechtes Gewissen mehr haben. Allerdings sollten Sie auch nicht mehr tun, als hier beschrieben. Das UI ist nicht die Applikation, sondern die Applikation hat nur eine dünne UI-Schale.

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...