• Teaser Home

    Clean Code Developer School

    Saubere Softwareentwicklung üben – regelmäßig, fokussiert, individuell, angeleitet

Was Führungskräfte lesen (2017)

Der Jahresanfang ist ein guter Moment für die Orientierung. In welcher Richtung liegt doch gleich Ihr Ziel? Was wollten Sie erreichen? Haben Sie sich überhaupt etwas vorgenommen?

Wenn Sie für 2017 Clean Code Development auf den Zettel schreiben, freuen wir uns natürlich besonders. Aber auch wenn nicht, wünschen wir viel Erfolg!

Und wir können sehr empfehlen: Nehmen Sie sich auch die Lektüre des einen oder anderen Buches vor. Lesen bildet, heißt es doch ;-) Allemal kann Lesen sehr kostengünstig einen Blick über den Tellerrand bieten. Da gibt es bestimmt einiges zu entdecken, das Sie anregt oder motiviert oder ins Grübeln bringt. Oder es verschafft Ihnen einfach nur Entspannung.

Wir haben deshalb mal einige Führungskräfte aus dem Bereich Softwareentwicklung gebeten, uns und Ihnen zu verraten, was sie denn gerade lesen oder welche Bücher sie im vergangenen Jahr beeindruckt haben.

Vielleicht ist da ja auch etwas für Sie dabei. Das würde uns freuen. Viel Spaß beim Stöbern.

Leseempfehlungen

Johannes Boppre, Entwicklungsleiter, Corporate Planning AG, Hamburg

Als Wahlpfälzer, Weinliebhaber und notorischer Anekdotenerzähler ein absolutes Muss für mich und zudem immer wieder unterhaltsam zu lesen. Absolute Leseempfehlung für alle Leute, die gerne mal einen Zeh in die verrückte Welt der Weinliebhaberei tauchen wollen.

Sehr unterhaltsames Buch über einen Mann, der sich mit den Supersportlern im Gedächtnistraining austauscht und dann selbst einer wird. Man lernt sehr viel über die Funktion und Möglichkeiten des eigenen Gehirns. Die Erkenntnis, warum uns mit zunehmendem Alter die Jahre subjektiv immer kürzer vorkommen und was wir selbst daran ändern können, war für mich sehr schön.

Super Unterhaltsame Bücher von Mark-Uwe Kling, humorvoll und sozialkritisch, ich habe selten während meinen Autofahrten so viel gelacht wie bei diesen Hörbüchern.



 

Uwe Henker, Bereichsleiter Softwareproduktion, medatixx GmbH & Co. KG, Bamberg

Das Buch lese ich noch. Bin gespannt und ängstlich. Ein Glück, dass ich schon in 17 Jahren in Rente gehe…

Das Buch habe ich wegen der Normalen gelesen. War interessant, aber meine Sicht auf die Normalen ist natürlich nicht besser geworden. Ich hoffe nur, dass ich nicht normal bin und es auch nicht werde.

Ich fand es super spannend, aber auch beängstigend.

Das kam natürlich nach dem Buch von Keese. War interessant aber auch erschreckend. Dann hatte ich Menschheit 2.0 begonnen, aber nur wenig gelesen. Habe jetzt aber wieder angefangen.


 

Guido Grogger, Chapterlead/Teamlead Java, Interhyp AG, Berlin

Wer noch glaubt, dass der Mensch ein Wesen ist, welches möglichst rationale Entscheidungen trifft und dabei ausschließlich die eigene Nutzenmaximierung anstrebt, dem sei das Buch von Verhaltensökonom Dan Ariely ans Herz gelegt. Mit Hilfe der Ergebnisse vieler Experimente aus der Verhaltensforschung stellt er den „Homo oeconomicus“ stark in Frage, welcher immer noch trotz aller Kritik eine tragende Rolle in der Wirtschaftstheorie spielt.

Eigentlich war das Aussortieren für mich die unangenehmste Aufgabe bei Aufräumen. Nach der Lektüre dieses Buches mache ich es nun mit Freude und Leichtigkeit. Marie Kondo hat eine Methode entworfen, bei der es darauf ankommt, beim Sortieren den Verstand auszuschalten und statt dessen auf das Glücksgefühl zu hören. Klingt vielleicht seltsam, funktioniert aber wunderbar.

Dieses Buch gibt mir in unserer krisen- und katastrophengeplagten Zeit Hoffnung auf eine bessere Zukunft. Ganz im agilen Sinn wird dafür kein Masterplan entworfen, der einfach in der richtigen Reihenfolge und zur richtigen Zeit umgesetzt werden müsste. Statt dessen werden Wege gezeigt, wie jeder Einzelne mehr Verantwortung für die Gesellschaft übernehmen kann. So können wir uns langsam aber sicher durch viele Ideen und Experimente an eine nachhaltige und lebenswerte Zukunft herantasten.


 

Frank Lindecke, Entwicklungsleiter, ma design GmbH & Co. KG, Kiel

Seit 2013 hat mich das Fieber der Fotografie gepackt. Bei den Bildern geht es für mich um Schönheit im Aufbau, den Orten, den Emotionen, die diese Bilder in mir erzeugen. Zum Lernen braucht es Imitation. Davon bin ich überzeugt.

Die Verbindung zur Software Entwicklung ist, dass ich mir öfter mal „fremden“ Code anschaue, um Inspiration zu bekommen. Den Stil des Entwicklers zu erleben und seine Ansätze zu „schmecken“.

Das ist ein sehr persönliches Buch und ich habe wirklich überlegt, ob ich es in diese Liste packe. Da es aber bei mir liegt, gehört es dazu.

Das besondere an diesem Buch für mich ist, dass es so viele Wirklichkeiten von Männlichkeit gibt und diese sich immer wieder wandelt. Wir können immer wieder etwas lernen für uns und manchmal braucht es dazu Tränen oder ein Lachen.

Verbindung zu Software? Weiß ich nicht. Außer vielleicht, dass es viele Wirklichkeiten geben kann, etwas zu meistern. Und sei es das Größte, unser Leben.

Das Buch hat mich schon immer interessiert und ich hab es mir im Herbst bestellt und in den Weihnachtsfeiertagen reingeschnuppert.

Ich kann es verstehen, wenn man „dem Kampf und Kriegsführung“ skeptisch gegenüber steht. Spannend fand ich das Kapitel 8 „Die neun Anpassungen“. Da wird von Folgendem geschrieben „Für einen General gibt es fünf Gefahren. Ist er todesmutig, kann er leicht getötet werden. Hängt er zu sehr am Leben, ist er leicht gefangen zu nehmen. „.

Es geht für mich dort eben gerade nicht um ein „Entweder-Oder“, sondern eher um ein „Sowohl, als auch“.

Meine Idee ist es, dies in Software Entwicklung zu übersetzen. Ich glaube, dass es auch dort viele Parallelen gibt, die wir dort beherzigen können und sei es einfach in dem Umgang mit uns selbst und unseren Kollegen und Kunden.


 

Alexander Schütz, Entwicklungsleiter, medatixx GmbH & Co. KG, Bamberg

Schluss mit defensiver Programmierung

Ein Muster von Trainingsteilnehmern, das ich häufig sehe, wenn wir die Resultate von Übungsaufgaben anschauen, ist das defensive Programmieren. Hier ein Beispiel:

Die Übungsaufgabe war die Function Kata fromRoman; es galt also, römische Zahlen in Dezimalzahlen zu konvertieren. Die zu schreibende Funktion lautete int fromRoman(string roman). In einer ersten Iteration sollten nur einziffrige römische Zahlen konvertiert werden, z.B. „X“ oder „D“.

Der Code, über den ich dann gestolpert bin, sah ungefähr so aus:

Zweierlei hat mich daran gestört, sogar sehr gestört.

  1. Es wurde vom Kontrakt abgewichen. Die vom „Kunden“ gewünschte Signatur sah int als Ergebnistyp für die Funktion vor, nicht int?. Ob das eine gute Entscheidung des „Kunden“ war, wäre zu diskutieren gewesen. Doch diese Diskussion fand nicht statt. Also war es die Aufgabe der Trainingsteilnehmer, die Funktion ohne nullable type umzusetzen.
  2. Im Code wurde eine Validation vorgenommen. Die Funktion prüft, ob überhaupt eine römische Zahl anliegt. Wenn nicht, reagiert sie ganz bewusst speziell. (Dass sie null zurückgibt, statt eine Exception auszulösen, ist eine Folge der Entscheidung für einen geänderten Ergebnistyp.)

Zu meiner Schande muss ich gestehen, dass ich in der Situation nicht ganz trainerprofessionell reagiert habe :-/ Ich war nicht ruhig, verständnisvoll, besonnen, sondern in meiner Verzweiflung etwas polterig. Leider. Sorry!

Vielleicht hat das ja nun aber auch etwas Gutes. Ich schäme mich und versuche auch auf diesem Weg eines Blogartikels, ein wenig Buße zu tun. Geschieht mir recht, nochmal Zeit zu investieren, um meinen Standpunkt klar zu machen. Jetzt in Ruhe.

Also, was hat mich denn so verzweifeln lassen? Meine Reaktion hatte ja nichts mit dem armen Teilnehmer zu tun, sondern nur mit mir selbst. In mir hatte sich etwas angestaut. Frust angesichts meiner Ohnmacht, dieses unselige Muster aus der Welt zu schaffen. Denn Stefan Lieser und ich sehen es wirklich in jeder Trainingsgruppe. Immer und immer und immer wieder fügen Entwickler dem Code, der unzweifelhaft geschrieben werden muss, weiteren hinzu. Die Begründung: „Das habe ich so gelernt. Das ist defensive programming.“

