Last und Lust der Kommiteesoftware

Gerade habe ich das Originalpaper "How Do Commitees Invent" von Mel Conway gelesen, dem Conway´s Law entstammt. Da ist mir unerwartet ein Schauer kalt den Rücken runtergelaufen bei dieser Aussage:

"To the extent that an organization is not completely flexible in its communication structure, that organization will stamp out an image of itself in every design it produces. The larger an organization is, the less flexibility it has and the more pronounced is the phenomenon."

Nicht, dass ich Conway´s Law nicht schon vorher gekannt hätte. Aber manchmal vergrößert sich die Tragweite von Wissen durch neue Formulierungen oder einen anderen Blickwinkel einfach nochmal. Vielleicht liegt es auch daran, dass ich mich gerade Technologien abseits der Microsoft-Schiene oder überhaupt des Mainstreams annähere wie Erlang oder CouchDB. Jedenfalls habe ich den Absatz oben innerlich quasi simultan so gelesen:

"To the extent that Microsoft is not completely flexible in its communication structure, Microsoft will stamp out an image of itself in every design it produces. The larger Microsoft is, the less flexibility it has and the more pronounced is the phenomenon."

Und dann habe ich an den Entity Framework, an Oslo, an Visual Studio, an Windows und an andere Microsoft Produkte/Technologien gedacht. Microsoft hat sich seit 1990 und Visual Basic 1.0 sehr verändert. Für mich, der ich vor einigen Jahren noch viel mit Microsoft Deutschland zu tun hatte, war insbesondere ein Änderungsschub um 2002/3 zu spüren.

Wasfüreine Organisation ist Microsoft also heute? Inwiefern ist Microsoft "not completely flexible in its communication structure"? Das hat natürlich nur wenig damit zu tun, ob Microsoft-Mitarbeiter Email oder Blogs benutzen. Es geht vielmehr um die organisationsinternen Kommunikationswege und Weisungsbefugnisse.

Dieselbe Frage lässt sich natürlich auch Oracle oder IBM oder SAP stellen. Aber dort kenne ich mich nicht so mit den Produkten aus.

Sind Microsoft-Produkte heute also vielleicht schon quasi notwendig mehr Last als Lust? Sind sie womöglich heute schon weniger der Lösung eines Problems als der inneren Struktur von Microsoft angemessen? Hat Microsoft eine Größe und damit Kommunikationsstrukturen erreicht, die sozusagen notwendig zu Overengineering führen?

Ich tendiere da mal zu einem vorsichtigen "Hm... es scheint immer mehr der Fall zu sein..." Das bedeutet nicht, dass nun alle Technologien über diesen Kamm geschoren werden müssten. Es geht nur um die Tendenz sowie eine daraus abzuleitende Vorsicht. Auch ist Microsoft inzwischen so groß, dass es immer wieder "Taschen der Widerstandes" geben kann und gibt, die nicht in die allgemeinen Kommunikationsstrukturen 100% eingebunden sind und insofern auch andere Systeme bauen können. Die Gruppe um die Concurrency Coordination Runtime fällt mir da ein oder das F# Team.

Doch sobald diese Taschen sich öffnen wollen, kollidieren sie natürlich irgendwann mit der "großen Organisation". Und dann kommt es darauf an... Was macht die mit diesen aus ihrer Sicht eigentlich anarchischen Systemen?

Technisch gesehen, läuft Microsoft qua seiner Größe und Organisation also langsam (oder immer schneller?) in den Morast. Die interessanten Sachen passieren dann irgendwann einfach dort nicht mehr. (Ja, ich weiß, wieviel Forschungsgelder Microsoft ausgibt. Dennoch ist es schwierig für eine solch große Organisation, den Geist der Anfangsjahre zu bewahren. Das ist lange, sehr lange recht gut gegangen - aber die Controller und damit die formale Kommunikation sind in unserer Wirtschaft ein Naturgesetz. Sie lassen sich hinauszögern, aber nicht vermeiden.)

Beweis #1: Das Internet. Microsoft hat es verschlafen und nur mühsam aufholen können. Beweis #2: O/R Mapping. Hier hat Microsoft lange geschlafen bzw. nichts zustande gebracht und ringt immer noch um ein vernünftiges Produkt. Beweis #3: IDE. Visual Studio kann einiges, aber die Qualität in puncto Flexibilität, wie sie heute so wichtig ist, die Eclipse bietet, hat VS nicht. Beweis #4: Microsoft Office. Ohne Zweifel hat Microsoft hier einen Standard geschaffen. Aber Innovation ist etwas anderes. Die spannenden Sachen wie realtime Kollaboration und neue Kommunikationsformen passieren z.B. bei Google.

Was den Technikern eine Last ist, mag anderen aber natürlich eine Lust sein. Controller lieben solche Moloche wie Microsoft. Hatte Microsoft lange Jahre mit dem Image einer "Bastelbude" zu kämpfen, die nicht "enterprise ready" ist, so gibt es diesen Zweifel in seiner grundlegenden Ausprägung nicht mehr. Microsoft ist hoffähig. Wer sich für Microsoft entscheidet - von BizTalk Server bis Entity Framework -, der wird nicht gefeuert, wenn es nicht klappt. Ob die Entscheidung allerdings in technischer Hinsicht die beste ist, hat damit nichts zu tun. Microsofts schiere Größe ist der scheinbare Garant für einen Mindesterfolg.

