Die Selbstlern-Challenge - Retrospektive

Zehn Wochen sind wie im Flug vergangen, seit ich zur Teilnahme an einer Selbstlern-Challenge eingeladen hatte.

Das Angebot

Die Herausforderung war, sich selbstständig über einen Zeitraum von 10 Wochen in das Thema Flow Design & Co einzuarbeiten. Einzige Bedingung: Als Dokumentation des Dranbleibens am Thema sollte mir jede Woche eine Frage per Email geschickt werden - die ich dann selbstverständlich auch beantwortet habe.

Zehn Teilnehmer hatte ich gesucht und in weniger als 24 Stunden auch gefunden. War das ernsthaftes Interesse am Thema? Oder vielleicht doch nur Interesse am “Preisgeld”? Jedem der durchhält, hatte ich einen 50€ Amazon-Gutschein versprochen. Wie sich herausstellte, waren solche Überlegungen unbegründet. Wer dabei geblieben ist, hat sich intensiv mit dem Thema auseinandergesetzt. Zwei Teilnehmer schrieben sogar, sie seien an dem Gutschein gar nicht interessiert.

Erkenntnis #1: Beim nächsten Mal werde ich zur Wahl stellen, das “Preisgeld” ausgezahlt zu bekommen oder es zu spenden.

Warum hatte ich überhaupt ein “Preisgeld” ausgesetzt? Weil ich einen zusätzlichen Anreiz zum Mitmachen bieten wollte. Der sollte nämlich hoch sein, um meine Hypothese zu bestätigen. Bevor ich die aber erläutere hier erstmal die “Gewinner”…

Die “Gewinner”

Von 10 Teilnehmern haben 5 durchgehalten. Der Austausch mit ihnen war unterschiedlich intensiv. Beim einen waren es über 80 Emails, die zwischen uns hin und her gingen, beim anderen nur 4, dafür aber noch Chats in Slack.

Erkenntnis #2: Veränderungen während des Challenge vermeiden. Als ich nach einigen Wochen Slack als weiteres Kommunikationsmedium angeboten habe, kam es zu einigen Irritationen. Manche nahmen diesen neuen Kanal freudig auf und haben sich auch untereinander darüber ausgetauscht. Andere waren verwirrt bis verärgert und wähnten eine unlautere einseitige Vertragsänderung. Dabei wollte ich doch nur nett sein… Aber so kann es gehen. Deshalb: Wenn die Sache einmal läuft, Füße stillhalten.

Ach, ja, die “Gewinner”. Die gab es natürlich nicht, weil es nichts zu gewinnen gab. Es war ja kein Wettbewerb. Eher sollte es wohl heißen, die “Durchhalter” oder “Finisher”. Gewinner waren alle inklusive mir. Denn wir haben einiges gelernt - auch die, die nicht durchgehalten haben. Hoffentlich.

Über die Ziellinie haben sich diese 5 Teilnehmer gefragt:

• Manuel Beetz
• Benjamin Beisner
• Karsten Peiler
• Max Schmidt
• Benjamin Seblu

Herzlichen Glückwunsch! Die Gutscheine sind schon verschickt.

Leider war die Auswertung nicht ganz so einfach, wie gedacht. Zuerst hatte ich mir noch aufgeschrieben, wer wann eine Frage gestellt hat. Doch im Eifer der Email-Kommunikation ist das dann nicht mehr so klar gewesen. Wann war eine Frage die Wochenfrage, wann nur eine weitere? Am Ende musste ich also die ganze Kommunikation nochmal durchsehen und habe sogar die Teilnehmer gebeten, das nochmal zu prüfen.

Erkenntnis #3: Zumindest die Einreichung der wöchentlichen Frage sollte stärker formalisiert sein. Solange die Erfolgsbedingungen so einfach sind und von normaler Kommunikation kaum unterscheidbar, braucht es dafür einen Rahmen. Es hätte gereicht zu fordern, dass die Wochenfrage in einer Email mit einem Betreff geschickt wird, in dem die Fragennummer steht, z.B. “Selbstlern-Challenge Frage #3”.

Die Hypothese

Die Teilnehmer haben immer wieder mal gefragt, was denn meine Hypothese gewesen sei. Und auch Sie mögen sich gefragt haben, warum da einer bereit ist, 500€ dafür zu bezahlen, dass man ihm 100 fragen stellt. Müsste es nicht umgekehrt sein? :-)

Ja, als Geschäftsmodell taugt der Ansatz nicht wirklich. War ja aber auch so nicht gedacht. Ich habe vielmehr in Forschung investiert. Ich wollte herausfinden, ob meine Ansicht über das autodidaktische Lernen in unserer Branche “korrekt” ist.

Eine wissenschaftliche Studie ist das nun zwar nicht geworden, aber ich denke, eine Antwort habe ich dennoch bekommen. Hier meine Ausgangshypothese:

Ich glaube nicht daran, dass Entwickler autodidaktisch eine Methode wie Flow Design & Co neben ihrem Job lernen können.

Diese Hypothese hatte sich in mir über längere Zeit gebildet. Das wurde mir besonders bei einem Seminar Ende letzten Jahres bewusst. Da sagte ein Teilnehmer beim abschließenden Feedback, er fände den Ansatz gut, könne ihn aber frühestens in 2–3 Monaten in einem nächsten Projekt anbringen. Darauf erwiderte ich, er müsse schauen, dass er bis dahin im Thema drin bliebe, er müsse für sich weiter üben. Und der Teilnehmer sagte selbstgewiss, das würde er selbstverständlich. Damit hätte er Erfahrung.

Das war zu schön zu hören, um wahr zu sein. Deshalb schlug ich vor, er könne mir doch jede Woche als Resultat seines Übens eine Frage schicken. Das Angebot nahm er allerdings nur halbherzig an. Und dann bin ich gemein geworden: Ich habe ihm 2 Monate lang alle 2 Wochen eine Email geschickt und freundlich nachgefragt. Darauf hat er einmal geantwortet - und dann nicht mehr. Für mich bedeutet das: Er hat nicht geübt. Er hatte sich schlicht überschätzt. Guten Willen möchte ich ihm nicht absprechen. Nur nützt der nichts, wenn er nicht umgesetzt wird.

Als ich damit meine Hypothese als bestätigt zur Ruhe betten wollte, habe ich dann aber doch ein schlechtes Gewissen bekommen. Deshalb der Selbstlern-Challenge.

Mit dem Challenge wollte ich herausfinden, ob nicht sogar unter günstigeren Bedingungen das autodidaktische Lernen fehlschlägt. Aber nochmal zur Präzisierung: Die Hypothese bezieht sich auf das Lernen einer Methode, d.h. von etwas, bei dem man, wenn man es anwendet, relativ schlecht Feedback bekommt.

Wer sich autodidaktisch einen API beibringen will oder ein Tool lernt, der bekommt sofort bei der Anwendung Feedback. Was er tun will klappt oder nicht. Wenn es nicht klappt, kann das natürlich frustrierend sein. Aber meist klappt zumindest so viel, dass es relativ leicht ist, dran zu bleiben. Dann wird man besser und sucht nach Wegen, es in der Praxis anzuwenden.

Bei Methoden wie TDD, agilem Vorgehen, einem neuen Sprachparadigma oder eben auch Entwurfsansätzen wie Flow Design (oder das gute alte OOD) ist das jedoch anders. Ob man es gut macht, lässt sich nicht sofort ablesen. Es braucht größere Übungen und mehr Zeit, um Effekte festzustellen. Zumindest, wenn man autodidaktisch lernt. Lernt man mit Trainer, bekommt man sofort Feedback.

Dass es mit dem autodidaktischen Lernen nicht einfach ist, hatte ich ja schon in einem Selbstversuch demonstriert.

Der Selbstlern-Challenge hat es den Teilnehmern jedoch einfacher machen wollen. So gemein bin ich also doch nicht, oder? ;-) Nicht nur habe ich ein “Preisgeld” ausgesetzt, ich habe mich auch als Accountability Partner zur Verfügung gestellt. Ich habe also meiner Hypothese quasi ein Bein gestellt.

Dennoch war das Ergebnis offen…

Die Auswertung

Ist meine Hypothese nun falsifiziert worden? Hm… Um ehrlich zu sein, mit 50% “Gewinnern” hatte ich nicht gerechnet. 2–3 wären mir lieber für meine Hypothese gewesen ;-) Aber besser 50% als 90% sage ich mir nun.

Man kann die 50% natürlich so oder so auslegen.

a) Es haben mehr Teilnehmer durchgehalten als erwartet. Die Hypothese kann also nicht wahr sein. Autodidaktisches Lernen ist in der Branche kein Problem auch für Methoden. Hypothese falsifiziert. b) Es haben 50% der Teilnehmer nicht durchgehalten. Das ist ein großer Prozentsatz, der umso stärker zu bewerten ist, da es zusätzliche Anreize und Unterstützung gab. Im Grunde war das Lernen gar nicht ganz autodidaktisch. Echt autodidaktisches Lernen wird mit einer noch höheren Abbrecherquote belegt sein. Hypothese nicht falsifiziert.

Hm… Was nun?

Sie werden es mir nicht verdenken, ich tendiere zu Erklärung b). Meine Gründe:

1. Die Teilnahme war echt freiwillig. Hier war also die intrinsische Motivation sehr hoch.
2. Das Durchhalten wurde explizit belohnt. Der Effekt eines “Preisgeldes” mag nicht groß gewesen sein, aber ich würde ihn auch nicht ignorieren.
3. Die Pflicht, mir jede Woche “Rechenschaft abzulegen” hat sicher einen Zug ausgeübt. Da war jemand, der sich erstens dafür interessiert, das man voranschreitet, und der zweitens enttäuscht werden konnte.
4. Zu den Bedingungen gehörte, dass ich alle Teilnehmernahmen nennen darf. Es bestand also die Möglichkeit, als Abbrecher öffentlich gemacht zu werden.
5. Es musste nicht nur aus Texten gelernt werden, sondern da war jemand, der einem über Verständnishürden hinweggeholfen hat. Das macht Lernen einfacher und somit motivierender.

In Summe sind das so viele “Hilfestellungen” für das autodidaktische Lernen, dass mir eine 50% Abbrecherquote hoch erscheint und ohne solche “Unterstützung” noch viel höher gelegen hätte.

Bottom line: Autodidaktisches Lernen ohne Förderung und Forderung funktioniert nicht in unserer Branche. Mit Förderung meine ich, dass Unterstützung gegeben wird in Form von Zeit und anderen Ressourcen. Mit Forderung meine ich, dass die Nutzung der Förderung eingefordert werden muss. Jemand muss daran ziehen. Sonst vertrocknet die Förderung ungenutzt aus verschiedenen Gründen. Ohne Nachfragen wird anderes nach einer initialen Hochmotivationsphase schnell wichtiger. Damit bleibt das Lernen trotz der (passiven) Förderung auf der Strecke.

Erkenntnis #4: Wer sagt, “Ach, ich bleibe schon dran am Thema…” der überschätzt sich sehr wahrscheinlich. Es braucht einen echten Plan, wie man Lernstoff außerhalb einer Seminarumgebung tatsächlich weiter übt und dann in die Anwendung kommt. Ist der nicht kristallklar im Hinblick auf fördernde und fordernde Elemente, dann liegt Wunschdenken vor.[1]

Fazit

Die 10 Wochen haben Spaß gemacht. Es war schön, mit motivierten Teilnehmern zu arbeiten. Das hat mich weitergebracht. Ich habe wieder etwas mehr über Flow Design gelernt. Aber ich habe auch etwas über distance learning gelernt.

Erkenntnis #5: Nur eine Frage als Zeichen des Fortschritts zu erwarten, ist zu wenig. Es braucht etwas mehr methodische Anleitung für die Teilnehmer. Ein “Challenge-Tagebuch” fällt mir da ein, ein Portfolio und zumindest für Meilensteine im Lernstoff konkrete Aufgaben.

Auch wenn ich meine Hypothese bestätigt finde, bin ich nicht frustriert. Ich denke, es wurde etwas deutlicher, wie Angebote für das selbstständige Lernen aussehen müssen. Denn nur das skaliert am Ende. Wer möchte, dass sich eine Methode verbreitet, muss als Lehrer aus dem Weg treten, sonst ist er ein Nadelöhr.