Was soll ich sagen…? Das macht mich sprachlos. Vielleicht ist es die Tragik, die dieses Gefühl noch verstärkt. Denn Entwickler wollen ja das Gute, sie bemühen sich um Qualität – und erreichen das Gegenteil. Sie optimieren lokal und temporär – indem sie im Moment des Codierens eine Qualitätssicherungsmaßnahme ergreifen –, doch verfehlen sie dadurch ein globales, langfristiges Qualitätsoptimum. Defensive Programmierung ist keine Clean Code Entwicklung!

Ok, was habe ich denn für ein Problem? Warum hat mich der obige Code lospoltern lassen? Weil defensives Programmieren das Geld des Kunden verschwendet.


GFU Clean Code Powerdays

In diesem Beispiel ist das ganz deutlich: Der „Kunde“ hat sich nicht gewünscht, dass eine Validation stattfindet. Das ist erstens an der beauftragten Funktionssignatur abzulesen; die enthält keinen nullable type. Das ist zweitens an der Liste der Testfälle abzulesen, die für die Funktion definiert waren. Es gab keinen Test, der die Übergabe von null oder leerer Zeichenkette (oder überhaupt irgendeiner ungültigen römischen Zahl) durchgespielt hätte. Das ganze Thema „ungültige Eingaben“ war sogar aus-drück-lich ausgeklammert.

Dennoch sehen sich Entwickler immer wieder bemüßigt, Zusatzaufwand zu treiben, um solche Fälle abzudecken. Sie ignorieren Anforderungen oder sie imaginieren sie. Ich weiß nicht.

Was ist der Antrieb dahinter? Geht es wirklich darum, dem Kunden mehr Qualität zu liefern? Ich glaube nicht. Eher vermute ich den-eigenen-Arsch-absichern als Beweggrund. „Soll keiner sagen, meine Funktion hätte aufgrund falscher Eingaben Müll produziert!“ oder so mag der Gedanke sein. Nicht Altruismus, sondern Egoismus treibt Entwickler, das Geld des Kunden in defensives Programmieren zu versenken. Sie selbst wollen sich Ärger in der Zukunft ersparen.

Das finde ich verständlich; sie haben bestimmt einige Negativerfahrungen gemacht, die sie zukünftig vermeiden wollen. Doch das Mittel ist aus meiner Sicht gänzlich falsch gewählt.

Noch schlimmer wird das bei defensiver Programmierung wie dieser:

Ja, das hat tatsächlich jemand empfohlen. Sehen Sie das Problem? Gruselig, oder? Was, wenn der Button tatsächlich null ist? Dann crasht das Programm nicht. Aber es funktioniert auch nicht. Vielmehr passiert stillschweigend nichts. Und das ist ganz bestimmt sehr, sehr überraschend für den Benutzer. Daraus kann nur ein hässlicher Supportfall werden. Wer führt über diese Kosten Buch? Der Entwickler ist fein raus: kein Crash. Doch der Rest der Organisation hat Schweiß auf der Stirn. Die Uhr tickt.

Das ist großer Mist.

Mehr Vertrauen!

Defensive Programmierung ist vielleicht ein Mittel in einer Welt von Einzelkämpfern, die niemandem vertrauen können. Es ist eine letzte Zuflucht in einer feindlichen Umgebung.

Doch das kann doch nicht die Vorstellung von einem produktiven Arbeitsplatz sein. Die Zusammenfassung von Menschen in einem Team, ihre Anstellung in einem Unternehmen soll ja gerade Kosten durch Misstrauen vermeiden. Unternehmen, Teams, Projekte definieren Horizonte des Vertrauens. Das dient der Reduktion von Komplexität.

Menschen, die sie in einer Kneipe treffen, untersuchen Sie auch nicht erst auf Waffen. Wechselgeld im Supermarkt prüfen Sie auch nicht erst auf Falschgeld. Zwischen vielen Ländern in Europa sind sogar die Grenzkontrollen abgeschafft. Sie können nach Dänemark oder in die Schweiz fahren, ohne eine Prüfung Ihrer Identität.

Solches Vertrauen macht das Leben einfacher. Wenn Sie einen Eindruck davon bekommen wollen, wie es zugeht, sobald wir dieses Vertrauen nicht mehr haben, lesen Sie z.B. dies. Eine schreckliche Welt!

Also: Die Bequemlichkeit und Effizienz der Welt, die wir schätzen, hängt von der Reichweite unseres Vertrauens ab.

Das ist uns im täglichen Leben bewusst, deshalb sind wir bereit, dafür etwas zu tun. Als Gesellschaft geben wir einiges Geld aus für Organe, die solche Verhältnisse erhalten. Polizei, Gerichte, Gesundheitsamt, TÜV sind nur einige.

Nur die Softwareentwicklung scheint das noch nicht begriffen zu haben. Denn nach Aussage des Teilnehmers, der für mich der Anlass zum Poltern war (Sorry, again!), hat er die defensive Programmierung in der Ausbildung beigebracht bekommen. Das Misstrauen ist also Lehrmeinung. Der Wilde Westen lebt noch in den Köpfen der Lehrer. Kein Entwickler ist sicher vor einem anderen, deshalb müssen alle fleißig proaktive Verteidigungsmaßnahmen ergreifen?

Wie nun aber richtig?

  1. Der Kunde bestimmt, was Anforderung ist.
  2. Vertrauensgrenzen sind explizit zu ziehen.

Vertrauensgrenze Benutzerschnittstelle

Der vornehmste Grund, um ein Validation von Input vorzunehmen ist der Wunsch des Kunden. Das bedeutet, als Entwickler müssen wir mit dem Kunden reden. Horribile dictu! Ja, reden. Wir müssen mit ihm über Schnittstellen reden. Nur an denen ist er ja interessiert. An Schnittstellen zeigt sich für ihn das Verhalten der Software, die er beauftragt.

Die offensichtlichste Schnittstelle ist die Benutzerschnittstelle: Menschen geben Daten ein, die Software antwortet mit Daten. Aber auch Service-Schnittstellen gehören dazu. Die werden von anderer Software genutzt, drehen sich jedoch auch nur um Input-Daten (request) die in Output-Daten (response) transformiert werden sollen.

Mit dem Kunden ist abzusprechen, welcher Input zu welchem Output führen soll. Der Kunde ist in diesem Fall wirklich mal König. Der zahlt, der sagt an. Das war im obigen Beispiel eindeutig der Fall.

Das bedeutet: Was er nicht ansagt, dafür will er im Zweifelsfall nicht zahlen oder noch nicht zahlen. Wenn Entwickler trotzdem Code schreiben für Verhalten, das der Kunde nicht gewünscht hat, dann verschwenden sie sein Geld. Massiv. Trotz allerbester Absichten. Sie handeln im besten Fall paternalistisch, im schlechteren arrogant.

Die korrekte Verhaltensweise für Entwickler ist: Wenn Sie eine mögliches Validitätsproblem sehen, dann melden sie das dem Kunden. Es gilt das ehrwürdige militärische Prinzip: Melden macht frei.

Ich kritisiere also nicht den Gedanken „Hier könnte aber etwas falsch laufen, wenn null übergeben würde.“ Im Gegenteil: Das ist sensibel beobachtet! Sehr gut!

Nur aus dem guten Gedanken ist dann im Training keine gute Maßnahme geflossen. Die wäre gewesen, mich als „Kunde“ darauf anzusprechen. Dann hätte ich wiederholen können, dass ich (derzeit) keine Behandlung invalider Daten wünsche oder hätte mich überzeugen lassen, dass das eine gute Idee ist. In dem Fall hätten wir zumindest ein Beispiel für unter diesen Umständen von mir erwünschtes Verhalten notiert und ggf. den syntaktischen Kontrakt angepasst.

Der typische Einwand gegen dieses Vorgehen: „Ich kann den Kunden doch nicht mit all solchen Kleinigkeiten belasten. Der erwartet, dass ich sowas selbstständig mache.“

Da ist etwas dran. Der Kunde hat tatsächlich eine Erwartung an unsere Kompetenz als Entwickler. Doch die ist nicht, dass wir alle Sicherheitsmaßnahme selbstständig ergreifen. Das gäbe es nämlich kein Halten mehr. Sicherheit ist unersättlich. Ohne Kontrolle stürzen wir in ein Sicherheitskaninchenloch.

Die Erwartung des Kunden ist vielmehr – zumindest, wenn er kostenbewusst ist -, dass wir ihn informieren. Mit unserer Kompetenz sollen wir ihn auf mögliche Probleme aufmerksam machen. Dann kann er entscheiden, wie zu verfahren ist. Nur so sichern wir uns auch wirklich ab gegen spätere Kritik des Kunden.

Kunden haben Prioritäten. Da mag eine Input-Behandlung mit Lücken dringender sein als eine ohne. Denn mit Lücken ist ein Durchstich schneller hergestellt. Entscheidet ein Entwickler selbstständig, lückenlos zu programmieren, sinkt die Geschwindigkeit in Bezug auf das, was dem Kunden am Herzen liegt.

Der Aufwand für defensive Programmierung ist ja nicht zu unterschätzen. Das ist Logik. Die muss zuerst hingeschrieben werden, dann muss sie getestet werden. Das sind pro Funktion 2-3 Minuten. Bei 10 Funktionen sind es schon 30 Minuten. Wenn das 3 Entwickler pro Tag tun, sind es 90 Minuten. Schnell werden also Hunderte Euro durch defensive Programmierung verbrannt, die kein Kunde gewünscht hat.