Nach Conway´s Law also mal meine These wie hier illustriert:

Eine gewisse Zeit lang nimmt die Qualität der Technologien durch Wachstum zu. Aber ab einer gewissen Größe sinkt sie eben - sogar unter das Ausgangsniveau. Mit "Qualität"  meine ich natürlich sozusagen die "overall user experience" von der Funktionalität über die Dokumentation bis zum Service.

Wünschen tue ich mir das für Microsoft oder IBM oder Google oder sonst einen Technologieanbieter nicht. Meine Befürchtung ist nur, dass es eben unvermeidlich ist. Deshalb sollten wir auf der Hut sein und gerade als Techniker immer unser Radar kreisen lassen auf der Suche nach Innovationen, die uns wirklich voran bringen. Das Entity Framework - sorry to say - gehört nicht dazu. Und ob Oslo "es reißen wird", halte ich auch noch nicht für ausgemacht.

Also: Wachsam bleiben! Links und rechts andere Technologien und Paradigmen anschauen. Nicht auf Microsoft warten. Im eigenen Haus nicht den Controllern die Technologieentscheidungen überlassen. Nur so erhalten wir uns die Lust an den Technologien, statt fatalistisch "Kommiteesoftware" hinterherzulaufen.

Anforderungsaikido - Den Kunden mit gnadenlosen Requirements zur Agilität motivieren

Auf dem Architecture.NET Open Space neulich in Düsseldorf bin ich in einem Gespräch über einen interessanten Gedanken gestolpert. Thema war das Übliche:

Gemeinhin ist es ja so, dass der Kunde eine Anforderung stellt, das Team versucht sie umzusetzen und der Kunde dann irgendwie nicht ganz zufrieden ist.

Das ist für uns quasi normal, wenn auch unbefriedigend. Wir glauben nicht mehr daran, dass der Kunde genau weiß oder sagen kann, was er will. Also leben wir mit Experimenten, Angeboten, Glaskugelguckerei - und damit YAGNI.

Für den Kunden ist das aber keinesfalls normal. Der glaubt ja allermeistens, dass er genau weiß, was er will. Und er glaubt, dass er nach all den Sitzungen über Anforderungsdokumenten es auch richtig rübergebracht hat. So ist es kein Wunder, wenn er am Ende beim Test verwundert oder gar ärgerlich ist, nicht vorzufinden, was er gewollt hat.

Das mag objektiv ungerecht sein - subjektiv ist es aber so. Laien haben meist entweder den Eindruck, alles ausreichend spezifiziert zu haben, oder den Anspruch, dass die Softwareentwicklung in ihrer Weisheit die Lücken schon selbstständig schließen wird.

Wir wir alle wissen, ist das nicht so und funktioniert auch nicht.

Jetzt der interessante Gedanke: Damit wir nicht länger während der Implementierung rätseln, YAGNI vermeiden und der Kunde glücklicher wird, könnten wir es ja zur Abwechslung mal mit "gnadenlosen Requirements" versuchen. Gnadenlos nenne ich sie, weil es darum geht, immer genauer und genauer und genauer nachzufragen. Quasi bis in die Absurdität hinein.

"Lieber Kunde, willst du es so oder anders? Wenn so, willst du es dann genau so oder lieber so? Wirklich? Echt? Garantiert? Überleg nochmal. Oder möchttest du es doch vielleicht lieber leicht abgewandelt so?"

Das klingt nicht nur hier nervig in seiner Allgemeinheit. Auch in einem Kundengespräch ist das nervig. Dabei geht es allerdings nicht darum, wirklich das absolut letztendgültig "Richtige" aus dem Kunden herauszuholen. Nein, nein! Im Gegenteil! Auch wenn die konkreten Fragen sich natürlich auf seine Problemdomäne bzw. die vorgestellte Lösung beziehen, soll der Kunde nicht wirklich auf die immer detaillierter werdenden Frage eine präzise Antwort haben.

Der Kunde soll vielmehr selbst spüren, dass er keine (!) Antwort hat. Ja, ganz genau: Er soll an den Rand seiner Selbstsicherheit geführt werden. Es soll ihm durch immer weitergehende Entscheidungen, die tatsächlich nur er treffen könnte - aber eben nicht kann, weil er auch die Antwort nicht weiß -, gezeigt werden, dass er selbst (noch) nicht genau weiß, was er haben will.

Das Ziel der Anforderungsanalyse ist mithin nicht mehr, die Anforderungen genau zu erheben, sondern nur genügend gute Anforderungen zu bekommen, um loslegen zu können. Und darüber hinaus soll Kunde wie Team klar sein, dass eben viel im Unklaren ist und auch nicht klarer sein kann. Es geht halt nicht anders.

Damit ist dann der Kunde idealerweise weichgekocht für ein iteratives Vorgehen. Er kann dann auch gefühlsmäßig nachvollziehen, dass ihm nicht mit einer "Big Bang Lösung" gedient ist. Er ist dann selbst froh, sich seinen eigenen Vorstellungen schrittweise, iterativ anzunähern.

Gnadenlos ist solche Anforderungserhebung, weil sie den Kunden echt beim Wort nimmt. Er hat ja erstens den Anspruch, seine Anforderungen zu kennen, und zweitens den Glauben, dass die sich dann auch geradlinig und klar planbar umsetzen lassen.

