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