Kleine Übung: Wer defensiv programmiert, tut einfach 5€ pro Maßnahme in die Teamkasse. Wie wäre das? :-)

Dazu kommt der Aufwand beim Lesen. Vielleicht ist der defensive Code noch schnell hingeschrieben. Doch er wird ja viel, viel häufiger gelesen als geschrieben. Jedes Mal ist er dann zu verstehen. Das kostet einen kleinen Aufwand. Defensiver Code verrauscht den eigentlichen Code. Er ist dessen Verständlichkeit abträglich. Die Wandelbarkeit von Software sinkt also durch defensiven Code, der ohne Auftrag geschrieben wird. Mittelfristig schießt sich der Entwickler, der ihn schreibt, damit sogar in den eigenen Fuß.

Vertrauensgrenze Modulschnittstelle

Absicherungscode, der einer expliziten Kundenanforderungen folgt, ist nun eigentlich gar kein defensiver Code mehr. Er ist ausdrücklich gewünscht. Es findet keine ängstliche Selbstverteidigung mehr statt.

Echt defensiver Code ist demgegenüber nie vom Kunden ausdrücklich gewünscht. Er erfüllt keine funktionale Anforderung und auch keine nicht-funktionale Effizienzanforderung. Vielmehr ist er zur Herstellung der Investitionssicherheit gedacht und fällt damit in einen Bereich, den der Kunde eher nicht im Blick hat. Defensive Programmierung ist eine verzweifelte Maßnahme Einzelner, um noch etwas Korrektheit und Produktivität zu retten. Ach, wie tragisch…

Doch woher kommt diese Verzweiflung? Woher das Misstrauen? Es ist ein Resultat mangelnder Kommunikation. Denn da, wo nicht kommuniziert wird, da bleiben und entstehen weiße Flecken. Man weiß nicht, was der andere denkt und tut. Unsicherheit greift Raum, dann Misstrauen – allemal wenn es zu negativen Erfahrungen kommt -, schließlich unternimmt man persönliche Absicherung.

Das, was sich auf gesellschaftlicher Ebene abspielt, spiegelt sich im Kleinen in Teams, in denen nicht ausreichend kommuniziert wird.

In Dresden und anderswo mag es helfen, zu versuchen, Misstrauen durch mehr Gespräche in Kaffeeküchen zu überwinde. Integration beginnt mit einem freundlichen Wort und einem offenen Ohr.

Für Softwareteams reicht das jedoch nicht aus. Sie bedürfen systematischerer Kommunikation.

Test-first

Die erste Maßnahme in dieser Hinsicht ist test-first Codierung. Tests sind die zentrale Dokumentation für gewünschtes Verhalten. Wer nachschauen will, wie Software benutzt werden soll, der studiert automatisierte Testfälle. Sie stellen eine lebendige Dokumentation des Soll-Zustands dar. Damit dienen sie nicht nur der Absicherung gegen Regressionen, sondern auch der Kommunikation im Team. Niemand soll sagen können, er hätte nicht gewusst, wie korrekte Parameter für eine Funktion aussehen.

Und wenn die vorhandenen Tests eine Frage zum Softwareverhalten nicht beantworten… dann schreibt man einen weiteren Test, der exploriert, wie sich Software de facto bisher verhält. Vielleicht ist das schon ausreichend, vielleicht regt das aber auch weitere Kommunikation an.

Nicht nur automatisierte Tests sind jedoch wichtig, sondern sogar sie zuerst zu schreiben, also vor dem Produktionscode. Erstens werden sie dann nicht so leicht vergessen, zweitens bietet ihre Codierung Gelegenheit, sich aus Sicht eines Softwarenutzers Gedanken darüber zu machen, was denn eigentlich passieren soll. Man lügt sich weniger in die Tasche durch schon vorhandene Kenntnis „der Innereien“. Weniger Bestätigungsfehler.

Entwurf

Und woher kommen die Schnittstellen, auf die automatisierte Tests angesetzt werden? Sie sind das Ergebnis eines expliziten Entwurfs. Womit ich beim großen Sorgenkind der Softwareentwicklung bin.

Im Fehlen eines expliziten Entwurfs, der diesen Namen verdient, sehe ich den Hauptgrund für die Praxis der defensiven Programmierung. Es wird nicht gelehrt, wie explizit und systematisch vor der Codierung entworfen werden kann. Damit entsteht in der Kommunikation im Team eine eklatante Lücke. Einzelne Entwickler werden zu schnell sich selbst überlassen. Das treibt sie in die Unsicherheit. Dann wollen sie ihren Arsch absichern.

Ein systematischer Entwurf von Software durch das Team bestimmt die wesentlichen Module zur Realisierung anstehender nicht-funktionaler Anforderungen. Sein Ergebnis sind Funktionen, Klassen, Komponenten, Services mit klaren Schnittstellen und Beziehungen.

Weniger geht gar nicht.

Und dann werden in dieser Struktur ausdrückliche Vertrauensgrenzen gezogen. Das Team definiert gemeinsam, zwischen welchen Modulen Misstrauen herrschen soll. Denn Misstrauen hat auch etwas Gutes: es entkoppelt.

Dadurch entsteht eine interne Anforderung zur Herstellung von Wandelbarkeit. Die ist zu erfüllen mit Code, der über die Verhaltensanforderungen des Kunden hinausgeht. Das ist völlig ok, ja sogar notwendig. Das erwartet der Kunde zurecht vom Team.

Doch Achtung: Es ist eine Teamentscheidung, wo diese Grenzen verlaufen. Einzelne Entwickler kompensieren hier wieder nicht ihre persönliche Unsicherheit. Deshalb würde ich auch in diesem Fall nicht von defensiver Programmierung sprechen.

Selbstverständlich hält das Team solche Entscheidungen fest: in Form von syntaktischen und semantischen Kontrakten. Nichts anderes sind Funktionssignaturen bzw. Interfaces und Tests.

Interne Vertrauensgrenzen manifestieren sich damit geplant im Code. Sie sind keine ad hoc Entscheidungen. Einzelne Entwickler sind bei der Codierung von Logik in Funktionen nur für deren Korrektheit zuständig. Ihre Aufgabe ist es in dem Moment nicht, darüber zu spekulieren, wie irgendwer diese Funktion benutzen könnte.

Nutzungsspekulationen sind Sache des Entwurfs und damit des Teams.

Fazit

Schluss mit defensiver Programmierung! Sie ist ein Relikt aus Zeiten, da man noch glaubte, man müsse als Softwareentwickler nicht reden. Doch kein Softwareentwickler ist eine Insel.

Softwareentwicklung ist ein „Teamsport“. Der funktioniert nur, wenn man sich vertraut. Dazu gehört gekonnte Kommunikation und geeignete Dokumentation von Entscheidungen.

Wo defensive Programmierung noch an der Tagesordnung ist, da fehlt es an diesen Kompetenzen. Das Resultat: geringe Produktivität, Verschwendung von Kundengeldern. Traurig, traurig.

Doch zum Glück gilt: Gefahr erkannt, Gefahr gebannt. Es ist nie zu spät, mit besserer Kommunikation zu beginnen und untaugliche Gewohnheiten abzulegen. Now is the time!

Entwurf und test-first Entwicklung lassen sich lernen. Es winkt Entspannung durch mehr Vertrauen.

Software in Gerüsten bauen

Softwareentwickler machen keinen Dreck. Softwareentwickler tun auch nichts Überflüssiges. So scheint mir jedenfalls der Anspruch.

Die Realität sieht am Ende natürlich ganz anders aus: der Dreck ist im Code überall, es stinkt mächtig (code smells). Und vom Überflüssigen ganz zu schweigen. Wenn premature optimization laut Donald Knuth „the root of all evil“ ist, dann findet sich Überflüssiges allerorten im Code.

Natürlicher Müll

Woher kommt dieser Anspruch aber? Andere Berufe haben kein Problem, Dreck zu machen und Überflüssiges in Form von (temporären) Hilfskonstruktionen herzustellen. Das tun sie ganz bewusst. Es ist geradezu sprichwörtlich: „Wo gehobelt wird, da fallen Späne.“ Genau! Das ist auch nicht schlimm, wenn man am Ende der Arbeit die Späne zusammenfegt und entsorgt.

Überall entsteht Abfall in irgendeiner Form während Dinge hergestellt wird. Der ist eigentlich überflüssig, lässt sich jedoch trotz fleißigen Bemühens nicht komplett vermeiden. Späne, Bauschutt, Nahrungsmittelabfälle, Abwasser… Die Transformationseffizienz ist eben nicht 100%. Input kann nicht perfekt in Output überführt werden.

Doch wo ist solch bewusst in Kauf genommener Dreck, Abfall, Müll bei der Softwareentwicklung? Ich sehe ihn nicht. Es entsteht zwar Dreck, nur unbewusst. Er wird nicht als solcher wahrgenommen. Das halte ich für ein Problem. Nur TDD hat dafür ein Auge: im dritten Schritt nach Red und Green soll mit Refactoring aufgeräumt werden. Leider wird selbst das aber nur selten getan.

Softwareentwickler durchlaufen keine Lehre, in der ein fester Bestandteil das Aufräumen ist. Tischlerlehrlinge, Kochlehrlinge, Schlosserlehrlinge hingegen lernen alle die (Wieder)Herstellung von Ordnung am Ende von Arbeitsphasen. Dreck wird zusammengekehrt, Werkzeug wird in Schubladen und Regale weggeräumt. In einer Küche ist das sogar extrem. Da wird nicht bis zum Tagesende gewartet, sondern ständig gewischt und gespült. Während die eine Hand mit dem Kochlöffel rührt, putzt die andere schon entstandene Spritzer weg. Das ist ein simples Gebot der Hygiene, wenn schon nicht der Produktivität.