Nun, dann nehmen wir ihn eben mit gnadenlosen Requirements ernst. Dann soll er mal die "Hosen runterlassen" und wirklich, wirklich detailliert jeden Fliegenschiss bestimmen. Er wird dann schon merken, dass er damit nicht weit kommt. Wichtig ist dafür natürlich, quasi nie mit den vom Kunden formulierten Anforderungen zufrieden zu sein. Er muss aufgeben beim Spezifizieren. Er muss sagen: "Ok, ihr habt gewonnen. Ich weiß es wirklich nicht genau. Versucht es also mal und zeigt mir das Ergebnis möglichst schnell. Aber dann lasst uns auch in kleinen Schritten vorgehen."

Akzeptiert sind gnadenlose Requirements erst, wenn der Kunde auf der Matte liegt und abklopft. Dann (!) können wir mit ihm ernsthaft sprechen. Dann machen heben wir ihn auf und versichern ihm, dass das alles gar nicht so schlimm ist. Es gibt einen Ausweg und der heißt agiles Vorgehen.

Ja, den Gedanken fand ich schon interessant. Mit gnadenlosen Requirements den Kunden mit den eigenen Waffen "agilitätsreif zu schießen" ;-) Oder etwas weniger brutal ausgedrückt: Anforderungsaikido. Die Energie des Kunden aufnehmen, weiterführen und ihn damit aus seiner Balancezone zu ziehen. Dann fällt er in unseren agilen Arme ;-) Ja, das klingt etwas netter, glaub ich.

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

Asynchronizität und Verteilung üben - Szenarien für verteilte Anwendungen

Wer was Neues lernen will, tut das am besten zunächst mit Übungen. Chirurgen lernen neue Techniken erst an toten und/oder nicht menschlichen Lebewesen, Piloten lernen im Simulator. Und ich will den neuen Application Space ausprobieren oder allgemeiner asynchrone und verteilte Architekturen üben. Was sind aber Übungsaufgaben, an denen ich mich versuchen kann? Einen asynchronen und verteilten Service aufzusetzen ist ja trivial. Von dem Service dann auch noch Notifikationen zu bekommen oder Pub/Sub einzurichten, das ist auch trivial. Jeweils für sich genommen sind diese Dinge einfach - aber wie füge ich diese Bausteine zu etwas Größerem, Realistisch(er)em zusammen? Erst in einem umfassenderen Szenarion, das nicht von der Technik ausgeht, sondern von "Kundenanforderungen" kann ich auch feststellen, was einer Technologie wie dem Application Space noch fehlen mag (oder wo sie besonders geeignet ist).

Hier möchte ich nun einige Szenarien zusammentragen, die mir als Übungen für Verteilung und Asynchronizität erscheinen. Sie sind mehr oder weniger komplex, aber immer irgendwie "zum Anfassen". Jedes bietet für die zu übende oder evaluierende Technologie eine andere Herausforderung. Ich werde sie mit dem Application Space implementieren, wer mag, kann aber natürlich WCF pur oder mit Azure oder Jabber pur oder MassTransit oder NServiceBus oder Rhino Service Bus oder MSMQ pur oder TCP Sockets pur oder noch ganz andere Technologien damit ausprobieren. Ganz im Sinne der School of .NET Diskussion sehe ich diese Szenarien auch als Chancen für ganzheitliches Lernen. Clean Code Development, Komponentenorientierung, .NET Framework Grundlagen, TDD... all das und mehr kann man auch einfließen lassen.

Szenario 1: Stammdatenverwaltung

Aller Anfang sollte einfach und typisch sein. Deshalb ist mein erstes Szenario eines, mit dem viele Entwickler immer wieder konfrontiert werden: die Stammdatenverwaltung oder "forms over data". Ein Anwender verwaltet mit seinem Client Daten in einer Datenbank mit den üblichen CRUD-Funktionen: Create, Read, Update, Delete. Zusätzlich kann er einen serverseitigen Datenimport anstoßen.

Ob sich für dieses Szenario eine Verteilung überhaupt lohnt, sei einmal dahingestellt. Allemal, wenn aus anderen Gründen eine Anwendung verteilt werden soll, muss auch die Stammdatenverwaltung auf eine solche Architektur abgebildet werden.

Um das Datenmodell einfach zu halten, reicht es aus, wenn das Szenario sich nur um Personen mit ihrer Adresse dreht.

Datenmodell:

• Person(Nachname, Vorname, Straße, PLZ, Ort, Land, Tel, Soundex)

Featureliste:

• Der Anwender kann nach Personen suchen; der Server liefert eine Liste von passenden Personen zurück.
• Der Anwender kann eine gefundene Person bearbeiten und speichern.
• Der Anwender kann eine neue Person anlegen.
• Der Anwender kann eine Person löschen.
• Der Anwender kann gefundene Adressen in eine CSV-Datei exportieren. Der Export kann clientseitig erfolgen.
• Der Anwender kann den Import von Personen aus einer CSV-Datei veranlassen. Dazu muss er dem Server mitteilen, in welcher Datei die Daten liegen. Der Server importiert, meldet zwischendurch den Fortschritt und liefert am Ende ein Importresultat.
• Dublettenprüfung: Jede Person soll nur einmal in der Datenbank stehen. Mehrere Sätze mit denselben Daten sind zu vermeiden, um bei Mailings nicht mehrere Briefe an dieselbe Person zu senden. Um den Vergleich von Personen zu vereinfachen, können sie mit einem Soundex-Wert ausgestattet werden. Wannimmer eine Person gespeichert werden soll (nach Bearbeitung, nach Neuanlage, beim Import) und schon mit einem anderen Datensatz in der Datenbank vertreten ist, wird die Operation verweigert und der Anwender informiert. Die Dublettenprüfung kann in Schritten implementiert werden:
  • Dubletten bei Neuanlage prüfen
  • Dubletten beim Import prüfen
  • Dubletten nach Bearbeitung prüfen

Klingt doch einfach, oder? Hat aber natürlich seine Tücken, denn es gilt ja, diese Funktionalität asynchron und verteilt zu realisieren. Wie kommunizieren Client und Server im Sinne einer solchen Stammdatenverwaltung miteinander?

Herausforderungen:

• Wie werden asynchrone Operationen wie Speichern oder Import im UI repräsentiert?
• Wie meldet der Server den Fortschritt beim Im/Export an den Client (Notifikationen)?

Szenario 2: Referentenfeedback (Heckle Service)

Christian Weyer hat ein schon älteres Szenario in seinem dotnetpro-Artikel "Schnuppern an Azure" (5/2009)mit den aktuellen Technologien neu implementiert. In der dotnetpro 7/2009 greife ich das auf und realisiere es mit dem Application Space.

Die Idee ist einfach: Zuschauer eines Vortrags auf einer Konferenz sollen dem Referenten live Feedback geben können. Sie sollen sozusagen elektronisch zwischenrufen können (engl. to heckle). Dazu hat jeder Teilnehmer einen Client, mit dem er kurze Textnachrichten an den Referenten senden kann, der sie in einem eigenen Frontend auflaufen sieht.

Datenmodell:

• Nachricht(Absendername, Nachrichtentext, Eingangszeitstempel) - Jede Nachricht gehört natürlich zu einem Referenten. Ob das allerdings in der Nachricht vermerkt werden muss, soll hier nicht festgelegt werden.

Featureliste:

• Teilnehmer senden Zwischenrufe an den Referenten.
• Teilnehmer sehen sich die Liste der letzten n Zwischenrufe an.
• Der Referent bekommt jeden Zwischenruf automatisch angezeigt.
• Falls der Referent sein Frontend - aus welchen Gründen auch immer - neu startet, bekommt er die Liste aller bisher eingegangenen Zwischenrufe angezeigt.
• Der Referent identifiziert sich irgendwie, so dass die Teilnehmer ihm und keinem anderen ihre Zwischenrufe senden. Die Teilnehmer müssen einen Referenten also beim Zwischenrufen adressieren. Potenziell kann die Heckle-Anwendung ja gleichzeitig in vielen Vorträgen zum Einsatz kommen.
• Der Veranstalter der Vorträge kann die Zwischenruflisten aller Referenten jederzeit einsehen.

Herausforderungen:

• Wie nehmen Teilnehmer mit dem Referenten Kontakt auf? Direkt, indem sie seinen Rechner adressieren oder indirekt via eines Discovery-Servers?
• Wo werden die Nachrichten vorgehalten, damit vor allem Teilnehmer und Veranstalter sich jederzeit einen Überblick verschaffen können?
• Wie wird insb. der Referent automatisch über neue Nachrichten informiert?

Szenario 3: Tic Tac Toe

Es ist zwar kein typisches Geschäftsanwendungsszenario, aber es macht Spaß: ein Spiel realisieren. Bei Tic Tac Toe (TTT) sind die Regeln simpel, so dass man sich auf die verteilte Implementation konzentrieren kann.

Zwei Spieler spielen gegeneinander auf einem TTT-Brett. Jeder sitzt an seinem PC und sieht den gemeinsamen Spielstand.

Datenmodell:

• Spielfeld mit 3x3 Spielfeldern in den Zuständen O, X und leer. Zusätzlich sollte das Spielfeld noch einen Spielzustand haben wie Spiel begonnen, Spiel beendet, Gewinner ist Spieler 1, Gewinner ist Spieler 2.

Featureliste:

• Ein Spieler bietet sich zum Spiel an.
• Ein Spieler nimmt Kontakt mit einem anderen auf und sie beginnen eine Partie.
• Spieler machen Züge.
• Ob und welcher Spieler gewinnt, wird automatisch festgestellt.
• Ein Spieler beendet eine Partie vorzeitig.

Dies ist während des Spiels natürlich ein Peer-to-Peer-Szenario. Ob intern die Rollen aber auch gleich sind oder nicht vielleicht doch ein Spieler ein Partienserver ist, hängt von der Implementation ab.

Herausforderungen:

• Wie nehmen die Spieler Kontakt miteinander auf?
• Wo wird der Partienzustand gehalten?
• Wie erfahren die Spieler über den nächsten Zug?
• Wie wird den Spielern das Spielende mitgeteilt?

Szenario 4: Starbucks