Aber wohin treten? Darüber habe ich etwas gelernt. Herzlichen Dank an alle Teilnehmer, dass sie dabei mitgeholfen haben!

---

1. Das behaupte ich nun so apodiktisch, um die für mich deutliche Tendenz klar zu machen. Ich will nicht sagen, dass niemand so lernen kann. Sicher gibt es den einen oder anderen… nur habe ich von denen noch nicht viele gesehen. Und gerade die, die es von sich laut behauptet haben, sprangen eher zu kurz. Autodidaktisches Lernen einer Methode ist so gut oder schlecht möglich, wie als Kettenraucher ein hohes Alter zu erreichen. Es gibt Beispiele davon - nur würde ich die nicht zur Nachahmung bei der Lebensplanung oder Kompetenzausbildung empfehlen. ↩

Die Selbstlern-Challenge - Mitmachen und gewinnen!

500€ gibt es zu gewinnen. Ingesamt jedenfalls. Die bin ich bereit, als “Preisgeld” auszusetzen für diejenigen, die erfolgreich mitmachen.

Die Herausforderung

Ich suche 10 Freiwillige, die bereit sind, 10 Wochen lang sich im Selbststudium mit Flow Design auseinanderzusetzen. Das habe ich in einigen Büchern und vielen Blog-Artikeln ausführlich beschrieben. Dazu gehören Themen wie:

• Radikale Objektorientierung / OOP as if you meant it
• Agile Architektur / Die Anforderung-Logik-Lücke
• Softwarezellen

Über die 10 Wochen ist nicht viel zu leisten. Es gibt nur drei Bedingungen:

1. Wer teilnimmt, stellt mir jede Woche mindestens eine ernstgemeinte und nicht triviale Frage zu den obigen Themen. Diese Frage soll als minimale Dokumentation der kontinuierlichen und fortschreitenden Auseinandersetzung mit dem Stoff dienen. “Fragen auf Vorrat” sind nicht erlaubt, ebensowenig “aufholende Fragen”, die eine Woche ohne Frage kompensieren sollen.
2. Wer teilnimmt, reagiert auf Emails von mir zum Lernstoff innerhalb von max. 24h. Dies dient der Sicherung einer verlässlichen, flüssigen Kommunikation zur Beförderung des Lernens.
3. Wer teilnimmt, stimmt zu, dass sein/ihr Name veröffentlicht wird. Außerdem behalte ich mir vor, die Abschnitte zum Lernstoff aus der sich ergebenden Email-Konversation zu veröffentlichen.

Das ist alles. Es gibt keine Prüfung, es gibt überhaupt nichts, das am Ende abzuliefern wäre. Der Weg ist das Ziel :-)

Dieses Angebot gilt vom 27.1.2015 bis zum 17.5.2015 (oder anders: ab 5. KW bis inklusive 20. KW 2015). In der Zeit muss die 10-Wochen-Teilnahme abgeschlossen sein.

Update: Seit 28.1.2015 sind alle Teilnehmerplätze vergeben!

Die Teilnahme

Wer teilnehmen möchte, schreibt mir einfach eine Email. Dann beginnen die 10 Wochen zu laufen. Ich stelle daraufhin Lernmaterialien in Form von Links und Büchern zur Verfügung. Teilnehmer müssen also keinen Cent ausgeben.

Auf Wunsch stelle ich auch Aufgaben, an denen sich Teilnehmer versuchen können.

Der Gewinn

Der Gewinn der Teilnahme besteht natürlich vor allem in Wissens- und Erfahrungszuwachs. Darüber hinaus erhält aber auch jeder erfolgreiche Teilnehmer am Ende noch einen Amazon-Gutschein in Höhe von 50€.

Erfolgreich ist, wer die obigen Bedinungen erfüllt. Mehr ist nicht nötig, weniger allerdings auch nicht.

Die Hypothese

Mit dieser Herausforderung möchte ich eine Hypothese überprüfen, die ich zum autodidaktischen Lernen habe. Welche das ist, kann ich vorher nicht verraten. Damit würde ich die Durchführung des Experiments beeinflussen. Aber ich verspreche, dass ich am Ende der Herausforderung darüber berichte.

 

Und nun: Lasst das Selbstlernen beginnen!

Regelmäßiges Lernen - Meine Retrospektive

Ende Juni 2014 hatte ich versprochen, ich würde nun auch noch expliziter das Lernen in meine Arbeitszeit einbauen. Zwar besteht mein Job als Berater, Trainer, Autor zu einem großen Teil ohnehin aus Lernen, doch das hat eine andere Qualität als das, was ich meinen Seminarteilnehmern und Kunden nahelege. Mein Job ist Lernen, deren Job ist es nicht.¹

Wenn ich Softwareentwickler empfehle, in der Arbeitszeit zu lernen, dann bürde ich ihnen scheinbar eine extra Aufgabe auf. Das war bei meinem Lernen bisher nicht der Fall gewesen. Deshalb wollte ich mein Lernen noch expliziter machen; es sollte auch für mich eine zusätzliche Aufgabe im Tagesgeschäft werden, damit ich einmal fühle, wie es meinen Kunden geht.

Mein Commitment war, dass ich wöchentlich während der Arbeitszeit 2+ Stunden mich auf diese Aufgaben konzentriere:

• Französisch lernen
• Bücher zu Sachthemen außerhalb normaler Lernthemen lese
• Meditiere, d.h. "Ruhe und Fokus lernen"

Und ich hatte versprochen, über meine Erfahrung mit solchem extra Lernen nach drei Monaten zu berichten. Hier nun meine Beobachtungen:

Das sind zwei Auszüge aus meinem Lernprotokoll, das ich mit Lift geführt habe.

Sie sehen, lückenlos ist das nicht. Meine erste Beobachtung also: Es ist nicht leicht. Es ist nicht leicht, an jedem Arbeitstag die 15-30 Minuten aufzuwänden. Irgendetwas anderes schien oft dringender und so war das Lernen dann verschoben auf später und dann auf den nächsten Tag.²

Gelegentliche "Planübererfüllung" hat das zum Teil wett gemacht, ist langfristig aber keine erfolgversprechende Strategie, würde ich sagen. Das ist wie mit dem Refactoring: wenn man es länger und länger nicht tut, dann ist der Berg am Ende so groß, dass man es auch nicht nachholen kann.

Außerdem ist der mentale "Umschaltaufwand" gerade beim Französich Lernen für mich teilweise so hoch, dass in der kurzen Zeit die echte Lernaufmerksamkeit dann noch kürzer ist. Das fühlt sich ineffizient an.

Die Lehre, die ich daraus ziehe: Extra Lernen macht in so kleinen Tageshappen nur sehr bedingt Sinn. Besser scheint mir ein wöchentlicher Lernblock von 2+ Stunden.

Manchmal habe ich mir aber auch selbst ein Bein gestellt. Die beste Zeit für Französisch und Sachbuch war der Vormittag - ebenso jedoch auch fürs Schreiben. Welcher Tätigkeit dann den Vorzug geben? Die Entscheidung fiel mir leichter fürs Schreiben.

Die nächste Lehre daher: Der Zeitpunkt für Lernen will gut gewählt sein. Und wenn er einmal gewählt ist, sollte die Entscheidung nicht immer wieder neu getroffen werden müssen. Da geht Kraft verloren. Da zieht Lernen allzu schnell den Kürzeren. Vertagen scheint so einfach, so schmerzfrei. Doch in Wirklichkeit wird nicht vertagt, sondern gestrichen.

Aber auch von solchen Äußerlichkeiten unabhängig fiel mir das Lernen nicht immer leicht. Ich habe Wellen der Motivation gespürt. Manchmal klappte es besser, dann war ich für den nächsten Tag motivierter; manchmal klappe es nicht so gut, dann hatte ich am nächsten Tag nicht soviel Lust, mich weiterem Frust auszusetzen.

Solche ups and downs lassen sich wohl nicht vermeiden. Aber ich denke, man kann sie mildern. Das ist wie beim Fitnesstraining. Die Lust am Morgen (oder Abend) sich aufzumachen, ist unterschiedlich - da hilft es, wenn jemand auf einen wartet.

Ich habe (wieder einmal) übers Lernen gelernt: Lernen macht mehr Spaß und funktioniert verlässlicher, wenn man es nicht allein machen muss. Das Mindeste ist ein Accountability Partner, d.h. eine Person, der man direkt in die Augen blicken und gegenüber Rechenschaft ablegen muss. Eine Person, die den Lerner zieht. Die ihn an seinen Vorsatz erinnert, ihn fordert (aber auch durchaus fördert).

Damit meine ich nicht unbedingt einen Lehrer, aber der kann es natürlich auch sein.

Ein Mitlerner ist genauso gut. Oder einfach nur jemand, der eben zieht und sonst nichts.

Lernen in Teams sollte deshalb nicht Sache der Einzelnen sein, sondern der Gruppe. Gemeinsam Lernzeit einrichten, gemeinsam lernen. Das hilft ungemein.

Unterschätzt habe ich am Ende allerdings vor allem einen Aspekt: Relevanz. Nach einer initialen Phase hoher Motivation bin ich beim Französisch Lernen in den Morast gekommen. Es ging nur zäh voran. Nicht, weil es besonders schwierig gewesen wäre. Es lag vielmehr an einer fehlenden Bedeutung des Französischen für mein sonstiges Leben.

Ich mag Französisch. Ich würde es gern lesen und auch sprechen können. Doch am Ende ist das nicht jeden Tag wieder genug Antrieb gewesen, um dauerhaft dabei ins Lernen zu kommen. Anders wäre es wahrscheinlich gewesen, hätte ich schon mehr Vokabular drauf gehabt und mit dem Lesen von spannenderer Lektüre anfangen können. So aber war dieses Thema sehr abstrakt.

Das bedeutet: Lernen funktioniert umso besser, je relevanter es für das sonstige Leben (hier: Arbeitsalltag) ist. Je kleiner der Sprung vom Lernen ins Tagesgeschäft, desto besser. Das muss nicht bedeuten, dass man alles anwenden kann oder Großartiges leisten muss. Aber immer wieder sollte im Arbeitsalltag etwas ein Stückchen leichter fallen, besser werden.

Das habe ich bei der Lernaufgabe "Sachbuch lesen" positiv gemerkt. Dort habe häufiger Impulse für die Arbeit bekommen.

Diese Retrospektive zu meinem Lern-Commitment mag ernüchternd klingen. Es hat nicht so einfach geklappt, wie gedacht. Auch die Öffentlichkeit, in die ich mich mit dem Commitment begeben hatte, hat daran nicht viel geändert.

Doch ich sehe es positiv: Immerhin habe ich dabei etwas gelernt. Auf der Meta-Ebene. Für mich selbst, für meine Kunden oder für Sie braucht es neben der Erkenntnis, dass Lernen wichtig ist, und dem guten Willen einfach noch ein paar Rahmenbedindungen:

1. Wenn es um echten Lernstoff geht, dann besser jede Woche eine längere Lernzeit einplanen (2+ Stunden).³
2. Einen Lernpartner oder zumindest einen Accountability Partner suchen.
3. Immer wieder probieren, den Lernstoff im Alltag anzuwenden. Sozusagen inkrementelles Lernen à la Agilität, d.h. es entsteht sofort Nutzen.

Das mögen jetzt keine weltbewegenden Einsichten sein. Irgendwie klingt das doch selbstverständlich. Und doch ist es nochmal etwas anderes, diese Einsichten durch Erfahrung gewonnen zu haben.

Angesichts der Wichtigkeit des Lernens und auch des Lernens während der Arbeitszeit, in sich immer wieder etwas anderes dazwischen drängt, ist jeder Gewinn an Klarheit jedoch ein Fortschritt, finde ich. Mit dem falschen Fuß loszugehen, sich Illusionen hinzugeben, enttäuscht nur. Besser ist es, von Anfang an ein realistisches Rahmenwerk aufzubauen.

In diesem Sinn ist auch die CCD School gedacht. Sie bietet nicht nur Input fürs Lernen, sondern auch eine Form der Begleitung, der Accountability Partnerschaft. Offline geht das im Monatsrhythmus, online auch häufiger.