Ich finde das ganz natürlich. Sogar würde ich sagen, Abfall bewusst und kontrolliert entstehen zu lassen, ist eine Sache der Effizienz. Denn wenn ich in jeder Sekunde sauber sein muss, wenn ich nie Dreck erzeugen darf… dann werde ich langsam, weil ich ja ständig nicht nur meine eigentliche Aufgabe verfolgen muss, sondern auch auf permanente Sauberkeit zu achten habe.

Sauberkeit und Ordnung sind wichtig – aber nicht in jeder Sekunde. Phasen, in denen Späne fallen, und Phasen, in denen die Späne zusammengefegt werden, dürfen, ja sollten sich sogar abwechseln. Solche Natürlichkeit ist allerdings aus meiner Sicht weder im Bewusstsein der meisten Entwickler noch in dem ihrer Vorgesetzten gewachsen.

Hilfreiche Konstruktionen

Dasselbe gilt für Hilfskonstruktionen. Die werden auch als überflüssig angesehen. Warum nur? Weil sie von vornherein als Abfall erscheinen und daher vermieden werden müssen? Dabei arbeitet der Rest der Welt damit ständig: Häuser werden eingerüstet, Schiffe auch, Autos kommen auf Hebebühnen, Schiffe auch, es gibt Kräne, es gibt Schuttrohe am Bau usw. usf.

Diese Hilfskonstruktionen sind dazu da, die Arbeit am Werkstück zu erleichtern. Und am Ende werden sie abgebaut. Das Haus steht wieder frei, das Auto auf der Straße, das Schiff liegt im Wasser. Nichts mehr zu sehen von den so nützlichen Hilfskonstruktionen. Man war sich nicht zu fein, zusätzlichen Aufwand für deren Auf- und Abbau zu treiben. Denn dadurch konnte die eigentliche Arbeit viel effizienter gestaltet werden. Unterm Strich also ein Gewinn.

Nur die Softwareentwicklung kennt das nicht. Dort gibt es keine Hilfskonstruktionen, die bewusst temporär aufgebaut und nach der eigentlichen Arbeit wieder abgebaut werden. Selbst bei TDD, wo ja sogar Abfallbeseitigung „eingebaut“ ist, sind Hilfskonstruktionen unbekannt. Alle Tests sollen erhalten bleiben. Aber warum? Gibt es denn keine Unterschiede bei Tests? Ich sehe sehr wohl Tests, die eigentlich nur temporär nützlich sind. Die nenne ich Gerüsttests – denn ich baue sie nach getaner Arbeit wieder ab. Der Gewinn: der Code wird übersichtlicher, die Angriffsfläche für Regressionen wird verringert.

Dabei gibt es das Konzept des Prototyps in der Softwareentwicklung. Nur wird der regelmäßig entgegen der Begriffsdefinition nicht weggeschmissen, sondern zum Produkt umgebaut.

XP kennt spike solutions. Auch das Code, der am Ende weggeworfen wird. Nur wer „spiket“ denn bewusst? Das scheint mir selten trotz immer wieder hoher Unsicherheiten im Verständnis von Anforderungen oder beim Einsatz von Technologien.

Seit Jahren gibt es auch das Konzept Kata, also Übungsaufgabe. Entwickler treffen sich gelegentlich, um gemeinsam an Katas etwas zu lernen. Doch das sind Einzelne, vielleicht höchstens 5% aller Entwickler. Denn eines ist ja klar: der Code zu einer Übungsaufgabe ist am Ende Abfall. Der kann weg, ist nicht im Tagesgeschäft einsetzbar. Also denken sich 95% der Entwickler, dass es wohl nicht lohne, ihn überhaupt zu schreiben. Der ist überflüssig.

Ab auf die Werkbank!

Vielleicht ist ja ein Grund für die „Abfallaversion“, dass die Softwareentwicklung auch keinen Unterschied machen zwischen dem Ort, wo ein Teil bearbeitet wird, und dem, wo das Teil in einem Ganzen eingebaut ist. Softwareentwicklung findet immer am endgültigen Marmorblock statt. Alles wird aus einem Stück herausgemeißelt. Kein Wunder, dass der Softwaremonolith allgegenwärtig ist.

Das mag ja gut gehen, wenn man Michelangelo heißt und wahrhaft meisterlich mit Marmor umgehen kann. Doch normale Entwickler sollten sich doch eigentlich nicht an so einer Aufgabe probieren. Viel einfacher ist es, ein Ganzes aus Teilen zusammenzusetzen, die man einzeln auf Werkbänken bearbeitet. Doch das geschieht nicht. Code, der zum Einsatz beim Kunden kommt, ist immer eingebaut im Ganzen. Man kann vielleicht auf ihn von außen mit Tests zugreifen, es gibt also Revisionsklappen. Doch das ist ein Zugeständnis an das Paradigma „aus einem Stück hauen“.

Bei TDD as if you meant it wird dieses Paradigma aufgebrochen – doch wer kennt diesen TDD-Ansatz?

***

Abfall, Hilfskonstruktionen, Werkbänke… das alles sind keine Themen in der Softwareentwicklung. Mir scheint das ein Problem zu sein. Der schlechte Stand der inneren Codequalität ist für mich umso weniger ein Wunder. Wenn wir uns die Freiheit nicht nehmen, etwas „Verschwendung“ zuzulassen, um dafür auf der anderen Seite fokussierter und effizienter zu arbeiten, dann machen wir noch keinen guten Job als Software Craftsmen oder Software Engineers.

Frühjahrsputz 2016 – Gemeinsam ran an den Schmutz

Der Frühjahrsputz für Wohnung und Körper (Fasten) ist Tradition. Warum nicht diese schöne Tradition auch auf Ihre Codebasis ausdehnen? Dort gibt es sicher auch einige Ecken, die mal entrümpelt werden könnten, oder?

Wenn Sie jetzt denken „Ja, müsste ich mal machen…“, sich aber nicht aufraffen können, dann verstehen wir das allerdings sehr gut. Aufräumen macht irgendwie keine Freude. Oder wenn doch, dann fällt es Ihnen trotzdem wahrscheinlich schwer, dafür einen Termin im Tagesgeschäft zu finden.

Deshalb bieten wir Ihnen an: Wir helfen Ihnen beim Frühjahrsputz!

Gehen Sie Staub, Schmutz, Gerümpel in Ihrem Code nicht allein an. Lassen Sie uns das zusammen machen: „Pair Putzen“ :-) Gemeinsam macht es mehr Freude; zu zweit sieht man auch mehr Schmutzstellen und ein Termin mit jemand anderem wird leichter eingehalten.

Die CCD School Putzhilfeaktion

Ja, Sie haben richtig gelesen: Wir würden Ihnen gern beim Säubern Ihres Codes zur Hand gehen. Sauberer Code, also Clean Code, ist immerhin unser Job ;-)

Und weil die Sonne so schön lacht, die Vöglein so munter zwitschern und die Kirsche schon so hübsch blüht, haben wir uns ein Angebot überlegt, dem kein Schmutz widerstehen kann. Wie bieten…

  • 6 Teams
  • jeweils 3 Termine
  • à 90 Minuten

unsere Hilfe an – und das lediglich zum Preis eines Amazon-Gutscheins, dessen höhe sie selbst am Ende der Putzaktion bestimmen.

So funktioniert’s:

Bewerben Sie sich mit Ihrem Team über das unten stehende Formular, wenn Ihre Codebasis in Java oder C# entwickelt ist. Aus allen Bewerbungen wählen wir 6 aus, denen wir beim Frühjahrsputz jeweils insgesamt 4,5 Stunden beistehen. Diese Zeit verteilen wir allerdings auf 3 online Sitzungen à 90 Minuten. In den Sitzungen arbeiten wir im remote pair via Teamviewer und anderen Werkzeugen zusammen an der realen Codebasis.

Die Sitzungen liegen 1-2 Wochen auseinander, so dass die ausgewählten Teams zwischendurch Zeit haben, mit den Impulsen aus dem „Pair Putzen“ selbstständig weitere Erfahrungen zu sammeln.

Um Ihnen die Bewerbung leicht zu machen, verzichten wir in diesem schönen Frühling auf ein Honorar. Wenn ein Team unsere Unterstützung jedoch als wertvoll empfunden hat, dann freuen wir uns über eine Anerkennung in Form eines Amazon-Gutscheins. Dessen Höhe bestimmt das Team selbst nach Budget und Wertempfinden.

Unsere Motivation

In Zeiten so vieler scheinbar kostenloser Angebote mögen Sie sich fragen, warum wir Ihnen dieses Angebot machen. Der Grund ist einfach: Wir wollen mehr Erfahrung beim Säubern von realem schmutzigem Code machen. In unseren Trainings konzentrieren wir uns bisher auf Clean Code, wollen also Schmutz von vornherein vermeiden. Und Beratungseinsätze bringen uns zwar ans Brownfield, an den Legacy Code, in den Big Ball of Mud – doch da solche Begleitungen länger dauern, gibt es davon nicht so viele verschiedene.

Um in der Vermittlung von Clean Code Prinzipien und Praktiken noch besser zu werden, glauben wir, müssen wir jedoch mehr, viel mehr unsauberen Code sehen. Diese Putzaktion ist ein Versuch, dieses Ziel zu erreichen.

Wir helfen Ihnen beim Reinemachen, Sie helfen uns mit Zugang zu realem Legacy Code. So einfach ist der Deal.