Gregor Hohpe hat in einem Blogbeitrag deutlich gemacht, wie wenig praktikabel die bisher so beliebten 2-Phase-Commit-Transaktionen in der realen Welt, d.h. in asynchronen (und verteilten) Szenarien sind. MassTransit und Rhino Service Bus haben das aufgenommen und versucht, mit ihren Mitteln das Szenario abzubilden. Es ist einfach eine schöne Fingerübung für jeden, der in die verteilte und asynchrone Programmierung einsteigen will.

Bei Starbucks kommen Kunde, Kassierer und Barista zusammen. Der Kunde bestellt ein Getränk, der Kassierer nennt den Preis und nimmt das Geld entgegen. Währenddessen bereitet der Barista schon das Getränk zu und serviert es, wenn die Zahlung geklappt hat.

Datenmodell:

• Bestellung(Getränkeart, Bechergröße, Menge)
• Zahlungsaufforderung(Gesamtpreis einer Bestellung)
• Bezahlung(Betrag, Zahlmittel) - Zahlmittel könnten Barzahlung oder Kreditkarte sein

Featureliste:

• Kunde bestellt ein Getränk beim Kassierer. Variation: Kunde bestellt mehrere und verschiedene Getränke beim Kassierer.
• Kassierer nennt den Gesamtpreis
• Kunden bezahlt
• Kassierer nimmt Bezahlung entgegen und prüft den Betrag. Wenn ok, dann schließt er die Bestellung ab.
• Barista bereitet bestellte Getränke vor.
• Wenn Bezahlung abgeschlossen, stellt der Barista die Getränke zur Abholung bereit.

Der Kunde kann hier als interaktiver Client realisiert werden. Kassierer und Barista hingegen sind automatische Dienste. Um die reale Welt nachzustellen, können ihre Funktionen über Pausen (Thread.Sleep()) eine wahrnehmbare Dauer bekommen.

Herausforderungen:

• Wie nehmen die Beteiligten Kontakt miteinander auf?
• Wie wird der Dialog zwischen Kunde und Kassierer geführt?
• Wie erfährt der Kunde über das fertiggestellte Getränk?
• Was passiert mit einem schon zubereiteten Getränk, wenn die Zahlung nicht erfolgreich ist?

Szenario 5: Arbeitsteilung

Das MSDN Magazine Juni/2009 beschreibt in "A Peer-To-Peer Work Processing App With WCF" ein Szenario, dass sich auch zur Übung zu realisieren lohnt. Mehrere sog. Worker stehen da bereit, um Aufträge von sog. Usern anzunehmen. Der Artikel nutzt zur Arbeitsverteilung das P2P-Protokoll von WCF - aber man kann es auch anders machen.

Datenmodell:

• Arbeitsauftrag(Id, Dauer)

Featureliste:

• User vergeben Aufträge in einen Pool von Workern hinein.
• Worker übernehmen einen oder mehrere Arbeitsaufträge.
• Worker können dem Pool beitreten oder ihn verlassen.
• Ob ein Worker Aufträge annimmt hängt von seiner Last ab. Die gesamte Auftragslast soll natürlich möglichst gleichmäßig auf die Worker verteilt werden.
• Wie die Arbeit "so läuft" können sog. Spectators beobachten; sie dienen der Instrumentierung des Systems.

In dieser Featureliste fehlen einige Aspekte, die der Artikel beschreibt, z.B. "Work Item Backup" oder "Work Sharing". Ich habe sie nicht aufgenommen, weil sie mir abhängig scheinen vom gewählten Lösungsweg (hier: P2P-Kommunikation). Meine Szenarien sollen aber keine Lösungswege oder Technologien nahelegen (z.B. Einsatz eines Busses oder Sagas oder P2P-Kommunikation).

Die schlanken Aufträge habe ich ebenfalls deshalb übernommen. Es geht ja nicht um eine konkrete Problemdomäne. So müssen die Aufträge nur eine Dauer haben, um Lastverteilung beobachten zu können.

Herausforderungen:

• Wie wird die Auftragslast möglichst gleichmäßig (oder "gerecht") auf die Worker verteilt?
• Wie werden weitere Worker möglichst unmittelbar in die Auftragsbearbeitung einbezogen? Oder allgemeiner: Wie kann der Worker-Pool "atmen"?
• Wie werden User über Auftragsergebnisse (oder gar Fortschritte) informiert?
• Wie kann ein Spectator die Arbeit(sverteilung) beobachten?
• Müssen Aufträge nach Vergabe noch "gesichert" werden können, falls Worker noch nicht zu ihrer Verarbeitung gekommen sind?
• Wie können die Worker möglichst ortsunabhängig verfügbar gemacht werden?

School of .NET - Stakeholderverträgliches Lernen

Stefan Lieser hat ihn nun entworfen: einen Rahmen für neues Präsenzlernen. In 3 Blogeinträgen haben wir laut (oder besser: sichtbar und öffentlich) darüber nachgedacht, wie Lernen in Zeiten von Web 2.0 und einer wieder mal geplatzten Wunschblase aussehen könnte. Das übliche Kochrezept - nimm ein Thema, biete 2, 3, 4, 5 Tage Kurs an, fertig - schien uns nicht mehr so unzweifelhaft zeitgemäß. Es setzt einfach den Willen voraus, bei knapper Personaldecke wie heute üblich auf Entwickler über längere Zeit zu verzichten. Die Kompaktheit des Lernen mag zwar auch ihre Vorteile haben - doch die wahrzunehmen fühlen sich nicht alle, die es wollen, in der Lage. Also liegt der Gedanke nahe, Lernen mehr an die Bedürfnisse der Lernenden anzupassen.