Zu guter Letzt aber doch noch ein Trost: Ich habe auch festgestellt, dass sich manches verselbstständigt. Ich mag mich schließlich nicht so regelmäßig und dauerhaft zur Meditation hingesetzt haben, wie geplant - doch das, was ich damit erreichen wollte, hat sich auf anderem Wege in mein Leben eingeschlichen. Die Fokussierung und das Konzentrieren auf "Innen" finden inzwischen "einfach so" immer wieder statt.

Manchmal wird aus extra Lernen also neue Gewohnheit. Dann macht das Thema keine Last mehr, sondern ist Alltag, gar Lust.

---

1. Ob das wirklich eine günstige Sichtweise ist, die Arbeit von Softwareentwickler als nicht (oder nur wenig) lernend anzusehen, lasse ich hier einmal dahingestellt.↩

2. Dazu kam, dass ich nicht jeden Tag meine Arbeitszeit einteilen konnte, wie ich wollte, weil ich in Trainings- und Beratungen beim Kunden war.↩

3. Anders ist es mit Gewohnheiten oder einzelnen Handlungen. Meditation lässt sich nicht auf einmal pro Woche konzentrieren. Genauso wenig eine tägliche Reflexion, wie sie der Rote Grad des Clean Code Development empfiehlt.↩

Futter für das Coding Dojo

Wie soll man eigentlich Profi in der Anwendung der Prinzipien und Praktiken von Clean Code Developer werden? Durch Übung :-) Und zwar zunächst einmal durch Übung an Übungen, d.h. nicht am Produktionscode des Tagesgeschäftes.

Woher aber solche Übungen nehmen? Es gibt einige Übungsvorschläge, die sog. Code Katas. Doch die sind meist sehr, sehr überschaubar. Es sind vor allem Übungen im Entwickeln kleiner Algorithmen. Das ist nicht schlecht – aber am Ende zu wenig. Damit kann man ein paar Prinzipien und auch die Methode TDD üben… Doch realistisch sind solche Übungen nicht. Sie bereiten insofern nur begrenzt auf das reale Leben vor.

Deshalb haben Stefan Lieser und ich nun angefangen, Übungen zu sammeln, die ein breiteres Spektrum abdecken. Wir setzen sie schon seit mehreren Jahren in unseren Trainings der Clean Code Developer Akademie ein. Und jetzt “lassen wir sie frei”. Ein kleines Geschenk an die Community.



Im “Coding Dojo” der Clean Code Developer School bauen wir ein Verzeichnis von Code Katas und anderen auf. Wir teilen dabei die Übungen in verschiedene Kategorien je nach Umfang. Am unteren Ende stehen “Function Katas”, bei denen die Aufgabe darin besteht, nur eine Funktion zu entwickeln, um einige Anforderungen zu erfüllen. Darüber liegen “Class Katas” und “Library Katas”. Und weiter geht es mit “Application Katas” und “Architecture Katas”. Sie stehen für umfangreichere Aufgaben, zu deren Lösungen Benutzerschnittstellen und Ressourcenzugriffe oder gar Verteilung gehören. Es sollte also für jeden Geschmack und jedes Zeitbudget etwas dabei sein.

Auf der Seite des “Coding Dojo” sind die Aufgaben in diesen Kategorien gelistet; die zugehörigen Dokumente befinden sich hingegen bei scribd.com, wie oben im Bild zu sehen. Wir nutzen gern die Cloud als Speicehrort ;-) Hier ein Beispiel:

Application Kata Taschenrechner by Clean Code Developer School

Das Verzeichnis der Übungsaufgaben soll natürlich ständig wachsen. Wir haben noch einige in petto, wir werden weitere bekannte und beliebte Aufgaben im Web “ernten” und aufarbeiten. Aber wir freuen uns auch, wenn Sie uns Ideen für Übungen mitteilen. Von einem umfangreichen und vielfältigen Verzeichnis an Katas können die Communities aller Plattformen nur profitieren.

Und nun: Auf zum Üben! Auf in ihr persönliches Coding Dojo!

Nehmen Sie sich (am besten regelmäßig) allein oder mit Kollegen ein bisschen Zeit dafür. Oder besuchen Sie uns in der Clean Code Developer School. Dort zeigen wir Ihnen in Ruhe, was wir unter sauberer und nachhaltiger Softwareentwicklung verstehen.

Clean Code Development anders lernen

Ich hatte einen Traum. Den erfülle ich mir nun. Zusammen mit Stefan Lieser eröffne ich die Clean Code Developer School (CCDS):

Mein Traum war schon vor Jahren, Softwareentwicklung entspannter und nachhaltiger für die Teilnehmer zu unterrichten. Zunächst hatten Stefan und ich das mit den CCD Camps versucht, deren Trainings bis zu 14 Tage gedauert haben.

Da hat uns dann aber die Realität schnell eingeholt. So lange mögen Unternehmen ihre Mitarbeiter nicht “von der Leine lassen”. Auch die Aufteilung in kleinere Blöcke mit Pausen dazwischen hat die Attraktivität solch soliden, ausführlichen Lernens nicht erhöht.

Die Konsequenz: Inzwischen sind sind runter auf die üblichen 2, 3 oder maximal 5 Tage Trainingseinheiten. Wir versuchen, die Clean Code Developer Inhalte so zu schneiden, dass Teilnehmer in so kurzer Zeit wirklich etwas mitnehmen.

Leider zeigt sich, dass schon 5 Tage am Stück zu lernen, eine starke Belastung für die Aufmerksamkeitsspanne ist. Ab Tag 4 ist deutlich zu spüren, wie die Luft bei den Teilnehmern ausgeht. Der Lernstoff muss einfach mal sacken, statt unter weiterem begraben zu werden.

Doch die übliche Ökonomie von Trainings drängt darauf, soviel wie möglich in kurze Trainings zu stecken.

Darauf habe ich jetzt aber keine Lust mehr. Und Stefan Lieser auch nicht.

Wir sehen einfach, dass oft das Geld für die üblichen Trainings rausgeschmissen ist. Zuviel Lernstoff in zu kurzer Zeit führt dazu, dass am Ende nichts richtig geübt wurde. Aber vor allem fallen die Teilnehmer nach dem Training in ein Loch. Zurück am Arbeitsplatz fehlt ihnen die Zeit und die Anleitung, um den Stoff weiter zu üben und dann auf ihre Situation zu transferieren.

Das ist für uns als engagierte Trainer frustrierend zu sehen.

Deshalb machen wir es jetzt anders.

Einstweilen geben wir unsere üblichen Trainings zum Beispiel im Rahmen der Clean Code Developer Akademie noch nicht auf. Aber zumindest setzen wir einen Fuß in eine neue Richtung mit der Clean Code Developer School.

Dort findet Lernen nämlich nicht in tagelange Kursen ab und an im Jahr statt, sondern jede Woche in Blöcken zu 4 Stunden.

Wir meinen das mit dem “regelmäßig lernen” ernst. Ohne geht es einfach nicht. Nur findet es am Arbeitsplatz nicht statt. Deshalb machen wir mal ein ganz anderes, quasi ein unwiderstehliches Angebot. Wir kommen mit der CCDS den Lerninteressierten im doppelten Sinn so weit entgegen, dass kontinuierliches Lernen machbar wird.

Natürlich sind wir uns bewusst, dass ein solches Angebot schlechter skaliert als übliche Trainings. Ob und wie es sich für uns rechnen wird, müssen wir sehen. Aber egal. Wir starten das Experiment, weil wir das Richtige im Sinne eines nachhaltigen Lernens für die Teilnehmer tun wollen.

Details zum Was, Wie, Wo, Wann finden Sie auf der Seite der Clean Code Developer School. Hier will ich nicht mehr verraten ;-)

Falls Sie in der Nähe eines Schulungsortes der CCDS sein sollten, schauen Sie doch zumindest mal für einen Schnupperunterricht rein.

Wenn ich Sie für diese Idee begeistern konnte, dann folgen Sie der CCDS doch ab jetzt über ihren RSS-Feed oder bei Twitter: @ccd_school.

Quotenlose Entwicklung

Was ist an diesen Bildern falsch?

 

Zeigen Sie vielleicht keine echten Softwareentwickler? Doch. Zumindest auf dem linken Bild erkenne ich eine Person, von der ich weiß, dass sie Informatiker ist – weil ich mit ihr zusammen studiert habe.

Ist das Diagramm am Whiteboard des zweiten Bildes unrealistisch? Nein. Es folgt zwar keinem UML-Standard, würd ich sagen – aber das ist ja nichts Besonderes in der Branche :-) Die Inhalte sehen zumindest plausibel aus für eine Besprechung einer Web-Anwendung.

Stößt mir auf, dass die Bilder gestellt sind? Nein. Das finde ich normal für Werbebilder. Man muss nicht wissen, warum die Personen im ersten alle zum Himmel blicken. Erwarten Sie von dort die Niederkunft eines besseren Tools? Oder steigt von dort der neue Kollege herab? Auch “gute Aussicht” verbinde ich nicht mit einem Blick nach oben, sondern eher in die Weite, zum Horizont. Aber egal.

Gleichfalls sitzen die Personen im zweiten Bild etwas gezwungen um den Tisch. Der Laptop zeigt nichts; warum ist er aufgeklappt? Realistisch wäre, wenn dort ein Skype-Chat und eine FaceBook-Seite zu sehen wären oder zumindest ein Email-Client. Denn damit beschäftigen sich Menschen in Besprechungen, wenn sie ein Laptop dabei haben. Und dann die Armhaltung der Person rechts. Zu schlaff, um ernst gemeint zu sein, würde ich sagen. Aber egal.

Nein, ich meine etwas anderes. Ich meine das Mann-Frau-Verhältnis. Beide Bilder aus dem aktuellen ObjektSpektrum zeigen 5 Personen, nein, genauer: 5 Softwareentwickler – und davon sind 2 Frauen.

40% der abgebildeten Person sind weiblich. Das ist absolut unrealistisch. Weit von der Realität entfernt. Geradezu märchenhaft.

Meine aktuelle Zählung der weiblichen Mitglieder im Clean Code Developer XING-Forum ergibt einen Anteil von um die 3%. (Prämisse: Das Verhältnis im Forum spiegelt das Verhältnis in der Branche wider. Ich wüsste aber nicht, welcher Faktor CCD unattraktiver für Frauen als für Männer machen sollte. Eher umgekehrt. Auch glaube ich nicht, dass Frauen bei XING unterrepräsentiert sind.)

In der Softwareentwicklung haben wir eine bodenlose Frauenquote. Warum also mit solchen Bildern die Branche beschreiben? Soll es dadurch besser werden? Motto: “Wir zeigen mal die Verhältnisse, die wir uns wünsche, dann ziehen wir Frauen an, sich bei uns zu bewerben.”

Oder ist es eher wie bei Truckermagazinen? Motto: “Wir zeigen Mädels im Team, dann bewerben sich die hormongesteuerten männlichen Entwickler bei uns.” Wobei sowohl Trucker wie Entwickler wissen, dass nicht immer Mädels drin sind, wo sie drauf sind.

Tja… ich weiß nicht. In jedem Fall sind mir beide Bilder sehr ins Bewusstsein gesprungen ob ihrer Entfernung von der Realität. Das bedaure ich. Ich bedaure es sogar umso mehr, je öfter ich Trainings mache, in denen wir konsequent im Team Anforderungen analysieren/verstehen, Architektur und Modell entwerfen und schließlich die Arbeitsorganisation planen. All diese Teamtätigkeiten würden sehr von “weiblichen Elementen” profitieren. Dazu zähle ich unter anderem – man verzeihe mir eventuelle Klischeehaftigkeit – “weniger Technikverliebheit”, “mehr Kommunikationskompetenz”, “mehr Servicewille”, “mehr Blick für´s Ganze”.

Was müssen wir als Branche tun, um das zu ändern? Wie können wir die bodenlose Frauenquote erhöhen? Wie können wir unsere Arbeit für Mädchen/Frauen interessanter machen? Das ist natürlich vor allem eine Herausforderung der Ausbildung. Klar. Aber ich denke auch, dass es um Marketing geht. Wo ist die Branchendarstellung, die ein anderes Bild zeichnet von der Softwareentwicklung? Aber auch die Personalabteilungen sind gefordert. Sie sollten ihre Forderungen an den Entwickler(innen)markt überdenken. Sie sollten ihre internen Förderungen von noch-nicht Entwicklerinnen überdenken. Und es hilft sicherlich nicht, Wunschdarstellungen wie die obigen aus “political correctness” heraus zu bringen, ohne einen Plan zu haben, wie sie denn materialisiert werden könnten.