Los geht’s

Wenn Sie Lust auf unsere Unterstützung beim Code-Frühjahrsputz haben, dann füllen Sie das folgende Formular aus. Bewerbungen sind bis zum 20.4.2016 möglich. Selbstverständlich behandeln wir alle Bewerbungen vertraulich und begraben Sie anschließend nicht unter Spam-Emails ;-)

Lernstoff in den Alltag überführen

Wie schaffen Sie es eigentlich, Clean Code Development Praktiken (und damit auch Prinzipien) in Ihren Alltag zu einzubauen? Diese Frage tauchte anlässlich einer Vorstellungsrunde in einem TDD 2.0 Training auf. Ein Teilnehmer sprach nämlich ausdrücklich davon, das sei sein Vorsatz.

Über solchen Vorsatz habe ich mich natürlich sehr gefreut. Doch auf die Frage, wie hoch die Wahrscheinlichkeit sei, dass der Vorsatz auch in die Tat umgesetzt würde angesichts all der Umsetzungs(miss)erfolge mit früheren Vorsätzen… da kam dann leider nur eine Wahrscheinlichkeit von weniger als 50% heraus.

Das wäre aber doch schade, oder? Allemal angesichts der Anfangsinvestition an Zeit und Geld in das Training. Ganz zu schweigen von den nicht realisierten Vorteilen, wenn die Entwicklung anschließend nicht sauberer testgetrieben verläuft.

Aber das ist sicher nicht nur ein Problem dieses Teilnehmers. Im Grunde kämpfen ja alle damit, Lernstoff nach Ende des Trainings im Alltag lebendig zu halten oder gar zu vertiefen und anzuwenden. Wie kann das funktionieren?

Ich denke, es ist für unsere Motivation und unser Selbstvertrauen wichtig, in der Lage zu sein, solch einen Vorsatz verlässlich in die Tat umzusetzen. Er stellt ja ein Versprechen dar, das wir uns (oder gar dem Unternehmen, das ein Training bezahlt) geben. Und versprechen soll(t)en eingehalten werden. Das erhält und schafft Vertrauen mit all seinen guten Effekten.

Deshalb hier zwei Tipps, um es Ihnen leichter zu machen, den Vorsatz umzusetzen, Lernstoff in den Alltag zu überführen.

Nach dem Behavior Grid von BJ Fogg, einem Experten in Sachen Verhaltensveränderung, geht es um ein Green Path Verhalten, d.h. ein neues Verhalten, das Sie von nun an auf unbestimmte Zeit annehmen wollen. Er schreibt dazu:

Green Path Behaviors are the result of three elements: Motivation, Ability, and Triggers. As the Fogg Behavior Model describes, you must Trigger the behavior when the person is both Motivated and Able to perform it. The specific steps: 1. Boost motivation (if needed), 2. Enhance ability by making the commitment act simple, 3. Issue the trigger when #1 and #2 are in optimal states.

BJ Fogg Behavior Grid

Nicht zu viel vornehmen

An Motivation wird es Ihnen nicht fehlen. Sie haben sich ja gerade freiwillig mit einem spannenden Lernstoff auseinandergesetzt und suchen nach einem Weg, Ihre hohe Motivation möglichst verlustfrei in eine bleibende Veränderung zu transformieren.

Deshalb ist die erste Frage nach BJ Fogg, wie Sie Ihre „ability“ erhöhen, eine neue Verhaltensweise an den Tag zu legen. Beispiel: Im TDD 2.0 Training haben Sie die Methoden „TDD as if you meant it“ und „Informed TDD“ kennengelernt – und dennoch fehlt Ihnen noch etwas. Das ist die Fähigkeit (ability), das Gelernte jeden Tag einzusetzen.

BJ Fogg schreibt dazu:

Increase the perceived ability (self-efficacy) by making the behavior easier to do

Sie müssen also einen Weg finden, um den Lernstoff einfach in den Tag zu integrieren.

Das kann auf zwei Wegen geschehen:

  • Sie nehmen sich vor, (zunächst) nicht alles, sondern nur einen Teil anzuwenden. Sie reduzieren also den Umfang. Konzentrieren Sie sich z.B. auf nur eine der beiden erlernten obigen Methoden.
  • Sie nehmen sich vor, (zunächst) nur eine sehr kurze Zeit pro Tag oder Woche mit dem Lernstoff zu verbringen. Dieser Zeitraum sollte so kurz sein, dass es Ihnen keine Schmerzen bereitet, ihn wirklich regelmäßig im Tag bzw. in der Woche freizuräumen für den Lernstoff.

Damit erreichen Sie, dass Sie sich nicht zu viel vornehmen, sich nicht überfordern. Gehen Sie lieber in kleinen, dafür verlässlich Schritten vor – statt dass Sie mit großen Sprüngen anfangen, die Sie schnell ermüden oder mit einer organisatorischen Wand kollidieren lassen.

Wenn Sie sich für jeden Tag etwas vornehmen, scheinen mir 15 Minuten (ca. 3% Ihrer Zeit/Tag) die maximale Zeitspanne, die Sie dem Neuen widmen sollten. Natürlich wären 30 Minuten oder gar 45 oder 60 noch besser, doch bleiben Sie realistisch. Freuen Sie sich lieber auf garantierte, einfach einzuplanende 15 Minuten, als dass Sie immer wieder um größere Zeitspannen ringen müssen. (Sie können die Zeitspanne ja auch jederzeit verlängern, wenn Sie merken, dass die Regelmäßigkeit kein Problem darstellt.)

Falls Sie sich aber nicht jeden Tag, sondern nur wöchentlich mit dem Neuen beschäftigen können/wollen, dann empfehle ich max. 120 Minuten pro Woche (5% Ihrer Zeit/Woche) einzuplanen. Längere Zeit können Sie sich kaum am Stück zurückziehen.

Wie gesagt, am wichtigsten ist, dass Sie sich verlässlich Ihrem Lernstoff widmen. Das tun Sie aber nur, wenn die Organisation der dafür notwendigen Zeit, ein no brainer für Sie ist. Sich die Zeit zu nehmen, muss schmerzfrei bis schmerzarm sein. Darauf dürfen Sie keine Energie verwenden müssen, sonst laugen Sie sich aus – und andere Dinge, die weniger Energie erfordern, nehmen diesen Raum wieder ein.

Was Sie übrigens mit dem (reduzierten) Lernstoff in der (kurzen) Zeitspanne tun, ist Ihnen überlassen. Sie können ihn einfach lernend vertiefen und üben. Oder Sie können ihn schon im Projekt anwenden. Vermeiden Sie in beidem Überforderung.

An ein bestehendes Verhalten knüpfen

Der Raum, den das Neue einnimmt, sollte also (zunächst) nur klein sein. Aber wo sollte dieser Raum liegen?

Im Kalender verankern

Wenn Sie schon ein funktionierendes Zeitmanagement haben, dann platzieren Sie den Zeitraum für die Beschäftigung mit dem Lernstoff einfach im Kalender. So gewährleisten Sie, dass Sie das Thema im Tagesstress nicht vergessen. Sie behandeln es dann wie jeden anderen „offiziellen Termin“. Und so sollte es auch sein. Lernen ist nicht weniger wichtig als ein Meeting oder die Abgabe eines Berichtes, die ebenfalls im Kalender stehen.

Allemal mit einer wöchentlichen Lernphase lohnt sich der Eintrag im Kalender. Das muss ja nicht sklavisch immer am selben Tag und zur selben Zeit sein. Diese Woche Mittwoch vormittag, nächste Woche Donnerstag nachmittag usw. ist völlig ok.

Blocken Sie Lernzeiten! Sie sollten first class citizens in Ihrem Kalender sein.

An eine Gewohnheit knüpfen

Für kurze tägliche Lerneinheiten hingegen mag ein Kalendereintrag zu umständlich/schwergewichtig sein. 15-20 Minuten können Sie auch ohne einschieben. Aber wie erinnern Sie sich daran? Indem Sie den Raum fürs Lernen an einen schon bestehenden Raum anschließen.

Ihre Tageszeit ist aufgeteilt in größere und kleinere Räume. Insbesondere wenn Sie die verlassen besteht eine gute Chance, dass Sie einen anderen als üblichen Weg einschlagen. Schließen Sie das Lernen als bereichernden kleinen Umweg an etwas an, was Sie ohnehin jeden Tag garantiert tun. Beispiel:

  • Sobald Sie morgens den Rechner hochgefahren haben, widmen Sie sich als erstes für 15 Minuten dem Lernstoff. Wäre das nicht ein guter Start in den Tag?
  • Wenn Sie mittags vom Essen kommen, überwinden Sie das „Suppenkoma“ mit 20 Minuten Lernzeit. Das macht mehr Spaß als gleich wieder ans Bug Fixing zu gehen.
  • Jeden Tag nach dem Daily Standup konzentrieren Sie sich zuerst 15 Minuten auf den Lernstoff, bevor Sie mit der Projektarbeit loslegen.

Sie haben sicher noch mehr und andere Gewohnheiten, an die Sie das Lernen binden können. Nehmen Sie sie als automatische Erinnerungen während des Tages, den Lernstoff nicht aus den Augen zu verlieren.

Je kürzer der Zeitraum für das Lernen ist, desto besser muss natürlich die Vorbereitung sein, den Lernstoff wieder aufnehmen zu können. Machen Sie Lesestoff griffbereit (als Buch mit Lesezeichen oder als Link in einer Leseliste), legen Sie ein eigenes Repository mit passenden Projekten an, legen Sie sich eine klare Aufgabe zurecht (z.B. als Link zu einer Kata im Coding Dojo).