Aufbauend auf dem Rahmen von Stefan konkretisiere ich deshalb mal eine School of .NET:

• Semesterlänge: 3 Monate
• 1 Tag Unterricht pro Woche
• Semesterbeginn mit einer Blockveranstaltung von 2 Tagen zur Gruppenbildung - genannt Semester.Ctor ;-)
• Semesterende mit einer Blockveranstaltung als intensiver Abschluss mit Retrospektive - genannt ~Semester oder Semester.Finalizer ;-)

Das sind dann zusammen 14 Unterrichtstage mit 11 Wochen zwischen den 12 Terminen. Zu den Präsenztagen kommen also noch ausgedehnte Gelegenheiten für Hausaufgaben. Die finde ich so wichtig wie Stefan, denn damit kann sich das Wissen setzen, das man in den Präsenztagen erwirbt. Im normalen Blockunterricht wird zuviel gestopft - und die Fragen kommen erst hinterher, wenn alle wieder auseinandergelaufen sind.

Wird der Unterricht aber über 3 Monate verteilt, kann das neue Wissen schrittweise schon in die Praxis überführt werden und wirft Fragen auf, die gleich am nächsten Unterrichtstag gestellt und diskutiert werden können. Die School of .NET ist damit viel praxisnäher als jedes übliche Training. Sie bietet sogar quasi während des Semesters Zugriff auf Consultants (die "Lehrer"), denn die "Schüler" können ja jederzeit Problemstellungen aus ihren Betrieben mitbringen.

Die Hausaufgaben involvieren die Teilnehmer auch viel mehr als jede Übung, die innerhalb des Unterrichts gemacht wird. Dann sind die nämlich auf sich allein gestellt. Insofern ist jedes berufsbegleitende Lernen letztlich tiefergehend als ein Blockunterricht.

Aber nicht nur für die Teilnehmer hat die School of .NET Vorteile. Auch Kunde und vor allem Chef können nur davon profitieren. Als Stakeholder wollen sie ja eigentlich beides: einen kompetenten Entwickler, der schon alles kann, und einen, der morgen auch noch mehr kann, also ständig lernt. Berufsbegleitend ist das möglich. 1 Tag in der Woche lernen die Entwickler und 4 bringen sie ihre Kompetenz im Projekt ein. Sie werden schlauer ohne störend lange abwesend zu sein. Zudem können sie - wie oben schon erwähnt - in den Unterricht Probleme aus dem Projekt einbringen. Auch der Unterricht bringt ihnen also etwas für das Projekt und sie lernen von anderen etwas über deren tägliche Probleme.

Lernt der Entwickler was, freut sich der Stakeholder ;-)

Ja, ich denke, ein solches Lernangebot werden Stefan und ich mal schneidern: School of .NET oder kurz SoN. Und dann bieten wir das in Hamburg und Köln mit regionalem Einzugsgebiet an. Da kann dann keiner, der lernwillig ist, mehr Nein sagen ;-) Der Unterrichtsort ist erreichbar und der Unterricht nimmt nicht zuviel Raum im Tagesgeschäft ein.

Solche Lerngelegenheit ist dann besonders interessant für alle, die um- oder aufsteigen. Dann geht es nämlich nicht darum, dass gleich morgen irgendwas gekonnt werden muss. Entwickler, die auf .NET umsteigen oder eine Brownfield-Anwendung uptodate bringen sollen, haben meist einen weiteren Zeithorizont. Da ist es klar, dass sie erstmal Erfahrung mit der Plattform sammeln müssen. Dito Neueinsteiger, die aus ihrer Erstausbildung kommen und noch nicht fit mit dem .NET Framework sind. Als Junior Programmer haben sie 1 oder 2 Jahre, um sich einzufuchsen. Da ist berufsbegleitendes Lernen ideal. Und auch wer heute fitte .NET Programmierer, aber am Markt nicht findet, der bekommt mit einer School of .NET eine Hilfestellung. Er kann sich eher auf einen "smart and getting things done" Entwickler einlassen, der noch kein .NET-Spezialist ist.

Ja, ich finde, das ist ein rundes Bild für eine School of .NET. Das machen wir, Stefan. Auch wenn das Format zu jedem Thema passt, fangen wir am besten mit .NET-Grundlagen und CCD an. Tüfeln wir mal ein Curriculum aus...

Schulbank statt “Druckbetankung” – Berufsbegleitendes Lernen gerade jetzt

Auf mein Posting mit der Frage, wie Präsenzlernen anders, attraktiver aussehen könnte, hat Stefan Lieser geantwortet – und auch laut nachgedacht. Wir stimmen also in der Analyse überein. Doch was tun? Wohin kann es gehen mit dem Lernen?

Vielleicht lohnt es, einen Begriff, den er ins Spiel gebracht hat, weiter zu verfolgen: Schule. Für Stefan ist es wichtig, Lernen effektiver zu machen durch “Mischung” und durch “Lernen durch Lehren”. Anfänger und Fortgeschrittene lernen zusammen und voneinander. Je nachdem um welche Lerninhalte es geht, sind unterschiedliche Mischungen förderlich. Geht es um Fachkompetenz, dann mögen unterschiedliche Fortschrittsgrade zusammen lernen, geht es um soziale Kompetenz, dann vielleicht unterschiedliche soziale Gruppen oder behinderte Menschen mit gesunden.