Ein kleiner Baustein für Veränderung mögen Initiativen wie diese sein:

Hier werden speziell Frauen angesprochen, sich einen Einstieg in die Softwareentwicklung vorzustellen. Etwas mehr Erklärung, warum das sinnvoll sein könnte jenseits von “Da kannst du Geld verdienen”, mag noch helfen. Klar. Aber es ist ein Anfang.

Wo sind weitere Initiativen, die sich an Mädchen/Frauen richten, um Ihnen zu zeigen, dass Softwareentwicklung von ihren “Gender-Kompetenzen” profitieren kann? Und dass das natürlich Spaß macht. Beiden Geschlechtern :-)

Vom Wert des Schätzens im Angesicht real möglicher Unproduktivität

Ob Softwareentwickler Aufwand schätzen können oder nicht… Das lasse ich zur Abwechslung heute mal dahingestellt. Stattdessen frage ich mal: Was sagen Schätzungen denn eigentlich aus?

Szenario 1: Ein Manager fragt seine Frau, wie lang sie für den Weihnachtsbraten wohl braucht. Sie schätzt, dass es wohl 3 Stunden sein werden.

Szenario 2: Ein Manager fragt den Klempner seines Vertrauens, wie lang er wohl für die Badezimmerrenovierung inkl. Austausch der Steigleitungen braucht. Er schätzt, dass es wohl 6 Tage sein werden.

Szenario 3: Ein Manager fragt seinen Entwickler, wie lang der wohl für eine Zahlungseingangs- und Mahnwesen-Anwendung braucht. Der schätzt, dass es wohl 5 Wochen sein werden.

Der geneigte Leser prüfe sich nun, wie er die Schätzungen in den drei Szenarien einschätzt. Sind die alle gleich vertrauenswürdig? Wenn nein, wodurch unterscheiden sich die Szenarien?

In allen Szenarien sind in der Sache grundsätzlich Erfahrene befragt worden. Ich hoffe, da sind wir uns einig. Ja, die Größenordnungen liegen auseinander – Stunden, Tage, Wochen –, aber da sehe ich nicht das Problem. Wenn Erfahrene sich verschätzen, dann doch wohl um einen nicht allzugroßen Prozentsatz, oder? Aus 3 Stunden könnten 4 werden; die Hausfrau hätte sich um 33% verschätzt – aber, hey, das kann doch passieren, oder? Aus 6 Tagen können 8 werden; hey, kein Problem, sowas kann passieren, oder? Oder aus 5 Wochen werden 6 Wochen. Wer hätte das nicht schon bei Softwareentwicklung erlebt. Alles normal, oder?

Das Problem sehe ich nicht beim Verschätzen. Ich glaube zwar immer noch, dass sich Hausfrau und Klempner weniger verschätzen als Softwareentwickler – aber für heute mal egal. Lassen wir sie alle gleich gut schätzen und sind wir mit 33% Überziehung zufrieden. Es könnte schlimmer kommen.

Nein, das Problem liegt woanders.

Szenario 1: Wie lange würde die Frau des Nachbarn des Managers für denselben Weihnachtsbraten wohl brauchen? Die schätzt auf 2 Stunden. Und der Mann der Chefin des Managers? Der würde auf 5 Stunden schätzen.

Szenario 2: Wie lange würde der Schwager des Managers als Heimwerker für die Badrenovierung brauchen? Vielleicht 10 Tage. Und wie lange würde der Großklempner am anderen Ende der Stadt schätzen? Vielleicht 4 Tage.

Bei Szenario 1 und 2 ist es relativ egal, wen man nach einer Schätzung fragt. Wenn der potenzielle Auftragnehmer einigermaßen erfahren in der Sache ist, dann werden die Schätzungen vielleicht um 50%-100% differieren. Hört sich viel an – ist es aber nicht. Denn:

Szenario 3: Wie lange würde der Schwager des Managers für die Anwendung brauchen? Vielleicht 5 Monate. Wie lange würde der Senior-Entwickler aus dem anderen Team brauchen, der leider unabkömmlich ist? Vielleicht 5 Tage.

Damit sind wir beim Kern des Schätzproblems der Softwareentwicklung: der ungewissen Produktivität.

In der Softwarebranche differiert die Produktivität einzelner Entwickler um mehr als eine Zehnerpotenz – unabhängig von der Erfahrung. D.h. der eine Entwickler braucht für eine Aufgabe 1 Stunde, der andere bis zu 10 Stunden und mehr. Das fängt schon beim Allersimpelsten an. Ich habe es selbst oft getestet mit Entwicklern, die ich in Trainings, in Bewerbungsgesprächen und bei Beratungen treffe. Denen gebe ich eine ganz, ganz einfache Aufgabe; manche brauchen dann 30 Sekunden, um sie zu lösen – und andere brauchen mehr als 3 Minuten. Wohlgemerkt für eine Sache, wo es keine zwei Meinungen gibt und das Ergebnis max. 5 Zeilen Code umfasst.

In anderen Branchen gibt es natürlich auch Produktivitätsunterschiede. Ein Koch mag doppelt so schnell sein wie der andere, ein Klempner gar dreimal so schnell wie der andere. Im Einzelfall ist es dann misslich, wenn man an den langsamen Vertreter einer Zunft gerät – aber eigentlich ist der Unterschied fast vernachlässigbar gegenüber dem in der Softwarebranche.

Das nun mal in Anschlag gebracht für das Schätzen: Wenn die Produktivität um den Faktor 10 differiert und ein Entwickler schätzt Aufwand… was sagt mir dann die Schätzung?

Sie sagt mir nur, dass der Entwickler ca. so lange braucht, wie er schätzt. Der Manager in Szenario 3 hört 5 Wochen, denkt sich seinen Teil, drückt den Entwickler dann auf 4 Wochen (weil Entwickler ja immer trödeln und Puffer einrechnen) – und ist zufrieden.

Was der Manager nicht weiß ist, wie produktiv der Entwickler ist. Er kennt die Güte des Entwicklers nicht oder höchstens in Bezug auf andere Entwickler in seinem Team, von denen er auch nicht weiß, wie gut sie sind. Der Manager weiß wahrscheinlich nicht einmal, dass der Faktor 10 und höher für den Produktivitätsunterschied in der Branche ist.

Dasselbe gilt natürlich für Teams. Vielleicht nivellieren sich im Team die Unterschiede aus – aber ist dann nur noch ein Faktor 5 gültig? Nein, ich denke er ist höher. Das liegt daran, dass die Ausbildung in unserer Branche so notorisch uneinheitlich und damit unzuverlässig ist. Wirklich gute Entwickler sind viel seltener – so mein Gefühl – als wirklich schlechte Entwickler.

Selbst wenn ein Kunde also Angebote einholt für ein größeres Projekt – die reichen von 2000 PT über 2500 PT bis zu 3200 PT –, weiß er nichts darüber, wieviel Geld er womöglich verschenkt, weil sich das Problem eigentlich auch in 750 PT erledigen ließe – wenn denn wirklich gute Teams geschätzt hätten.

Nun mag man sagen, “Tja, so ist es halt in der Softwareentwicklung…” Aber ich halte mal dagegen: Ist das nicht ein erbärmlicher Zustand? Wird da nicht volkswirtschaftlicher Schaden angerichtet, wenn die Produktivitätsunterschiede de facto so groß sind und es keiner in der Branche thematisiert und kein Kunde weiß?

Was hat da Schätzen noch für einen Wert? 6 Tage oder 10 Tage für die Badrenovierung… geschenkt. Mehrere Wochen statt 5 Tagen aber… da sollte jeder Manager, jeder Controller hellhörig werden. Das passiert aber nicht. Stattdessen reibt sich der Manager die Hände, weil er aus 5 Wochen Schätzung 4 Wochen gemacht hat. Er sieht nur das Geld, was er (vermeintlich) gespart hat, aber nicht das Geld, das er verpulvert, indem er einen schlechten Entwickler beschäftigt.

Fassen wir uns alle mal an die Nase und fragen: Wie produktiv bin ich eigentlich?

Und dann frage man sich: Wie produktiv könnte ich sein? Wie produktiv kann “man” sein? Wie stelle ich eigentlich fest, ob ich produktiver geworden bin über die Jahre?

“Ein Entwickler hat das im Gefühl” könnte die Antwort darauf frei nach Loriot sein. Aber ist das wirklich genug für eine Branche, die so wirtschaftsentscheidend ist wie die Softwarebranche? Das bezweifle ich.

Es ist zutiefst unbefriedigend, dass die Produktivitätsunterschiede so groß sind. Dafür kann der Ausbildung nur die Note 5 gegeben werden.

Und es ist zutiefst beängstigend, dass das Kunden offensichtlich nicht wirklich bemerken. Denn das zeigt einen verantwortungslosen Umgang mit dem hart erarbeiteten Geld ihrer Mitarbeiter.

Also: Bei der nächsten Schätzung die man einholt, einfach mal fragen: Wie gut ist der eigentlich, der da schätzt? Könnte es sein, dass es auch in der halben oder gar einem Viertel der Zeit ginge?

Wer darauf reagiert mit, “Kann ich ja eh nicht ändern. Hab nur den Entwickler/das Team”, der hat dann leider nicht begriffen, dass man mit Ausbildung und Übung die Produktivität steigern kann.

 

PS: Natürlich lässt sich darüber nachdenken, warum der Zustand in der Branche so ist, wie er ist. Das Umfeld muss es ja hergeben, dass solche Produktivitätsunterschiede überhaupt über Jahrzehnte existieren können. Meine Vermutung:

1. Laien glauben nicht, dass es so sein kann. Deshalb hinterfragen sie die Leistungen nicht. Und Entwickler selbst glauben das auch nicht – bis sie mal mit ihren Leistungen im Vergleich konfrontiert werden.
2. Das Metier ist so “ehrfurchtgebietend” oder esoterisch, dass sich Laien nicht an solch kritische Fragen trauen.
3. Laien sind so glücklich darüber, dass es am Ende irgendwie überhaupt läuft, dass sie sich mit solchen Fragen nicht beschäftigen.
4. Die Branche selbst hat kein Interesse, ihre hohen Aufwände zu reduzieren. Wenn sich mit billigen schlechten Entwickler Geld verdienen lässt, warum dann in gute investieren.
5. Die formale Ausbildung ist an solch weltlichen Details wie Produktivität nicht interessiert. Und die Selbstbildung kann sowieso eher nicht leisten, Produktivität systematisch zu steigern.

 

PPS: Und nun? Ich behaupte mal: Wer diese Erkenntnis ernst nimmt und sein Team nur um 25% beschleunigt (auch das ja nur relativ zu bisheriger Performance), der hat die Nase vorn im Wettbewerb. Und ich behaupte sogar: Dabei kann die Qualität der Arbeit nur steigen – wie auch die Motivation. Warum? Weil Menschen, die sich ernst genommen fühlen, lieber arbeiten und gute Arbeit abliefern. Ganz zu schweigen davon, dass höhere Produktivität nur mit Mittel erreichbar ist, die auch höhere Qualität bringen. Command/Control und Zuckerbrot/Peitsche gehören nicht zu diesen Mitteln.

Kollektiv intelligent codieren

Wenn ein einzelner Entwickler etwas codiert, dann hat das Ergebnis eine gewisse Qualität. Und wenn mehrere Entwickler zusammen etwas codieren, dann sollte das eine höhere Qualität haben. Oder?

Wie die sprießenden Coding Dojos zeigen, ist das nicht der Fall. Da mag der Spaß noch so groß sein, da mag die Motivation hoch fliegen – die Ergebnisse sind meist schlechter, als wenn ein einzelner Entwickler dasselbe probiert. Wenn nach 2 Stunden zwei 5zeilige Tests stehen und noch vielleicht 10 Zeilen Domänenlogik, ohne dass abzusehen wäre, wann die Aufgabe ganz gelöst sein wird, dann ist das ziemlich wenig.