Nicht alleine lernen

Abschließend noch die Empfehlung: Lernen Sie nicht allein. Es ist so viel leichter, mit anderen zusammen zu lernen. Damit meine ich nicht, dass Sie ständig diskutieren müssen. Nein, es geht nur darum, die Absicht und auch die Zeit mit anderen zu teilen. Dadurch überwinden Sie eher den inneren Schweinehund. Außerdem ist es leichter, gegen äußere Widerstände den Vorsatz durchzusetzen.

Das wöchentliche Lernen bietet sich für ein Lernen in der Gruppe an. Alle ziehen sich dann – wie im Kalender verabredet – zusammen in einen Raum zurück. Das schafft eine konzentrierte Atmosphäre.

Aber auch tägliches Lernen lässt sich mit anderen organisieren. Wenn das nicht die Kollegen sind, dann vielleicht „Freunde in der Cloud“? Mit Apps wie coach.me ist das sehr einfach möglich – und Ihnen wird auch noch digital geholfen, bei der Stange zu bleiben.

Sollte das nicht funktionieren, hilft ein Accountability Partner, mit dem Sie in 1-2 Wochen Abstand Ihre Erfolge, Strategien, Ziele besprechen können. Sie glauben gar nicht, wie hilfreich solche Gespräche sein können, um Vorsätze systematisch umzusetzen. Ein „Gewissen auf zwei Beinen“ wirkt Wunder, wenn Sie meinen, es aus eigener Kraft nicht zu schaffen.

 

Sie sehen: Vorsätze in die Tat umsetzen ist möglich. Je kleiner zunächst der Aufwand, desto höher die langfristige Erfolgswahrscheinlichkeit. Nehmen Sie sich also nicht zu viel vor. Aber nehmen Sie sich ein bisschen vor – und fangen Sie einfach an und machen dann weiter und weiter und weiter… ;-)

Kommunikation zwischendurch mit Slack

Im Präsenztraining, wenn also Trainer und Teilnehmer co-located sind, findet die Kommunikation natürlich vor allem mündlich statt. So sind Geschwindigkeit und Bandbreite maximal. (Zusätzlich kommen auch Code und Tafelbild zum Einsatz.)

Darüber hinaus gibt es dann noch Kommunikation per Email, um einmalig Unterrichtsmaterialien zu verteilen oder mehrfach Hausaufgaben „einzusammeln“.

Das passt erstmal so und ist ganz natürlich. Doch immer wieder haben wir festgestellt, dass es eine Lücke gibt. Mündliche synchrone Kommunikation ist wunderbar in vielen Fällen, schriftliche asynchrone „langlaufende“ Kommunikation per Email ist auch wunderbar in anderen Fällen.

Dazwischen gibt es jedoch noch Fälle, die nach einer „kleinen schriftlichen Kommunikation zwischendurch“ rufen. Beispiele:

  • Der Trainer zeigt eine Aufgabe aus dem Coding Dojo und will den Link allen Teilnehmern zur Verfügung stellen, damit sie auf ihren Rechnern den Text selbst durchblättern können.
  • Ein Teilnehmer recherchiert für die anderen zu einem Thema und will das Ergebnis kurz allen mitteilen.
  • Zu einer Aufgabe soll ad hoc eine Beispieldatei allen Teilnehmern zur Verfügung gestellt werden.
  • Nach dem Training hat ein Teilnehmer eine Frage.

Natürlich lassen sich diese Fälle mit Email bestreiten. Doch das ist irgendwie umständlich. Alle Teilnehmer in die Adressliste eintragen ist nervt, dann fehlt womöglich eine Email-Adresse, die Email landet bei einem Teilnehmer im Spam oder wird von einer wohlmeinenden Server-Policy wegen eines Anhangs blockiert usw. usf.

Email ist schlicht für manche Kommunikationsfälle zu schwergewichtig und zu wenig „dokumentenorientiert“.

Slack to the rescue

Deshalb führen wir bei der CCD School nun den Teamchat mit Slack ein. Slack hat sich seit Jahren für die interne Kommunikation in vielen Projekten bewährt. Nun wollen wir davon auch bei Trainings profitieren.

Jeder Trainingsteilnehmer wird zu einem Slack-Team für alle Trainings der CCD School eingeladen.

In diesem Team gibt es für jedes Training einen privaten Channel. Der ist für die broadcast Kommunikation zwischen den Teilnehmern. Darin können Links und andere Ressourcen gepostet werden; er ist das Medium für Diskussionen – bis es günstig ist, sie in einem anderen Medium weiterzuführen.

Zusätzlich gibt es direkte „Drähte“ zu jedem Teilnehmer (private chat) und es können Chats für Kleingruppen angelegt werden.

Einen Moment haben wir darüber nachgedacht, wie es ankommen mag, dass in diesem Team alle Trainings zusammenlaufen, also sowohl offene wie inhouse. Könnte sich da nicht ein Kunde in seiner „Privatsphäre“ verletzt fühlen?

Theoretisch könnte das sein. Doch wir halten den Fall für sehr selten, so dass wir nicht vorzeitig für ihn optimieren wollen. Sollte er eintreten, schauen wir, wie wir dann damit umgehen. Einstweilen wollen wir jedoch alle Teilnehmer und Kunden motivieren, das einheitliche Team als Chance zu sehen.

Dass ein Unternehmen ein Training durchführt, ist ja auch nicht unmittelbar sichtbar. Jeder Teilnehmer sieht nur die Channels, denen er zugeordnet wird. Lediglich über die Liste aller Mitglieder im Slack-Team ist mit einigen Klicks feststellbar, wer insgesamt dabei ist. Je mehr das dann allerdings sind, desto weniger ist klar, ob sie an einem inhouse oder offenen Training teilnehmen/teilgenommen haben und wann das war. Dass daraus Spam entsteht, ist kaum zu erwarten.

Also sind die Chancen durch eine wachsende Community an Trainingsteilnehmern einstweilen größer als sehr unwahrscheinliche nachteilige Effekte.

Mit jedem Teilnehmer mehr in dem Slack-Team vergrößert sich nämlich die Community derer, die sich mit dem Thema Clean Code Development im Allgemeinen und unserem Lehrstoff im Konkreten beschäftigen. Wer eine Frage hat, hat hier über den Channel #general also eine wachsende Zahl Ansprechpartner jenseits des Kreises seiner Trainingskollegen.

Andererseits können alle von Antworten auf Fragen von einzelnen profitieren, selbst wenn die in einem privaten Channel gestellt worden sein sollten. Denn wenn wir finden, dass eine Antwort von allgemeinem Interesse ist, dann können wir sie (zusammen mit der Frage) in #general posten.

Slack ist unserer Erfahrung nach ein sehr unkompliziertes Werkzeug für die „kleine asynchrone Kommunikation zwischendurch“. Hier lassen sich kurze Mitteilungen verschicken, aber genauso Dokumente „für die Ewigkeit“ hinterlegen.

Slack wird unsere Kommunikation im Training und außerhalb flüssiger gestalten. Darauf freuen wir uns.

 

P.S. Achja, da ist natürlich noch die zu erwartende Klage „Muss denn ein weiteres Tool sein? Haben wir nicht schon genügend am Start?“

Darauf eine Antwort in zwei Teilen:

  • Nein, wir haben noch nicht genügend Tools am Start, wenn diese Kommunikationsfälle noch nicht durch sie abgedeckt sind. Ob man dann Slack oder HipChat oder etwas anderes benutzt, ist natürlich egal. Wir haben uns für Slack entschieden, weil… weil es irgendwie bisher das kleinste Übel war ;-)
  • Slack-Clients gibt es für den Desktop und den Browser. Man kann installieren, muss aber nicht. In jedem Fall ist das in einer Minute getan, sollte also für gestandene Entwickler kein Drama sein. Wer Slack außerhalb des Trainings nicht nutzen will, muss den Client nicht offen haben. Über Email-Benachrichtigungen kann man auf dem Laufenden bleiben, ob sich etwas in den Kanälen getan hat, so dass man nur bei Bedarf das Tool wieder anwerfen muss.

Angesichts der Einfachheit und Nützlichkeit von Slack glauben wir, dass der kleine Mehraufwand sich mehr als lohnt.

Und vielleicht lernt der eine oder die andere es ja auch genauso schätzen wie wir ;-) Etwas Neues muss ja nicht gleich nachteilig sein, oder?

Die Flexibilität, sich leicht auf Slack einzulassen, könnte sogar ein Zeichen dafür sein, bereit für echtes Clean Code Development zu sein. Denn dabei geht es auch um flüssige Reaktion auf Neues und Weiterentwicklung. Clean Code Development beginnt im Kopf!

Lernen mit Tagebuch

Regelmäßig lernen ist wichtig. Dabei hilft Begleitung bzw. Feedback von außen. Dafür sind wir als Trainer der CCD School gerne da. Allerdings können wir ja nicht bei jedem Lernschritt neben Ihnen sitzen. Das skaliert nicht, wäre zu teuer und muss auch nicht sein.

Lernen für sich oder in kleiner Gruppe ohne Betreuung hat nämlich auch seinen Vorteil. Sie können dann mehr in Ihrem Tempo fortschreiten. Und Sie lernen durchaus auch tiefer, weil Sie eben mehr auf sich allein gestellt sind. Es geht dann vielleicht langsamer voran, weil Ihre Fragen nicht jederzeit von einem Trainer beantwortet werden können. Doch durch die mühsamere Erarbeitung von Antworten durch Sie selbst sitzt das Gelernte dann fester.