Das ist schon mal ein guter Gedanke, finde ich. Die üblichen Kurse legen ja eher Wert auf Homogenität. Und da sie meist vollgepackt sind mit Stoff, wird der Austausch nicht gefördert und auch kein Raum zum Lernen durch Lehren geboten. Dann ist das Training zwar kurz (2-3 Tage) – das freut den Chef. Aber das Ergebnis ist, naja, oft nicht nachhaltig.

Damit haben die üblichen Kurse natürlich immer noch Zweck. Aber der ist womöglich ein anderer als der intendierte. Nützlich sind sie als Impulsgeber. Oder sie helfen zu motivieren. Einen Überblick können sie auch geben. Aber viel mehr ist nicht drin. Am Ende ist der Teilnehmer schnell wieder allein. Und dann oft ratlos. Wie war das doch gleich im Kurs? Da funktionierte es doch noch…

Mit dem Clean Code Developer Camp bemühen wir uns nun schon, das ein wenig besser zu machen. Gerade bei den 2 x 5 Tagen gibt es Raum für´s Lehren durch die Teilnehmer. Und eine Pause von 1-2 Wochen zwischen den Blöcken lässt Zeit zur Reflexion. In den nächsten Block kommen die Teilnehmer dann schon gleich mit Fragen aus der Praxis. Zusätzlich gibt es ein Diskussionsforum nur für die Teilnehmer, in dem sie jederzeit Fragen stellen können. Auch nach dem Kurs. Dort können sie sicher sein, dass man sie versteht, weil die Forenmitglieder durch dieselbe Erfahrung des Camps gegangen sind.

Aber wie gesagt: 5 Tage oder noch länger hören sich für manchen wie eine Drohung an. Den “Kickstart”, den so ein kompaktes Training bietet, kann und will nicht jeder bekommen.

Woher kommt denn überhaupt das “Training en bloc”? Wer will das? Es ist so weit verbreitet, dass es wie “gottgegeben” aussieht.

Einer, der es sich wünscht, ist sicher doch der potenzielle Teilnehmer. Der sucht “Erkenntis sofort”. Am besten alles in 1-2 Tagen. Leider funktioniert das nicht mit allen Themen. Und mit dem Lernen funktioniert es eh nicht so gut. Lernen ist Veränderung. Veränderung braucht Zeit. Doch erstmal zählt der Wunsch, die Nachfrage. Wenn die da ist, dann gibt es eben auch ein Angebot dazu.

Der andere, der sich en bloc Trainings wünscht, ist allerdings auch der Anbieter. Mit einem Blockangebot ist er mit größerer Reichweite attraktiv. Für 1, 2, 3 Tage reisen Teilnehmer auch mal von weiter her an. Das Training wird also mit weniger Mühe voll.

Die Parameterwerte des üblichen Lernens sind also: Zuhören (und ein wenig Übung), Homogenität der Lerngruppe, einmaliger Blockunterricht, Überregionalität.

Wenn ich nun auf der Suche nach neuen, effektiven und attraktiven Lernformen bin, um die nötigen Veränderungen in der Softwareentwicklung in die Betriebe zu bringen, wie wäre es, einfach mal diese Parameterwerte zu negieren? Sozusagen frei nach Nietzsche: Umwertung aller Werte.

Dann würde “modernes Lernen” so aussehen:

• Viel Übung, viel selbst erarbeiten, viel selbst weitergeben – statt Zuhören;  also Aktivität statt Passivität. Das beschreibt für mich auch die Atmosphäre, von der Boas Enkler in einem Kommentar zu meinem vorherigen Posting spricht: eine Atmosphäre, “in der Fehler gemacht werden dürfen und dennoch jeder danach strebt sich zu verbessern.”
• Heterogene Lerngruppe, in der die Interaktionen zwischen den Lernenden gefördert werden. Die Lerngruppe homogenisiert sich sozusagen selbst. Das schafft Vertrauen untereinander und erweitert den Horizont. Die Herausforderung an den Unterricht ist dann natürlich, dass er für jeden etwas bietet. Niemandem soll langweilig werden, niemand soll abgehängt werden. Jeder kann in seiner Geschwindigkeit lernen. Dazu sind auch Pufferzeiten nötig, denke ich, in denen Langsamere wieder etwas aufholen können.
• Abschied vom Blockunterricht. Stattdessen findet der Unterricht in mehreren “Sitzungen” statt. Warum nicht jede Woche 1 Tag Unterricht? Damit wäre über längere Zeit auch die Forderung des CCD-Wertesystems nach 20% Fortbildungszeit erfüllt. Zwischen den Unterrichtstagen wäre dann Pause, so dass weiter mit Hausaufgaben gelernt werden könnte. So ergeben sich auch die eben erwähnten Pufferzeiten ganz natürlich. Zudem ergeben sich in diesen Pausen sicherlich Fragen aus der Praxis an den Lernstoff, so dass der Unterricht viel praxisbezogener sein kann.
• Wenn Unterricht nicht mehr in Blöcken stattfindet, ist er quasi notwendig auch nicht mehr überregional. Denn wer würde schon über z.B. 5 Wochen jeweils 1 Tag von Berlin nach Frankfurt reisen, um dort an einem Kurs teilzunehmen? Wochenweises Lernen wäre also regional. Das hätte auch den Vorteil, dass sich im Unterricht Menschen treffen, die auch anschließend noch einen Kontakt halten könnten (z.B. durch Begegnungen in User Groups oder bei “Alumni-Veranstaltungen”).