Wie kann das aber sein, was geht schief beim Coding Dojo? Warum bleibt das Kollektiv der Dojo-Teilnehmer hinter Einzelleistungen verlässlich zurück? Oder sehe ich das ganz falsch und nichts geht schief? Ist das einzig schiefe der Sitz meiner Brille, durch die ich das Coding Dojo sehe?

Die anhaltende Diskussion (s. z.B. hier oder hier oder hier) über Sinn und Zweck von Coding Dojos lässt mich nun vermuten, dass die Diskutanten (mich eingeschlossen) aneinander vorbei reden.

Also setze ich heute mal meine übliche Brille erstmal ab und stecke mir eine Lupe aufs Auge.

Struktur von Dojo-Problemlösungen

Worum geht´s denn beim Dojo überhaupt? Es wird ein Szenario präsentiert, zu dem die Teilnehmer zusammen eine Lösung in Form von Code entwickeln sollen. Ob der Code durch einen Stellvertreter (Code Monkey) eingegeben wird, den die Gruppe “fernsteuert” oder ob Gruppenmitglieder reium den Code eingeben, ist an dieser Stelle nicht so wichtig. Ebenfalls noch nicht so wichtig ist, dass Dojos einen bestimmten Weg der Implementation favorisieren: das TDD.

Entscheidend ist die Art der Aufgabe: Übersetzung von Anforderungen in Code.

Diese Art der Aufgabe hat es nämlich in sich. Sie besteht aus zwei Phasen, die auch mehrfach durchlaufen werden können:

• Phase 1: Kreativphase
• Phase 2: Umsetzungsphase

Zwischen Anforderungen und “Produkt” steht mithin eine Barriere. Das ist der Entwurf des Produktes. Wie ein Produkt aussieht, ergibt sich nämlich nicht einfach so. Bevor man ein Produkt bauen kann, muss man eine Vorstellung davon haben, wie es aussehen soll.

Ein Bild vom Produkt, von der Lösung zu entwickeln, das ist nun ein kreativer Prozess. Aus den scheinbar oder tatsächlich möglichen Lösungen ist eine auszuwählen.

Ist die Auswahl getroffen, kann sie umgesetzt werden. Umsetzung erfordert also Klarheit in der Vorstellung, was umgesetzt werden soll.

Lösungsfindung und Umsetzung sind ganz verschiedene Tätigkeiten. Sie sind so verschieden, dass die Psychologie dafür zwei Arten des Denkens unterscheidet: divergentes Denken (oder auch laterales Denken) und konvergentes Denken.

Divergentes Denken ist in der Kreativphase nötig, konvergentes Denken in der Umsetzungsphase. Die Umsetzung ist also kein “no brainer”, sondern erfordert auch Denken. Denn selbst wenn die Lösungsstruktur grundsätzlich klar ist, bedarf die Umsetzung durchaus noch weiterer Entscheidungen. Umsetzung kann weit entfernt von “Malen nach Zahlen” sein. Umsetzung braucht Erfahrung und Kompetenz.

Sind Erfahrung und Kompetenz nicht aber auch für die Lösungsfindung (Kreativphase) wichtig? Interessanterweise sind Erfahrung und Kompetenz, also Expertentum, überbewertet, wenn es um kreative Lösungen geht. Lösungssuchende Gruppen sollten sich daher um Heterogenität bemühen; sonst schmoren Experten zu sehr in ihrem eigenen “Denksaft”. Der Horizont von homogenen Gruppen ist schlicht enger als der von heterogenen.

Fazit bis hierher: Wenn ein Coding Dojo daran interessiert ist, Anforderungen mit Code umzusetzen, dann ist es gut beraten, die zwei grundsätzlichen Phasen auf dem Weg dahin zu beachten. Ein Dojo muss sich also überlegen, wie es divergentes und konvergentes Denken herstellt.

Divergentes Denken in der Gruppe

Kollektive können gut divergent denken. Kollektive Intelligenz kann bei Problemen, die divergentes Denken erfordern, individueller Intelligenz relativ leicht überlegen sein. Ein Coding Dojo ist also gut aufgestellt, schöne Lösungsansätze für die gegebenen Anforderungen zu finden, da die Teilnehmergruppe gewöhnlich sehr heterogen ist.

Allerdings braucht es dafür eine Voraussetzung: das Dojo muss überhaupt eine Kreativphase durchlaufen. Nach Verständnis der Anforderungen muss es eine Phase geben, in der die kollektive Intelligenz divergent denkt. Ob diese Phase 3 Minuten oder 30 Minuten dauert, sei dahin gestellt. Das hängt ja auch vom Problem ab. Aber ohne eine solche Phase, d.h. einen Zeitraum im “Divergenzdenkmodus”, gibt es keinen Lösungsansatz.

Und wie sieht eine solche Kreativitätsphase aus? Was tun die Gruppenmitglieder da? Meine Vorstellung davon sieht so aus:

• Am Anfang der Kreativphase steht eine Stillarbeitsperiode. Jeder überlegt für sich, wie er/sie die Lösung gestalten würde. Warum Stillarbeit, wenn doch alle in der Gruppe sitzen? Weil sonst bei der folgenden Diskussion leicht die “Lauten”, die “Redseligen”, die “Schnelldenker” sich durchsetzen. Wird ohne einen Moment der stillen Besinnung gleich das kreative Getümmel eröffnet, haben “Leise” und “Langsame” wenig Chance, ihre womöglich besseren Ansätze zu Gehör zu bringen. Ohne Stillarbeit reduziert das Kollektiv also sein Potenzial – und nicht unbedingt auf die Kompetentesten. Hierzu mehr in “Group Genius”.
• Auf die Stillarbeit folgt die Diskussion der verschiedenen Lösungsansätze. Die Gruppe trägt zusammen, was die Heterogenität ausgebrütet hat. Dabei sollten am besten alle (!) Teilnehmer gehört werden. Auch das wieder eine Maßnahme, um kompetente Zurückhaltende nicht zu verlieren.
• Die Sammlung der Lösungsansätze erfolgt am besten am Flipchart/Whiteboard. Visual Studio oder eine Diagrammsoftware haben hier keinen Platz. Sie sind schlicht zu beschränkend. Die Kreativitätsphase braucht alle Freiheit und Flexibilität, die sie bekommen kann. Mit einem Stift in der Hand auf einer großzügigen Fläche ist sie am größten.
• Lösungsansätze sind keine Programme. In der Kreativphase wird nicht codiert. Es geht um ein Denken auf hohem Abstraktionsniveau. Es geht ums Modellieren. Stefan Lieser hat dafür ein Beispiel in seinem Blogartikel gebracht: eine Sequenz von Kullern (Funktionseinheiten mit klarer Verantwortlichkeit) war sein Modell für die Kata BankOCR. In seiner Lösungsskizze ist keine Klasse zu sehen. Und er hat sich auch nicht durch VS oder TDD oder C# behindern lassen. Wo ein konkreter C# Typname auftaucht, ist der auch nicht ganz scharf als Programmiersprachenkonstrukt gemeint. Er ist für Stefan eher nur ein Platzhalter oder ein Ausrutscher in eine andere Sprache. Ein Idiom, dass knackig eine Intention ausdrückt. Mehr nicht.
• Damit die Kreativphase auf eine Lösung hin konvergiert, muss am Ende irgendwie gefiltert werden. Entscheidungen sind zu treffen. Wie Stefan bin ich der Meinung, dass dafür ein Konsens (Abstimmung) der denkbare falsche Ansatz ist. Im Konsens steckt nämlich kein Bezug zur Sache. Warum jemand die Hand bei einer Abstimmung hebt oder nicht, ist nicht erkennbar. Vielleicht ist sie von einer Lösung überzeugt, vielleicht genervt (und will deshalb schnell einen Mehrheitsbeschluss, damit es weitergeht), vielleicht unentschieden, aber von einem anderen Teilnehmer persönlich beeindruckt. Eine Abstimmungsmehrheit sagt nur aus, dass für einen Lösungsansatz aus irgendwelchen Gründen mehr Leute die Hand gehoben haben als für einen anderen. Das war´s. Alles andere ist eine hübsche Illusion. Konsens/Demokratie gehört in den Bereich der Politik und nicht in den der Wissenschaft oder des Ingenieurwesens.
  Aber was dann? Statt für Konsens plädiere auch ich für Konsent. Der Begriff kommt aus der Soziokratie und ist hier und hier und hier näher beschrieben. Bei Konsententscheidungen geht es nicht darum, eine Mehrheit für einen Vorschlag zu finden. Wer dafür ist, ist quasi egal. Stattdessen sucht der Konsent nach Widerstand. Er wird daher auch die “Herrschaft des Arguments” genannt. Damit kommt die Sache ins Entscheidungsbild. Widerstände müssen sich nämlich auf den Vorschlag und die Sache bzw. ihren Kontext beziehen. Müdigkeit oder persönliche Beeindruckung haben da keinen Platz. Wer Widerstand leistet, d.h. einen begründeten Einwand hat, der muss auch persönlich hervortreten und sich erklären; damit auch hier keine Stimme untergeht, wird im Konsentprozess ebenfalls jedes Gruppenmitglied befragt. Das fokussiert die Diskussion ungemein. Konsententscheidungen sind daher effizient und effektiv. Das kann man von Abstimmungen nicht so einfach behaupten. Denn Mehrheit bedeutet nicht Effektivität (das Richtige entscheiden) und Mehrheit bedeutet auch nicht Effizienz (schnell entscheiden). Wie wir aus der Politik wissen, kann es bis zu einem Konsens lange dauern. Mehr zum Thema z.B. in meinem Vortrag “Agile Entscheidungen” auf dem Mathema Herbstcampus.

Zweck der Kreativphase ist es, den umzusetzenden Lösungsansatz zu finden. Dabei stolpert die Gruppe selbstverständlich über Lücken oder Divergenzen im Verständnis der Anforderungen. Die Kreativphase überlappt daher mit der vorgelagerten Phase der Anforderungserfassung. Die habe ich oben jedoch nicht aufgeführt, weil sie nicht direkt mit der Softwareentwicklung zu tun hat. Softwareentwickler erheben keine Anforderungen, sondern müssen sie “nur” verstehen. Wer mag, darf aber gern Phase 0: Anforderungserfassungsphase vor die Kreativphase setzen.

Nicht nur durch die Diskussion und weiterentwicklung verschiedener Lösungsansätze, sondern auch den “Rücksprung” in die Anforderungserfassung ist die Kreativphase also kein linearer Prozess. Sie ist “non routine work” und damit auch außerhalb der Reichweite von üblicher motivations-/produktivitätsfördernden Maßnahmen. Zuckerbrot oder Peitsche wirken nicht, um die Kreativitätsphase zu befördern. Im Gegenteil. Soviel als Anmerkung zur Arbeit in Projekten, die ja noch ausgeprägtere Kreativitätsphasen brauchen. Wer das nicht glaubt, der siehe hier.

Fazit: Lösungsansätze in der Softwareentwicklung entstehen nur in einem kreativen Prozess. Heterogene Kollektive können in so etwas gut sein. Allerdings braucht es dafür Raum und Struktur. Drauflosreden und Abstimmungen sind nicht genug. Gerade divergentes Denken muss also moderiert werden. Das Kollektiv soll sich ja auf den Inhalt konzentrieren, nicht auf die Form. Auch hier gilt wieder das Single Responsibility Principle.

Konvergentes Denken für die Umsetzung

Die Umsetzung eines Lösungsansatzes ist etwas anderes als den Lösungsansatz zu finden. Die Umsetzung braucht kein divergentes Denken, kein Querdenken, keine Vielfalt – sondern System. Bei der Umsetzung ist konvergentes Denken gefragt. Das greift auf einen Fundus an Erfahrungen und Techniken zurück. Es übersetzt den Lösungsansatz als Modell in die konkrete Welt der Implementationstechnologien.

Konvergentes Denken ist nun allerdings in der Gruppe schwierig. Tut mir leid, das berichten zu müssen. Aber so ist es. So sagt es die Psychologie. Wo beim divergenten Denken eine heterogene Gruppe hilft, da hilft beim konvergenten Denken eine homogene Gruppe, also eine Expertenrunde.