Lernen sollte also aus einer guten Mischung von Begleitung und Autodidaktik stattfinden. Deshalb bieten wir Termine der CCD School auch nur im Abstand von 4–6 Wochen an.[1] Zwischendurch soll selbstständig gelernt werden.

Das hört sich sinnig und einfach an, oder?

Leider hat dieses Vorgehen einen Haken. Wieder und wieder müssen wir feststellen, dass das Selbstlernen den CCD School Teilnehmern schwer fällt. Das hat auch ein kleines Experiment gezeigt, welches Trainer Ralf Westphal Anfang 2015 durchgeführt hat. Er hatte einen “Selbstlern-Challenge” ausgerufen: 10 Teilnehmer sollten sich 10 Wochen lang regelmäßig und selbstständig in Flow Design[2] einarbeiten. Das Ergebnis war ernüchternd. Trotz einer losen Begleitung und “finanziellem Anreiz” haben 50% der Teilnehmer nicht durchgehalten.

Nach dieser Erfahrung wollen wir das Thema selbstständiges Lernen in der CCD School noch bewusster angehen. Als erste Hilfestellung unser Tip:

Dokumentieren Sie Ihren Lernfortschritt in einem Lerntagebuch.

Ein Lerntagebuch soll das Lernen greifbarer machen und fokussieren.

Greifbarer wird es, weil Sie beim Lernen damit eine Spur hinterlassen. Ob das Lernen darin besteht, dass Sie etwas lesen oder mit Kollegen eine Aufgabe diskutieren oder einen Entwurf machen oder etwas codieren… Egal, wie flüchtig Ihre Lernprodukte sind, im Lerntagebuch findet all das Niederschlag.

Ein Lerntagebuch ist für Sie ein – womöglich papierernes – Dokument, das Ihnen oder auch anderen zeigt, dass und wie sie beim Lernen vorankommen.

Fokussierter wird das Lernen, weil Sie im Lerntagebuch ein Destillat des Lernens festhalten. Egal was und wie Sie lernen, mindestens für den Eintrag im Lerntagebuch müssen Sie sich konzentrieren. Für einen Moment gehen Sie in die Reflexion und lassen das Lernen Revue passieren. Ihnen wird das Lernen als eigenständige Tätigkeit nochmal bewusst.

Medium

Das Medium für Ihr Lerntagebuch ist fast egal. Sie können es in Word oder Evernote führen oder in einem physischen Notizbuch. Früher hat Trainer Ralf Westphal zur Dokumentation seiner Gedanken und seines Lernens Notizbücher benutzt:

Notizbücher als Lerntagebuch

Heute machter Einträge in Evernote-Notizen. Für jedes Lernthema gibt es eine, die er pro Lerneinheit fortschreibt. Hier ein Eintrag aus seinem Lerntagebuch zur Programmiersprache Groovy:

Evernote als Lerntagebuch Organisieren Sie sich Ihr Tagebuchmedium, wie Sie möchten. Nehmen Sie einen Ordner oder eine spezielle Tagebuch-App, schreiben Sie auf Papier oder auf dem iPad. Vielleicht hilft es Ihnen, sich an die Wichtigkeit des Lernens zu erinnern und es zu tun, wenn Sie ein Notizbuch am Arbeitsplatz liegen haben. Vielleicht macht es Ihnen so ein Papierbuch auch leichter, gegenüber Kollegen das Lernen zu vertreten. Oder Ihnen fällt es leichter, über das Lernen zu reflektieren, wenn Sie auf einer Tastatur flink Ihre Gedanken in ein Softwarewerkzeug fließen lassen können.

Inhalt

Ein Lerntagebuch soll Ihnen beim Lernen natürlich keine Last sein. Eher im Gegenteil! Es soll Ihnen Spaß machen, darin am Ende kurz zusammenzufassen, was Sie geschafft haben. Es ist doch schön, sich seiner Fortschritte bewusst zu sein.

Was Sie in Ihrem Lerntagebuch festhalten, steht Ihnen also frei. Ein kleiner Rahmen ist trotzdem hilfreich:

  • Versehen Sie jeden Eintrag mit einem Datum und womöglich sogar Uhrzeit bzw. Dauer der Lerneinheit, z.B. 26.6.2015, 10:00 bis 11:30
  • Wenn möglich, finden Sie eine Titel für den Eintrag. Pro Lerneinheit sollten Sie sich auf ein Thema konzentrieren. (Auch hier gilt das SRP ;-) Dieses Thema dokumentieren Sie mit einer Überschrift zum Eintrag, z.B. Flow Design Entwurf in Code übersetzen
  • Schreiben Sie zumindest in Stichpunkten auf, was Sie während der Lerneinheit getan haben, z.B.
    • Funktionseinheit mit einem Input/Output in Funktion übersetzt
    • Mehrere Funktionseinheiten/Funktionen zu einer Klasse zusammengefasst
    • Funktionseinheit mit mehreren Outputs in Funktion mit Continuations übersetzt
  • Notieren Sie Hürden, über die Sie gestolpert sind, oder Fehler, die Sie gemacht haben. Wenn möglich, sollte darauf natürlich auch eine Verbesserung/Lösung folgen, z.B. Der Aufruf von Funktionen mit Continuations ist schlecht zu lesen gewesen. Aber mit ein wenig Disziplin bei der Einrückung ging es besser.
  • Notieren Sie Ergebnisse und Erkenntnisse. Die ergeben sich natürlich oft aus Hürden/Fehlern, können aber auch Zusammenfassungen/Abstraktionen allgemeinerer Art sein, z.B. Streams im Flow Design wenn möglich mit IEnumerable übersetzen statt mit Continuations.

So könnte dann ein Eintrag in einem Notizbuch aussehen:

Handschriftlicher Eintrag

Oder so könnte er aussehen, wenn Sie Evernote bevorzugen:

Digitaler Eintrag

In einem elektronischen Lerntagebuch können Sie leichter konkrete Ergebnisse Ihres Lernens dokumentieren durch Codeausschnitte oder Screenshots oder Anhänge und Links. Nutzen Sie die Chance, um sich das Lernen plastisch zu machen.

Zusammenfassung

Physische und digitale Lerntagebücher haben ihre je eigenen Vor- und Nachteile. Probieren Sie aus, was Ihnen am besten dient.

In jedem Fall sollten Sie jedoch ein Lerntagebuch führen, egal, ob und wann Sie allein lernen, in der Gruppe oder sogar begleitet. Lassen Sie sich durch ein Lerntagebuch ans Lernen erinnern. Erfreuen Sie sich beim Durchblättern des Lerntagebuchs daran, was Sie alles schon geschafft haben.


  1. Das gilt zumindest für Präsenztermine von 1–2 Tagen. Kürzere online Termine machen auch in kürzeren Abständen Sinn.  ↩
  2. Flow Design ist eine der Methoden, die die CCD School unterrichtet. Softwareentwicklung mit Flow Design führt zu Code, der quasi automatisch wesentliche Prinzipien des Clean Code Development einhält. Beim Flow Design wird Verhalten von Software in Form von Datenflüssen entworfen und codiert.  ↩

Die CCD School geht online

CCDS onlineNach einigem Experimentieren ist es nun soweit: Clean Code Development können Sie nun im Internet lernen. Interaktiv, persönlich, individuell.

Das ist aber nicht nur zeitgemäß, sondern gleichermaßen praktisch wie ökologisch.

Der ökologische Vorteil liegt auf der Hand. Niemand muss mehr für CCD Unterricht reisen, nicht mit dem Auto, nicht mit Bahn oder Flugzeug. Clean Code Development kann man lernen „from the comfort of your home“. Nicht mehr als Webcam und Headset sind nötig. Naja, eine vernünftige Internetanbindung sollte auch noch vorhanden sein. Außer in wenigen Breitband-Diaspora-Gebieten, sollte das jedoch kein Problem sein.

Praktisch ist der online Unterricht aber auch. Er spart Transaktionsaufwand (Reisezeit und Reisekosten). Damit ist er in kleineren Happen und kurzfristiger möglich. Wenn das nicht eine gute Nachricht für jeden kostenbewussten Chef ist… ;-)

Außerdem findet er in kleineren Gruppen statt. Das kann dem Lernen nur zuträglich sein.

Mit dem Tool GotoMeeting ist flüssige Videokommunikation möglich. Screensharing und Chat gibt es auch. Andere Angebote wie TeamViewer, Google Hangouts oder Skype haben sich als qualitativ genügend erwiesen für längere Sitzungen mit mehreren Teilnehmern.

Dazu kommt dann noch ConceptBoard als gemeinsames online Whiteboard, um Gedanken grafisch spontan festzuhalten. Dafür lohnt sich allerdings noch ein Grafik-Tablet wie Wacom Bamboo mit Stift. Ist ja aber auch für kleines Geld zu haben.

Online Treffen beginnen dann gewöhnlich mit 5-10 Minuten technischer „Kalibrierung“ bis alles bei allen läuft. Aber anschließend flutscht es. Das Gespräch auch mit 5-6 Teilnehmern funktioniert erstaunlich gut. Der Wechsel zwischen Whiteboard und Bildschirmpräsentation ist womöglich sogar einfacher als offline. Kein Kabel muss mehr umgesteckt werden für den Beamer. Und wer sich mal ausklinken will, der stört auch weniger.

Sich vorher persönlich zu kennen, mag das online Treffen noch ein bisschen leichter machen. Doch am Ende bringt die Videokommunikation in jede Runde schnell Vertrauen.

Und so sind wir zuversichtlich, dass der online Unterricht eine große Zukunft hat. Er kann kostengünstiger und flexibler angeboten werden, so dass die geringen Nachteile schnell aufgewogen werden.