Hm… irgendwie finde ich diese Vision charmant. Schulbank drücken statt “Druckbetankung”. Berufsbegleitendes Lernen. Jede Woche ein Lernhäppchen. Ich glaube, das hätte für alle Beteiligten Vorteile.

Lernpräsenz in Zeiten der Krise – aber wie?

Na, schön, wenn alle von der Krise reden, dann frage ich mal, wie denn in Zeiten derselben gelernt werden soll? Oder ist Lernen in der Krise gar kein Thema. Ja, so mag es scheinen. Die Ausbildungsetats vieler Firmen sind dieser Tage sehr, sehr klein geworden. Das ist natürlich komplett kontraproduktiv. Genauso wie Entlassungen.

Die Krise kommt, die Leute gehen, das Wissen bleibt stehen. Hinterher ist man dann dümmer als Unternehmen.

Aber schon recht, so ganz ignorieren kann man die Krise auch nicht. Wie könnte also beides überein gebracht werden: das Arbeiten und das Lernen. Insbesondere, wenn es viel zu tun gibt beim Lernen.

Das Clean Code Developer (www.clean-code-developer.de) Wertesystem mit seinen Bausteinen ist da ein Modellfall, würde ich sagen. Da gibt es eine ganze Menge zu lernen. Nicht nur Technologie, wie es die meisten gewohnt sind, sondern vor allem neue Gewohnheiten, neues Denken stehen bei CCD auf dem Programm.

Eine erste Hilfestellung geben die Grade. Sie teilen die Bausteine in Häppchen ein, die man als Lernpillen besser schlucken kann. Wenn man dann aber mehr will, was dann? Wenn man schneller mit CCD starten will, was dann? Denn der selbstgeführte Weg durch die Bausteine – gerade wenn man ihn allein gehen will oder muss – ist steinig. Bau-steinig sozusagen ;-) Ob man WCF oder einen O/R Mapper richtig einsetzt, dazu bekommt man beim autodidaktischen Lernen recht gut Feedback von der Anwendung. Die funktioniert oder nicht, die ist schnell genug oder nicht.

Bei CCD ist es aber anders. Das Feedback ist nicht so klar. Der Code gibt nur schlecht Auskunft darüber, ob er änderbar ist. Metriken könnten befragt werden – aber die sind oft recht pauschal. Am Ende kann eigentlich nur Erfahrung Feedback geben. Für die braucht es aber entweder viel Zeit, um sie selbst zu gewinnen – oder einen Partner.

Insofern liegt die Frage nahe, wie es mit einer CCD-Ausbildung aussieht. Kann man schneller zu CCD-Erfahrung und neuen CCD-Gewohnheiten kommen, mit Hilfe von außen. Klar. Das CCD Camp beweist es. Das Feedback der Teilnehmer war und ist immer noch einhellig positiv.

Allerdings: Einige Projekte der Teilnehmer begleite ich und sehe, wie schwer es ist, selbst das, was man im Verlauf von 2 x 5 Tagen gelernt hat, unter Projektdruck einzusetzen. Der Druck presst es schnell raus aus dem Projekt und die Einschätzungen in Bezug auf die angemessene Anwendung der Bausteine ist noch nicht sicher.

So frage ich mich denn, wie kann Lernen noch effektiver sein? Lernen in Präsenz anderer, also nicht rein online, durch Buch und autodidaktisch, ist schon eine gute und wichtige Sache. Die Krise macht Chefs demgegenüber aber sehr sensibel. Solche Lernen in Präsenz führt dazu, dass Mitarbeiter nicht am Arbeitsplatz sind. 2 x 5 Tage scheinen da schnell zuviel. Und das verstehe ich durchaus auch.

Ich meine allerdings, dass die Lösung nicht lauten sollte, auf Lernen in Präsenz zu verzichten. Die Herausforderung muss vielmehr darin liegen, es geeignet aufzubereiten. Erfolge stellen sich nur beim Präsenzlernen wirklich schnell ein. Herausforderung 1: Sie müssen dann nur noch nachhaltiger gemacht werden. Herausforderung 2: Sie müssen in diesen Zeiten ohne massive Abwesenheit vom Arbeitsplatz erreichbar sein. Aber wie?

Inhouse Schulungen halte ich für keine Lösung. Sie holen den Mitarbeiter auch vom Arbeitsplatz weg – aber nicht richtig. Da kann keine wirklich fokussierte Lernatmosphäre entstehen. Die meisten sind mit einem Ohr immer am Telefon.  Außerdem lernt man da nur mit den Kollegen. Der Blick über den Tellerrand ist gering und eingefahrene Verhältnisse behindern womöglich zusätzlich.

Also: Wie denn aber sonst? Ich bin überzeugt, dass es nötig und möglich ist, Lernen in Präsenz besser und attraktiver zu machen. Auch und gerade für all die, die sich in der Krise fühlen.