Wenn ein Coding Dojo nun aber eine heterogene Gruppe darstellt und vor allem eben keine Experten zum Thema TDD zusammenkommen (sondern Entwickler, die es lernen wollen), dann kann ein Coding Dojo per definitionem für die Umsetzung keine guten Voraussetzungen bieten.

In diesem Licht erscheint es doppelt kontraproduktiv, die Kreativphase wie im letzten Coding Dojo anlässlich des dotnetpro.powerday zu überspringen. Nicht nur wurde kein Lösungsansatz erarbeitet, nein, es wurde die Gruppe sogar sofort in die Phase gestoßen, für die sie am schlechtesten aufgestellt ist. Weder existierte also eine gemeinsame Vorstellung von der Lösung, noch eine gemeinsame Vorstellung von der Umsetzung.

Vielleicht ist Ilker da zurecht stolz auf 2 grüne Tests und ca. 10 Zeilen Domänenlogik für die Kata BankOCR gewesen. Denn bei so schlechten Voraussetzungen ist beides vielleicht eine Leistung.

Frustrierend empfinde ich das Ergebnis dennoch. Denn die Gruppe ist um größere Erfolge betrogen worden, weil man nicht “artgerecht” mit ihr umgegangen ist.

Wie hätte es denn aber besser aussehen können? Meine Vorstellung von einer “artgerechten” kollektiven Umsetzungsphase sieht so:

• Das Coding Dojo definiert explizit, worauf bei der Umsetzung geachtet werden soll. Das kann einmalig geschehen (“Bei allen unseren Dojo achten wir bei der Umsetzung auf ABC und XYZ.”) oder für jedes Dojo immer weder neu (“Heute wollen wir uns auf XYZ bei der Umsetzung konzentrieren.”).
  Wichtig ist in jedem Fall die ausdrückliche Formulierung eines Umsetzungsrahmens. Denn nur so kann das Dojo bei der Umsetzung effizient gehalten werden. Kommentare, die sich auf Verhaltensweisen beziehen, die nicht im Fokus der Umsetzung liegen, müssen nicht verfolgt werden. Das entspricht wieder dem Konsentprinzip.
• Während der Umsetzung übernehmen einer oder mehrere Experten in Bezug auf die Umsetzungsgrundsätze die Moderation. Sie setzen selbstverständlich nicht allein um; die Gruppe soll so gut es geht auch die Umsetzung vorantreiben. Aber die Experten leiten die Gruppe an. Sie halten die Gruppe im Rahmen der Umsetzungsgrundsätze, geben Hilfestellungen, regen an, erklären.
  Experte kann jeder sein, der sich in Bezug auf Umsetzungsgrundsätze berufen fühlt. Dazu muss niemand eingeflogen werden. Auch der sprichwörtliche Einäugige kann die Blinden anleiten. D.h. wenn sich auch nur einer aus der Gruppe etwas mehr mit einem Umsetzungsgrundsatz auseinandergesetzt und eine Meinung dazu entwickelt hat, kann er die Moderation über nehmen – und sollte es auch.
• Nach der Umsetzung folgt selbstverständlich eine Reflexion. Wer mag, kann sie als Phase 3 ansehen. Darauf möchte ich hier aber nicht näher eingehen.

Warum braucht das Kollektiv bei der Umsetzung eine Moderation in Bezug auf die Umsetzungsgrundsätze? Weil die Gruppe zusammengekommen ist, um eben diese Grundsätze zu lernen. Wo aber keine/nur wenig Kompetenz ist, entwickelt die sich nicht spontan aus ungeleiteten, tappenden Versuchen einer heterogenen Gruppe.

Wenn man 10jährige in einem Raum sperrt mit einem Haufen elektrischer Bauteile und dem Auftrag, eine Lampenwechselschaltung zu bauen, ist kaum zu erwarten, dass da etwas herauskommt. Die Gruppe wird sich nicht das Wissen aneignen können. Zusammen mit einem Lehrer jedoch ist das möglich. Der baut die Schaltung nicht selbst, lenkt aber immer wieder die Aufmerksamkeit. Didaktik und Methodik müssen stimmen. Dann findet effizientes und effektives Lernen statt.

Bei einem Coding Dojo ist das nicht anders. Ohne Anleitung findet kein verlässliches Lernen in Bezug auf die ausgelobten Inhalte statt. Das sind meist die Umsetzungsgrundsätze (z.B. TDD, Architektur, OOP). Experten führen die Gruppe hin zur Kompetenz in Bezug auf die Umsetzungsgrundsätze. Sie greifen dabei so wenig wie möglich in den Gruppenprozess ein, aber soviel wie nötig, um den Fokus zu halten.

Irgendwas kann natürlich jeder auch ohne Anleitung lernen. Ich z.B. habe beim letzten Dojo gelernt, wie man rechteckige Blöcke in VS2010 markiert. So nett das aber auch ist, dafür gehe ich nicht ins Coding Dojo. Das kann ich auch bei einer Plauderei einer .NET User Group erfahren.

Fazit: Damit die Umsetzung eines Lösungsansatzes zügig und erfolgreich ist, braucht es Können. Wo das Können fehlt, muss es über Experten in die Gruppe eingebracht werden. Aber auch wo das Können schon in der Gruppe ist, braucht es Moderation für eine kohärente Arbeit der Gruppe.

Kollektive Intelligenz mit System

Ich schätze Ilker für seine hochmotivierte Art, Dojos durchzuführen. Und ich schließe mich seinen Latifa-Werten an.

Aber ich möchte bei ihnen nicht stehenbleiben. Sie sind für mich nur ein Rahmen, in dem für mich das eigentliche Lernen stattfindet. Und dafür ist meine Vision, dass es verlässlich stattfindet in Bezug auf klar kommunizierte Ansätze in der Umsetzungsphase oder auch der Kreativphase.

Darüber hinaus bin ich auch der Überzeugung, dass solches Lernen nur funktioniert, wenn es nicht eine gewisse Führung gibt. Im besten Fall versteht die mehr vom Lerninhalt als der Rest der Gruppe. Sollte das jedoch einmal nicht der Fall sein, ist noch nicht alles verloren. Allerdings muss die Moderation dann besonders sensibel sein.

Bei allem Willen zu Spaß beim Dojo und selbstverständlich grundsätzlicher Gleichberechtigung aller Teilnehmer glaube ich allerdings nicht, dass demokratische Anwandlungen oder “code first” Denke zielführend sind.

Mir scheint, dass die bisherigen Dojos die Kompliziertheit von Problemen unterschätzen und die Leichtigkeit, mit der sich Ansätze wie TDD lernen lassen, überschätzen. Sie glauben, ohne Kreativitsphase (oder gar Anforderungserfassungsphase) auszukommen. Sie glauben, ohne Expertenmoderation in der Umsetzungsphase auskommen zu können. Ihr Credo: “Durch den Code zur Wahrheit und zur Erkenntnis”

Dass es nicht so einfach ist, zeigen dann aus meiner Sicht die magerer Erfolge der Dojos. Wie gesagt: Irgendwas wird schon gelernt. Aber wird das gelernt, was sich die Dojo-Macher wünschen? Ich bezweifle es. (Wenn Sie sich überhaupt etwas wünschen jenseits des Barnum-Mottos “Hier ist für jeden was dabei.”)  Wird gelernt, was sich die Teilnehmer wünschen? Ich bezweifle es. (Wenn die überhaupt einen konkreten Lernwunsch haben und nicht bloß aus Neugierde kommen.)

Damit will ich nicht das Engagement bisheriger Dojo-Macher kritisieren. Im Gegenteil! Ich finde es sehr cool, dass wir hier in der .NET-Welt eine solche Szene entwickelt haben und eifrig diskutieren. Nochmal danke an Vorreiter Ilker!

Aber was am Anfang gut und ausreichend gewesen sein mag, ist es vielleicht jetzt nicht mehr. Der Geschmack kommt beim Essen. Und da es nun Katas und Dojos gibt, ist es – so scheint mir – an der Zeit, weiter zu gehen. Bisher war Dojo 1.0. Ich möchte jetzt Dojo 2.0. Ich möchte Coding Dojos nach oben skizziertem Schema, die noch mehr bieten als die bisherigen. (Oder vielleicht nicht mehr, sondern Anderes.)

Und deshalb präge ich jetzt mal einen weiteren Dojo-Stil: den Schwarm-Stil. Ilkers Stil ist der Latifa-Stil, meiner der Schwarm-Stil. Warum Schwarm in der Stilbezeichnung? Das ist für mich eine Anspielung auf das Buch “Der Schwarm” von Frank Schätzing. Darin kommt eine Intelligenz vor, die sich aus “sichtbaren” Individuen zusammensetzt, eine kollektive Intelligenz, eine Schwarmintelligenz.

Mir ist klar, dass am Begriff Schwarmintelligenz eine Menge hängt, was nicht zum Coding Dojo passt. Aber egal ;-) Ich finde ihn knackig und es steckt auch das Kollektiv drin.

Jetzt stellt sich nur die Frage, wann und wo das erste Schwarm-Stil Coding Dojo stattfindet. Mal überlegen… Wenn es konkreter wird, berichte ich hier im Blog.

Gemeine Kenntnislücken