Clean Code Development Training geht jetzt also online – wer geht mit?

Die CCD School schwenkt um

Ein zentraler Begriff bei Lean Startups ist das „Pivoting“. Es bedeutet Umschwenken, Kursänderung, wenn man feststellt, dass eine Strategie nicht so funktioniert, wie gedacht. Lean Startups sind ja Forschungsstätten, die Geschäftsmodell-Hypothesen überprüfen. Erfolg verifiziert sie, Misserfolg falsifiziert sie.

So tun wir es nun auch bei der CCD School. Wie schon im April gesagt, sehen wir sie als Startup. Wir hatten eine Hypothese, wie regelmäßiges Lernen für Lernende und Lehrer funktionieren könnte… und lagen damit nicht 100% richtig. Macht nichts. Ganz im Sinne des Elastischen Manifests sagen wir: Fortschritt vor Ankommen, Reaktion vor Planerfüllung. Als schwenken wir um.

Wir behalten natürlich das Bewährte bei. Immer noch geht es ja um eine bestimmte Idee. Die darf durch ein Umschwenken nicht kompromittiert werden. Die CCD School steht weiterhin für angeleitetes und fokussiertes Lernen. Fokussiert sein soll das Lernen durch Konzentration auf einen Themenkomplex (Clean Code Development) sowie ausdrücklich geplante Zeit fürs Lernen. Angeleitet soll das Lernen sein, um Hilfestellung im Thema zu geben, aber auch, um beim Lernen des Lernen zu unterstützen. Wenn niemand am Lernenden „zieht“, verliert der leicht die Konzentration oder verliert sich in einem „Tal der Tränen“.

Änderungen nehme wir in zwei Aspekten vor. Bei der Regelmäßigkeit und der Individualität.

Die Regelmäßigkeit muss natürlich grundsätzlich bleiben, sondern würde sich die CCD School nicht von anderen Trainings unterscheiden; sie steht im Kern der Idee. Doch gerade da hat sich unsere Hypothese als teilweise unzutreffend erwiesen. Nicht, dass das regelmäßige Lernen nicht besser wäre als das sporadische. Aber die terminliche Belastung und die „Transaktionskosten“ sind bei wöchentlichem Unterricht sowohl für Lernende wie für Lehrer hoch, gar zu hoch.

Deshalb schwenken wir vom wöchentlichen Unterricht um auf monatlichen. In Zukunft bietet die Schule Unterricht im Abstand von 3-5 Wochen an. Das ist seltener als bisher, aber immer noch häufig genug, um als regelmäßig empfunden zu werden. Der nächste Unterrichtstermin ist in absehbarer Entfernung, so dass Gelerntes nicht vergessen wird und noch nicht Geschafftes vertagt werden kann.

Unterrichtsblöcke dauern nun auch nicht mehr 4 Stunden, sondern 1 Tag. Dadurch muss zwar mehr Arbeitszeit eingesetzt werden… doch das halten wir beim vergrößerten zeitlichen Abstand für vertretbar.

Erste Erfahrungen mit diesem neuen Rhythmus sind ermutigend.

Ganz grundsätzlich soll individuelles Lernen natürlich weiterhin in der CCD School möglich sein. Wir freuen uns über jeden Lernenden, der sich aus eigenem Antrieb etwas vornimmt, woran er/sie arbeiten möchte. Die Erfahrung zeigt jedoch, dass gerade am Anfang ein großer Wunsch nach mehr Anregung und Anleitung vorhanden ist. Daher geben wir das Format Impuls+Individuallernen auf. Der Unterricht verliert damit den letzten Rest von Plan :-) Stattdessen fließt er einfach, wie es sich ergibt durch das Gebiet des Clean Code Development und besucht nach Bedarf die dortigen „Sehenswürdigkeiten“.

Als Anleiter sehen wir zu, dass es dabei stetigen Fortschritt gibt. Doch auch wer später einsteigt, kann mitreisen. Unsere Hypothese: In dieser Weise wird erstens mehr „Guidance“ gegeben und es ergeben sich natürlichere Anlässe für individuelles Arbeiten. Da besteht nämlich weniger in eigenen Projekten, als vielmehr im Voranschreiten in unterschiedlicher Geschwindigkeit bestimmt durch Auffassungsgabe/Vorbildung und Zeitpunkt des Einstiegs.

Soweit unsere Idee zum „Pivoting“ der Clean Code Developer School. Dieser Hypothese geben wir jetzt mal wieder einige Monate Zeit und reflektieren dann wieder.

Retrospektive zur Sommerpause

Nach knapp drei Monaten CCD School (CCDS) in München, sind wir jetzt in die Sommerpause gegangen. Zeit für eine kurze Reflexion. Die CCDS ist ja ein Experiment bzw. ein kleines Start-up. Da lohnt die Frage, ob die These bestätigt ist bzw. es Zeit für ein Pivoting ist oder alles weitergehen kann wie bisher.

Die Grundthese halten wir für bestätigt. Das Lernen in kleinen, regelmäßigen Happen ist eine sehr gute Sache. Fortschritt ist individuell möglich. Und die Anleitung beim Lernen ist wichtig. Dazu hat es nur positive Rückmeldung gegeben.

Den Unterrichtsplan haben wir allerdings nicht genau eingehalten. Am Anfang jedes Unterrichtsblocks gab es zwar eine Zeit gemeinsamer Arbeit, doch das Thema hat sich meist spontan ergeben. Mal war da mehr Vortrag durch Stefan oder mich, mal mehr allgemeine Diskussion. Das fühlte sich recht organisch an. Dennoch ist es gut, den Themenkomplex in kleinere Einheiten aufgeteilt im Hinterkopf zu haben. Die Vorarbeit für den Unterrichtsplan war also nicht vergebens.

Die plattformspezifischen Anteile werden wir aber streichen. Nicht, dass wir dazu nichts mehr sagen wollen, nur sollen die nicht mehr Bestandteil eines offiziellen Curriculums sein. Es hat sich gezeigt, dass der Unterricht sehr gut plattformübergreifend funktioniert. C# oder Java oder JavaScript? Das ist nicht wirklich wichtig. Als Trainer kommen wir mit allen zurecht – im Zweifelsfall müssen halt die Teilnehmer etwas in ihre Plattform einsteigen, um das eine oder andere Implementationsdetail mal zu erforschen. Aber auch das ist ja eine Sache, die kann man lernen und die gehört auch zum (selbstständigen) Lernen.

Der Knackpunkt bei der CCDS ist – das war nicht anders zu erwarten – der Aufwand. Oder genauer: Das Verhältnis von Aufwand und Effekt. München hat sich leider nicht als so offen für die CCDS herausgestellt, wie wir es gedacht hatten. Die Münchener .NET User Group hatte kein Interesse. Aus den 219 angeschriebenen Mitgliedern der CCD Gruppe bei XING gab es nur 2-3 Rückmeldungen. Sehr schade.

Andere Communities jedoch waren, als sie davon gehört haben, viel interessierter. Allen voran in Berlin und im Rhein/Main Gebiet hat man gefragt, ob wir nicht auch dort die CCDS öffnen könnten. Und dann gab es noch ein paar Anfragen nach inhouse Schools.

Diesen Widerspruch zu unserer These „Im Süden ist die Entwicklerdichte am höchsten, da finden wir am ehesten Teilnehmer“ werden wir jetzt mal in der Sommerpause diskutieren.

Angesichts des Aufwands stellt sich auch die Frage nach der Frequenz. Knapp 3 Monate jede Woche in der Ferne vor Ort sein, belastet den Reisemuskel sehr stark. Auch der eng getaktete regelmäßige Einsatz ist schwer mit unseren sonstigen Trainings- und Beratungsaktivitäten schwer zu vereinbaren. Was für die Teilnehmer gut ist, belastet uns als Trainer. Da müssen wir die Balance auch noch besser einstellen.

Ich denke, zweierlei könnte sich ändern: Die CCDS könnte in Semestern stattfinden. Die wären 2-3 Monate lang; es könnte Spring, Summer, Autumn, Winter Schools geben.

Oder mit der Frequenz könnten wir spielen. Ist Unterricht jede Woche wichtig oder reicht es alle 2 oder 4 Wochen? Ich denke, das wichtigste ist, den Abstand nicht zu groß zu machen. Unterrichtsblöcke im Monatsabstand scheinen mir da das Äußerste.

Wenn die Frequenz sinkt, müsste aber wohl auch etwas an der Dauer gedreht werden, sonst kommt nicht genug Stoff zusammen für eine größere Pause zwischen den Blöcken. Alle 3-4 Wochen 1 ganzer Tag oder 2 halbe Tage (Nachmittag + Vormittag) könnten ausreichen.

Soweit der Präsenzunterricht. Dazu könnte eine Betreuung aus der Ferne kommen. Im Jahr 2013 sollte es doch machbar sein, in kleinen Gruppen online zu arbeiten: Screensharing, Video… das ist doch kein Hexenwerk. Angebote gibt es viele. Was ist aber wirklich verlässlich für 1-2 Stunden online Treff? In dieser Hinsicht werden wir auch experimentieren müssen, um besser zu skalieren. Ausschließlich online lernen, halte ich für keine gute Sache. Regelmäßig ausschließlich lernen in offline Präsenz ist schwierig. Der Mix wird es machen.

In jedem Fall hat es uns bei aller Reiseanstrengung Spaß gemacht. Und den Teilnehmern auch. Wir bleiben also dran, dieses Lernangebot aufrecht zu erhalten.