In der dotnetpro 5/2010 habe ich in meiner Sandbox-Kolumne beklagt, dass viele .NET-Entwickler heute nicht vertraut sind mit Lambda-Funktionen oder der Funktionsweise von yield return (C# Iteratoren). Daraufhin bekam ich folgende Zuschrift eines Lesers:

“[I]n deiner neusten Sandbox ziehst du ja ganz schön über uns Entwickler her! Ich bin der Meinung, dass das ziemlich gemein ist.”

Das hat mich schon ein wenig getroffen. Denn “gemein” möchte ich ja nicht sein. Gemein findet der Leser es, dass ich die Unkenntnis von Jahre alten und grundlegenden Features des Hauptwerkzeugs von .NET-Entwicklern kritisiere, denn…

“Wenn ich meine tägliche Arbeit als Entwickler reflektiere, bin ich der Meinung das [m]an fast keine Change hat sich in alle neuen Technologien einzuarbeiten. Der tägliche Projektablauf ist halt mehr auf Codegenerierung ausgelegt. Es gibt halt von Seiten des Managements oft keine Toleranz für Weiterbildung oder den Einsatz von neuen Technologien.”

Leider liegt hier ein Missverständnis vor. Ich habe eben nicht gesagt, dass “man” (also jeder Entwickler) sich in “alle neuen Technologien” einarbeiten muss. Ich habe vielmehr geschrieben: “Zugegeben, niemand muss alles beherrschen. Und niemand kann alles beherrschen.” Und selbstverständlich habe ich Verständnis dafür, wenn im Projektdauerstress Veränderungen an Konzepten und Technologien nicht sofort nachvollzogen werden. Das kennen wir ja auch alles schon. Ja, ich weiß, lieber Leser:

“Es gibt halt von Seiten des Managements oft keine Toleranz für Weiterbildung oder den Einsatz von neuen Technologien.”

Deshalb habe ich ja eben auch nicht über die neueste Mode gesprochen und schon gar nicht über VS2010/.NET 4. Es ging mir um Features, die Jahre (!) alt sind. Es ging mir um Features des Haupt(!)werkzeugs. Nix Esoterisches.

Eine Analogie mag helfen: Wer einen Klempner trifft, in dessen übervollen Werkzeugkasten eine Bohrmaschine liegt, dessen Knöpfe er nicht erklären kann, der wird sicherlich Zweifel an der Professionalität des Klempners haben. Eine Bohrmaschine gehört zu dessen wichtigsten Werkzeugen (nehme ich an ;-). Die muss er auf dem Effeff beherrschen. Ist es dann gemein, wenn diese Unkenntnis hervorhebt und beklagt?

Nein. Natürlich ist das nicht gemein. Ich kann alles mögliche Verständnis dafür haben, warum der Klempner in den vergangenen 5 Jahren keine Zeit hatte, die Bohrmaschinenknöpfe kennenzulernen. Immer soviel zu tun. (Oder eher sowenig?) Ja, ja, schon schlimm die Auftragslage.

Doch das ändert nichts daran, dass er sein Werkzeug nicht beherrscht. Und damit frage ich mich, ob er für mich einen guten Job machen kann. Kann er die Löcher in bester Weise bohren, wenn er die Schlagbohrfunktion nicht kennt? Hm… wahrscheinlich nicht immer.

Jetzt zurück zur Softwareentwicklung. Hier ein Beispiel für die Arbeit eines Entwicklers, der nicht firm in der Verwendung von Lambda-Funktionen ist:

Ist das gut lesbar? Kaum.

Hier der Code lesbarer gemacht:

Und jetzt überlege man einmal, wie viel es ein Unternehmen jedes Mal kostet, wenn Entwickler Änderungen an schwer lesbarem Code vornehmen sollen. Dauert das 5% länger oder 10% oder gar 50%? In jedem Fall dauert es jedes, jedes Mal messbar länger.

Natürlich kostet es auch Zeit, sich mit Lambda-Funktionen auseinander zu setzen. Vielleicht 1-2 Tage. Das ist allerdings Zeit, die nur einmal anfällt. Danach stehen die Kenntnisse zur Verfügung und können helfen, Code z.B. lesbarer zu machen.

Stehen Sie nicht zur Verfügung, dann ist es ein Fass ohne Boden, wie oft Mehraufwand zu treiben ist. Das misst zwar keiner – aber es ist viel, viel teurer. Und es wird beklagt. Keine Sorge. “Warum dauert das schon wieder so lange mit dem neuen Feature?” ist (allermeistens) eine indirekte Klage darüber, dass Code unstrukturiert oder unlesbar ist. Dem, der klagt, fehlt zwar das Verständnis für den Kausalzusammenhang. Aber die Ursache ist dennoch dieselbe: mangelnde Werkzeugkenntnis. Ist das gemein? Ja, ich würde sagen, das ist gemein. Denn der, der klagt, ist wahrscheinlich gleichzeitig der (Mit)Verursacher der Unkenntnis.

Und nochmal: Ich rede nicht über exotische Features der Workflow Foundation. Ich rede über “Brot und Butter” Features des Hauptwerkzeuges jedes Programmierers: seine Programmiersprache. Man werfe mir also bitte nicht Gemeinheit vor, wenn ich darüber (schon wieder) den Kopf schüttele.

Eigentlich kann es mir ja sogar egal sein. Wenn ein Entwickler 5 Jahre oder mehr

“[…] Erkenntnisse  nicht in der Praxis einsetzen kann/darf hat man” und so “ irgendwann nur noch ein "Halbwissen"” hat,

dann ist es ja nicht mein Problem, wenn der Code schwerer als nötig lesbar ist oder er einen Job wie diesen nicht annehmen könnte:

Denn wenn dort schon TDD und Scrum im Titel stehen, dann wird man erwarten, dass der Bewerber sein Hauptwerkzeug selbstverständlich kennt. Denn TDD ohne Lambda-Funktionen ist kaum denkbar, wenn man moderne Mock-Frameworks einsetzen will.

Wer “irgendwann nur noch ein Halbwissen” hat und als Grund die mangelnde “Toleranz für Weiterbildung” beim Management anführt, der begibt sich in gefährliche Abhängigkeit. Denn wenn sich das Management in ähnlicher Weisheit wie in Bezug auf die Fortbildung entschließt, es einmal ohne den halbwissenden Entwickler zu probieren, dann wird der nächste Job kaum besser.

Gegen das Halbwissen hilft kein Händeringen und kein hoffender Blick zum Management. Halbwissen ist – das klingt hart, ist aber deshalb nicht minder wahr – im Wesentlichen selbstverschuldet. Heute noch mehr als gestern. Denn die Zeiten der verlässlichen Institutionen, die für uns die Lebensplanung übernehmen, ist vorbei. Unwiederbringlich. Verlässlichkeit und weise, gütige, wissende Lehrer, Beamte, Manager, Firmenpatriarchen oder was auch immer finden sich eher nur noch im Geschichtsbuch.

Die wahre Gemeinheit besteht also in den Kenntnislücken, die Entwicklern nicht nur das Entwickeln schwerer als nötig machen, sondern ihnen auch Freiheitsgrade bei der Gestaltung ihres Lebens nehmen.

Was dagegen tun? Am Ball bleiben. Braucht es dafür immer Freizeit? Nein. Einfach unter der Woche in der Arbeitszeit jeden Tag 30 Minuten hinsetzen und lesen. Oder etwas in Visual Studio ausprobieren. Wer soll denn da kommen und das verbieten? Der unverständige Manager? “Hey, was programmieren Sie denn da? Gehört das zum Feature X?” Und selbst wenn er es fragt, dann lautet die Antwort eben “Ja, das gehört dazu. Ich muss etwas ausprobieren.” Oder die Antwort auf einen Kommentar zum Lesen währen der Arbeit: “Ich muss etwas nachlesen, damit ich die Aufgabe besser erfülle.”

In welchem Land leben wir denn, wo nicht nur private Emails während der Arbeitszeit untersagt werden, sondern auch noch die Fortbildung? Wie viel Mikrokontrolle will denn Management ausüben?

Also, lieber Leser, es hilft nichts. Die Gemeinheit liegt nicht bei mir. Einen Missstand hervor zu heben, ist nicht gemein. Gemein ist der, der ihn herstellt – vor allem, wenn er womöglich weiß, dass er “das Personal dumm hält.”

16 Stunden in stickiger Luft und mit krummem Rücken müssen wir nicht mehr arbeiten. Gut so. Aber in einer der schnellsten Branchen zu arbeiten ohne Chance, sich durch kontinuierlichen Wissenserwerb unabhängig von einem Arbeitgeber zu halten, ist kaum besser. Das physische Leid ist vergangen. Präsent ist die aber anscheinend noch die existenzielle Abhängigkeit. Und das in einer Zeit, wo der, von dem man sich abhängig macht, überhaupt keine Garantie mehr geben kann, dass er für den Abhängigen auch angemessen sorgen kann.

Davon, dass der sinkende Wissenspegel (im Verhältnis zum Relevanten) nicht nur dem Entwickler, sondern sogar dem ignoranten Management schadet, mal ganz zu schweigen. Wo z.B. 19.000 Zeilen Code unwidersprochen in einer Klasse stehen können – ja, das habe ich neulich gesehen –, da kann mir niemand erzählen, dass irgendeinen Vorteile hätte. Das hat nur Nachteile, die viel, viel Geld kosten. Und das, weil der, der den Code geschrieben hat, mit “Halbwissen” zufrieden war. Das ist schlicht unprofessionell – und nicht nur auf Seiten des Entwicklers. Da hat das Management auch seine “Aufsichtspflicht” verletzt.

Und jetzt? Ran an den Ball. VS2010 und .NET 4 sind draußen. Auch ich muss mir das für mich Relevante jetzt drauf schaffen. Manchmal würde ich lieber mit dem Altbekannten weiter mokeln. Doch ich bin ja auch Teil der Branche und kann mich daher nicht vom Lernen ausnehmen. Wir sitzen alle im selben Boot.

Schaffe ich das mit dem Lernen übrigens komplett in dem, was ein Angestellter als seine Arbeitszeit ansehen würde? Nein. Aber es hilft nichts. Wenn ich gerade als Freiberufler weiter gefragt sein will, dann darf ich da nicht so genau sein. Zum Glück macht mir das Lernen allerdings Spaß. Ich fühle mich in dieser Branche gut aufgehoben.

PS: Bevor ich´s vergesse: Als Kritiker des allgemein nicht so rosigen Standes der Branche stehe ich nicht allein. Man lese mal hier bei SEMAT:

Software engineering is gravely hampered today by immature practices.

“Immature practices” – darum geht es. Das bezieht sich genauso auf das (oft abwesende) Vorgehensmodell wie auf die Abwesenheit von Fortbildungsplanung wie auf die Unkenntnis von zentralen Konzepten der Informatik (denn nichts anderes sind Iteratoren und Lambda-Funktionen), die präsent sind im Hauptwerkzeug eines Entwicklers.

Klage eines ungebackenen Entwicklers

Mehr Ausbildung zum Softwareentwickler in den Betrieben, das scheint mir ein wichtiger und gangbarer Weg für die Zukunft der Branche, die vom IT-Fachkräftemangel gebeutelt ist. So habe ich es in der dotnetpro 8/2009 in meiner Sandbox-Kolumne geschrieben. Daraufhin schreibt mir nun ein junger Fachinformatiker, wie sehr ich (für ihn) mit diesem Artikel und anderen zum Thema Ausbildung den Finger in die Wunde gelegt habe:

Hallo Herr Westphal,
mit großem Interesse habe ich Ihren Artikel "Entwickler selbst backen"
in der aktuelle dotnetpro gelesen.
Ich hoffe sehr das sich einige Firmen den Artikel zu Herzen nehmen und
auch den nicht Vollprofis eine Chance geben.
Ich selbst bin gelernter Fachinformatiker Fachrichtung
Anwendungsentwicklung und habe meine Ausbildung im Februar 
[des Jahres 2009] abgeschlossen. Die defizite der Ausbildung sind mir also bestens
bekannt, zum einen wurde bei uns in der Berufsschule
keinerlei Vorgehensweiße unterrichtet, weder Analyse noch Design
geschweigedenn irgendwelche Modelierungen mit UML.
Meine zweieinhalb Jahre Ausbildung habe ich in der Schule mit
Struktogrammen und dem Borland Builder 6 mit C++ verbracht, wo wir
es nach zwei Jahren tatsächlich geschafft haben eigene Klassen und
Methoden zu erstellen (Fehlerbehandlung, Debugging usw. waren alles
Fremdwörter).

Die Berufsschule hate nicht die Fachkräfte die nötig wären und auch
garnicht die Zeit, der überwiegende Teil wird in Systemintegration
ausgebildet und hat keinerlei Interesse an der Programmierung allgemein,
somit sind die Themen auch nicht gut zu vermitteln.
Somit bleibt noch der Betrieb, ich hatte das Pech das ich einem Betrieb
gelandet bin der nur eine EDV Abteilung besitzt und keine
Dienstleistungen in dem Bereich erbringt. Schulungen oder Einweisungen in richtige
Vorgehensweißen oder z.B. die Verwendung von Visual Studio gab es hier
nicht.

Wer sich nicht selbst weitergebildet hat blieb auf einem sehr niedrigen
Level. Ich bin sehr interessiert daran es richtig zu lernen, ich
arbeite sehr gerne mit ASP.NET und mit dem CompactFramework und möchte
ein möglichst hohes Level erreichen, leider scheitere ich an den Firmen
die scheinbar durchweg kein Interesse haben Ihre Mitarbeiter zu guten
Entwicklern auszubilden, und in Eigenarbeit mangelt es mir an Zeit und
manchmal auch an der Motivation (Die Firma dankt es mir eh nicht).

Deshalb habe ich auch kurz nach meinem Ausbildungsende die Firma
gewechselt, ich habe eine Firma gesucht die mir auch Weiterbildungen
anbietet, die verspricht das dass ausprobieren von neuen Technologien
Pflicht ist. Ich bin für diese Firma 200km umgezogen, und nehme weniger
Gehalt in Kauf. Leider musste ich feststellen das es hier keine
Weiterbildung gibt bzw. ich kann mir einmal im Monat mal eine Stunde zu
einem Thema, welches ich im übrigen in meiner täglichen Arbeit garnicht
einsetzen kann/darf, was anhören. Weitere Themen stehen dann wieder nur
Senior Software Developern zur Verfügung, welcher ich hier in dieser
Firma erst nach 5 Jahren sein werde. Das ausprobieren der neuen
Technologien findet hier garnicht statt, das Projekt läuft immernoch
auf dem 2.0 Framework und wie was umgesetzt wird, wird vorgegeben. Ich
habe mich im großen und ganzen selbst von Anwendungsentwickler zum
einfachen Programmierer heruntergestuft der den ganzen Tag irgendwelche
Support anfragen bearbeitet. Nun bin ich wieder auf der Suche nach
einer Firma die eventuell Interesse daran hat
sich selbst einen guten Mitarbeiter auszubilden. Ich bin nicht dumm und
eigentlich hochmotiviert ein "guter" .NET Entwickler zu werden, leider
muss ich wohl erst zwei bis fünf Jahre "Berufserfahrung" (meines
Erachtens ist das keine Berufserfahrung wenn ich Tag ein Tag aus
dasselbe mache ohne mich dabei weiterzubilden) sammlen bevor ich eine
Firma finde dem gerecht wird was ich suche.
Ich möchte Ihnen auf diesem Weg für diesen Artikel danken! Und ich hoffe
sehr das es auch in meiner Region Firmen gibt die diesen lesen und ihn
sich zu Herzen nehmen und vieleicht finde ich dann doch eine Firma bei
der mir meine Arbeit, die eigentlich auch mein Hobby ist, mir wieder
Spass macht. Ich hoffe das Konzept School of .NET wird in die Tat
umgesetzt, ich wäre sofort dabei das zu unterstützen!
[…]

Er würde so gern gebacken werden, aber niemand schiebt ihn wirklich in den Ofen. Die Firmen, bei denen die junge und zumindest motivierte Entwickler arbeitet, sehen ihn als fertig an, nur weil er eine Fachinformatiker-Ausbildung durchlaufen hat. Die aber ist, wie sich bei allem Verständnis für den Willen zu einer “plattformneutralen Ausbildung” zeigt, von nur zweifelhaftem Nutzen. State-of-the-art wird dort nicht vermittelt – was eher weniger an der Ausbildungssprache Borland C++ liegt.

Wie kann es sein, dass die Betriebe das nicht merken? 1. Es findet keine Qualitätskontrolle des in der Ausbildung Vermittelten bei seinem Lehrherren und auch später nicht statt. 2. Allemal als Auszubildender ist er wahrscheinlich so billig gewesen, dass niemand aufgefallen ist, dass er mit dem Ausbildungswissen nichts anstellen konnte. Seine Unproduktivität fiel nicht ins Gewicht. Denn unproduktiv muss er gewesen sein bei dem, was auf dem Lehrplan gestanden hat. Wieviel mehr hätte er schaffen können, wenn die Ausbildung zum einen der Plattform seines Lehrbetriebs entsprochen hätte und zweitens auf der höhe der Zeit stattgefunden hätte? Er hätte seinem Lehrbetrieb geradezu neue Impulse geben können. Nicht auszudenken wäre es doch, wenn ein Auszubildender aus dem Blockunterricht käme und z.B. sagte: “Wow, wir können viel korrekter arbeiten, wenn wir Unit Tests einsetzen.”

Stattdessen setzt man den motivierten Entwickler in eine Ecke und lässt ihn mokeln. Ich spekuliere mal, denn geschrieben hat er davon nichts: Seine Arbeit wurde nicht mit ihm nach Abgabe durchgesprochen. Nicht nur hat man ihm keine weitere Ausbildung/Fortbildung in den Betrieben zugestanden, auch fand sicherlich keine “Förderung im Kleinen” durch Kollegen statt. Es würde ja helfen, wenn sich jemand mit einem Junior-Programme in der Woche 2-3 Mal für ein Stündchen zusammensetzte, um seinen Code echt durchzugehen. Oder mal mit ihm Pair Programming machen. Davon jedoch keine Spur.

Betriebe nehmen klaglos, fraglos einfach an, was da aus der Ausbildung kommt. Und sie haben keinen eigenen Anspruch, wie es dann weitergeht. Außer einem Anspruch: irgendwie muss die Arbeit geschafft werden.

Was sie nicht sehen: vor 150 Jahren wurde die Arbeit auf den Feldern auch geschafft. Dafür war ein Heer von Landarbeitern zuständig. Doch heute schaffen wir es mit einem kleinen Bruchteil an Menschen, eine viel größere Zahl zu ernähren. Die Produktivität in der Landwirtschaft ist explodiert.

Dass das auch in der Softwareentwicklung mit etwas besserer Ausbildung, etwas besserer Kommunikation, etwas mehr Blick auf innere Qualität (Clean Code Developer lässt grüßen) und etwas besseren Prozessen auch der Fall sein könnte… das sehen viele nicht. Und das bedeutet, sie krebsen so dahin. Und das bedeutet, es wird für sie nicht besser, sondern eigentlich immer nur schlimmer. Darüber geht dann die Motivation der Leute verloren.

Der junge Entwickler hat zum Glück die Konsequenz gezogen und versucht, in eine bessere Firma zu kommen. Leider ist er nur vom Regen in die Traufe geraten. Doch er lässt nicht locker. Er will wieder einen Sprung wagen. Er glaubt noch, dass es Firmen mit mehr Interesse an ihren Entwicklern gibt. Ja, die gibt es. Ich wünsche ihm viel Erfolg bei der Suche!

Und den anderen Firmen wünsche ich einen Moment der Ruhe, des Abstands, um darüber nachzudenken, wie sie intern die Ausbildungs- und Arbeitssituation verbessern könnten. Es gilt ungehobene Produktivitätsschätze zu heben. Von höherer Motivation und Zufriedenheit mal ganz zu schweigen. Also, auf zum Entwicklerbacken!

Tagesschäft und Lernen vereint - School of .NET

Neulich haben Stefan Lieser und ich noch in unseren Blogs drüber diskutiert. Jetzt ist sie schon Realität: die School of .NET. Wir fanden das "gebrainstormte" Konzept so überzeugend, dass wir uns gleich hingesetzt und ein Curriculum ausgearbeitet haben.

Wer sich für berufsbegleitendes Lernen interessiert, wer nicht ein oder gar mehrmals 5 Tage am Stück aus dem Betrieb raus kann, um den Clean Code Developer "Kickstart" zu bekommen, wer schon lange sein .NET-Know-How festigen und ausbauen wollte, ohne das Projekt länger zu verlassen, dem eröffnet jetzt die School of .NET die Möglichkeit, das Angenehme mit dem Nützlichen zu verbinden. (Was hier angenehm und was nützlich ist, das Lernen oder das Tagesgeschäft, das überlasse ich jedem selbst zur Bewertung ;-)

Hier die Beschreibung des ersten "Semesters", dass Stefan und ich anbieten: die Ausbildung zum .NET-Entwickler für lokalen, synchronen und sequenziell entwickelten Code, den Synchronous Developer. Es findet simultan in Köln und Hamburg statt. Regionalität ist Trumpf!

Einsteigen, bitte - Level 1 der School of .NET

Stefan Lieser hat nun schon eine erste Skizze zu einem Curriculum für unsere School of .NET geliefert. Damit stimme ich überein:

Es geht um die Grundlagen der Objektorientierung (in C# oder auch VB): Erst wenn diese Grundlagen jenseits von "OOP hat mit Klassen zu tun" klar sind, ist zu erwarten, dass neuere Konzepte wie dynamische Programmiersprachen, funktionale Programmierung, Workflows, Aspektorientierung  in ihrer Andersartigkeit allen Vor/Nachteilen gewürdigt werden können.

Der einzelne Entwickler ist im Fokus, um auch in einer Umgebung, wo nicht alle Entwickler auf demselben Stand sind, schnellstmöglich Fortschritte am Arbeitsplatz erzielt werden können. Persönliche Grundfitness steht am Anfang, bevor es an echte Teamarbeit geht. Die CCD-Bausteine der ersten Graden - allen voran konsequentes automatisiertes Testen - geben hier den Takt an. Ziel ist - so könnte man sagen - eine Konditionierung im Hinblick auf Testautomatisierung: in der School of .NET wird es von der ersten Übung an keinen Code geben, der nicht mit einem Testrahmen ausgestattet ist.

Im Sinne eines Menschenbildes, das von schrittweiser Entwicklung des Bewusstseins zu immer höheren Ebenen ausgeht - nicht nur im Allgemeinen, sondern auch in Bezug auf Fachkompetenzen - steht am Anfang die Auseinandersetzung mit Code auf den kleinsten physischen Abstraktionsebenen: Methode, Klasse, Assembly und ansatzweise Komponente. Synchrone, 1- oder 2-Tier Software muss gemeistert werden, um fit zu sein für die nächste Stufe.

Hinzufügen möchte ich für Level 1 der School of .NET allerdings noch...

• Grundlagen des .NET Framework wie z.B. Streams, Exceptions, Instrumetierung, Linq, Extension Methods, Iteratoren, UserControls und mehr,
• Grundlagend des O/R Mappings, weil Datenbankzugriffe immer noch für viele Projekte ein Thema sind, das unnötig viel Aufwand macht

Damit haben wir, glaube ich, ein ordentliches Curriculum beieinander. Mancher mag sich dabei allerdings fragen, warum das eine oder andere Thema nicht darin auftaucht. Was ist mit WinForms oder ASP.NET MVC oder Silverlight? Was ist mit Security? Warum kein ADO.NET?

Die School of .NET hat nicht zum Ziel, Technologietraining zu sein. Über die technologischen Feinheiten von WinForms oder Security oder ADO.NET wird allerorten berichtet. Dazu kann man sich auch ein Spezialtraining suchen oder die Literatur studieren.

Mit dem Curriculum der School of .NET möchten wir uns vielmehr auf das konzentrieren, was zum einen bisher weniger Raum einnimmt in der Ausbildung oder was sich schlecht in Büchern vermitteln lässt. Das sind Grundlagen, Zusammenhänge, Konzepte und Prozesse. Beispiele:

• Bei Streams und Exceptions geht es uns nicht so sehr um die APIs des .NET Framework, sondern um die Konzepte. Ein streambasierter Umgang mit Daten ist etwas anderes als ein blockorientierter oder ein objektorientierter. Exceptions sind leicht zu werden und zu fangen; darüber müssen wir auch nicht reden. Aber wo einsetzen, welche Alternativen gibt es für die Meldung von (unvorhergesehenen) Zuständen: das ist konzeptionell interessant, das hat Auswirkungen auf den Anwendungsentwurf.
• WinForms und GDI+ Feinheiten sind nicht ohne. Aber darüber lässt sich allerorten lesen, das kann man leicht selbst ausprobieren. Der konzeptionelle Umgang mit UserControls jedoch, ihr Platz im Entwurf, das ist etwas anderes. Hier gibt es Nachholbedarf.
• Auch O/R Mapping ist für uns kein Technologie- sondern ein Konzeptthema. Die School of .NET wird kein Produkttraining durchführen. O/R Mapping soll vielmehr im Sinne von Patterns zu Bewusstsein gebracht werden.

Wer also spezielle Technologien trainieren will, der soll in ein Technologietraining gehen. Wer Hype hören will, der soll eine "Das ist alles neu in VS 20xx und .NET y.z"-Veranstaltung besuchen. Die School of .NET widmet sich - soweit es bei ihrem Plattformfokus geht - "Überzeitlichem". Mit dem Curriculum wenden wir uns an die, die einen Einstieg in die Plattform ernst meinen bzw. endlich ihre im Tagesgeschäft gewonnenen Erfahrungen auf soliden Untergrund stellen wollen.

Ein- und Umsteiger sind die primäre Zielgruppe für Level 1 der School of .NET. Für die Übergangsphasen zwischen Projekten und bei Aufnahme einer Tätigkeit ist das Level 1 gedacht. Berufsbegleitung bedeutet Entlastung des Betriebes bei der Ausbildung und Ergänzung anderer Ausbildungen im Sinne einer plattformspezifischen Konkretisierung und Vertiefung.

Und was kommt danach? Nach Level 1 kommt Level 2. Klar :-) Da geht es dann um:

• Fortgeschrittene Objektorientierung z.B. mit AOP und dynamischen Sprachen
• Echte Komponentenorientierung und Softwarearchitektur
• Asynchrone Programmierung - lokal und verteilt, also N-Tier Szenarien
• Die höheren Grade des CCD-Wertesystems mit Bausteinen wie automatisierter Produktion, iterativem Vorgehen oder statischer Codeanalyse

Level 2 richtet sich an den Entwickler im Team. Denn nur Teams können Software entwickeln, die intern auch als Team organisiert ist. Organisation und Produkt können nur co-evoluieren. Die Gestaltung von Level 2 ist insofern eine Konsequenz aus Conway´s Law. Asynchronizität und gar Verteilung können wir nur in den Blick nehmen, wenn wir uns auch organisatorisch mit autonomen Entitäten, den Entwicklern im Team auseinandersetzen. Aber dazu später mal mehr...

Jetzt werden wir erstmal School of .NET Level 1 in ein Angebot gießen. Soll die Innovation mal mit einem ersten Schritt beginnen...