Loseblattsammlung

Ein Welle der Empörung überschwemmte Dan North in der letzten Woche. Sein Post: ‘Programmieren ist kein Handwerk’ (http://dannorth.net/2011/01/11/programming-is-not-a-craft/) entzündete eine breite Diskussion. Im Normalfall würden ein paar hundert Menschen seinen Blog lesen, dieses Mal seien es 20000 innerhalb weniger Tage gewesen. Nach 4 Tagen hatte der Post 150 Kommentare. Worum geht es?

Dan North schreibt Programmieren sei kein Handwerk (craft) sondern ein Beruf (trade). Wenn meine schwachen Englischkenntnisse und meine kurzen Recherchen mich nicht trügen, dann zielt der Begriff ‘craft’ in die Richtung Handwerk, Kunsthandwerk, Ehre des Handwerks (Arbeitsethos), während ‘trade’ mit Geschäft, Gewerbe, Handel verwandt ist. Der Gegensatz, auf den Dan North zielt wird vielleicht am deutlichsten in folgender Passage: “… I want an expert programmer enabling my business. What I don’t want, however, is a prima donna plumber who insists on talking about the elegance …” Dan North zielt auf einen latent in der agilen Softwareentwicklung verhandelten Gegensatz. Ist qualitativ gute Software essentiell für die agile Softwareentwicklung? Ist sie Selbstzweck? Ist sie Mittel zum Zweck?

Der Anlass für Dan North Bemerkung ist das Manifesto for Software Craftmanship (http://manifesto.softwarecraftsmanship.org/). Das Manifest lehnt seine Form an das Agile Manifest an. Es versucht die Qualität der Software stärker ins Zentrum der Bemühung von Programmierern zu rücken. Dan North hat es nicht unterzeichnet, wenn man seinen Post liest, weiss man auch warum.

Ich möchte nicht zu der Debatte Stellung beziehen, sondern zwei Gedanken äußern, die mir schon seit längeren durch den Kopf gehen. Der erste Gedanke hat unmittelbar mit dem Begriff Handwerk zu tun. (Handwerk in dem emphatischen Sinne, den craft meint.) Meine eigene Erfahrung ist, dass sich TDD nicht wie die Anwendung einer beliebigen Praktik erlernen lässt. TDD (also Test-First-Programming) erfordert eine längere Phase der Übung und diese Phase ist anstrengend. Erst nach einem disziplinierten mehrmonatigen Sich-selbst-immer-wieder-dazu-zwingen stellt sich so etwas wie eine Vertrautheit ein. Wenn die Umerziehungsphase zu kurz ist, fällt man wieder in die alten Praktiken zurück. Als Bild habe ich einen Berg vor Augen. Wenn man erst einmal den Gipfel überschritten hat, ist der Weg zurück ebenso verbaut. Nachdem ich mich daran gewöhnt hatte praktisch jeden, nicht völlig trivialen Code mit Tests einzubetten, war es ein komisches Gefühl in bestimmten Kontexten darauf zu verzichten. Ähnlich stelle ich mir auch den Lernprozess in einem klassischen Handwerk vor. Der Lehrling begleitet den Gesellen ein paar Jahre lang, schaut ab, macht mit, handelt selbst, wird korrigiert und irgendwann ist es ihm ‘in Fleisch und Blut’ übergegangen. Die Theorie dazu, das Warum, spielt dabei kaum eine Rolle. Das ‘Immer und immer wieder’ steht im Mittelpunkt. Deshalb mag ich Handwerk/Craft als Begriff, es drückt diese wichtige Erfaghrung aus.

Aber – ohne dieses Aber wäre das hier ja doch ein Plädoyer für eine Seite – aber, ein Gedanke, den ich bei Kent Beck gelesen habe, hat mich nicht mehr in Ruhe gelassen, ohne dass ich ihn schon umsetzen, anwenden ohne nur richtig einordnen könnte. Leider habe ich ‘auf die Schnelle’ keine Referenz gefunden. In der gemeinten Passage beschreibt Kent Beck, wie schwer es ihm falle Quick-and-Dirty zu programmieren. Aber, so geht der Gedanke weiter, es sei eben Verschwendung, wenn wir jedes Codestück mit einer Superqualität auslieferten. Es ginge vielmehr darum, schnell etwas auszuliefern, um mit diesem Experiment zu sehen, was geht und was nicht, was angenommen wird und was nicht. Und anhand der Ergebnisse aus diesem Experiment kann man sagen, ob überhaupt weiter programmiert werden müsse und in welche Richtung das gehen solle. Die Zweige, die sich dann als entwicklungsfähig herausstellten, seien mit aller gebotenen handwerklichen Qualität zu verfertigen, aber eben auch nur genau die. Ich finde diesen Gedanken sehr gut. Er ist aber schwer zu verwirklichen. Ich spüre einen Unbill sobald ich etwas ‘nur mal so dahinrotze’. Ein schlechtes Gewissen macht sich breit. Die Gefühle aus dem TDD-Umerziehungslager rumoren im Bauch. Softwarequalität als Selbstzweck lässt sich viel einfacher zum Maßstab machen. (Wohlgemerkt: zum Maßstab, was noch nicht verwirklichen heisst.) Wenn ich das ganze Kontinuum von Quick-and-Dirty bis vollständig-getestet-wohldesigned-stabil ausreizen wollte, müsste ich den Kontext stärker in Rechnung stellen, die Feedbackschleifen müssten kürzer, effektiver und bewußter werden. Es ginge darum Experiment zu formulieren und duchzuführen.

Mit meinen zwei Gedanken finde ich mich auf beiden Seiten des Gegensatzes wieder. Das Handwerk ist mir wichtig, weil es die Essenz des Programmierenlernens bedeutet. Die Rückkoppelung des Kunden ist mir wichtig, weil sie allein der Qualität als Maß dienen kann.

Ich hatte das Glück auf den XPDays in Hamburg einen Vortrag halten zu dürfen. Mein Thema war: ‘das agile Ich’. Kürzer als ich es je könnte hat Holger Koschek den Inhalt des Vortrages in seinem Blog zusammengefasst:

http://blog.holisticon.de/2010/11/xp-days-germany-2010/

Vor ein paar Jahren prägte Neal Ford den Ausdruck ‘Polyglottes Programmieren’. Er bezeichnete damit den Umstand, dass wir als Programmierer immer mehr genötigt sind mehrere Programmiersprachen gleichzeitig zu benutzen. Das klassische Beispiel ist eine Webanwendung. In der Datenbank sprechen wir SQL, die Applikationslogik ist vielleicht in Java implementiert und auf der Clientseite im Browser kommt JavaScript zum Einsatz. Um die Webseite zu strukturieren und darzustellen müssen wir uns in den Beschreibungssprachen HTML und CSS ausdrücken. Also mindestens 5 Sprachen um ein Datum aus der Datenbank im Browser anzuzeigen. Bei Neal Ford ist der Ausdruck durchaus nicht negativ gemeint. Er drückt das Aufatmen eines neugierigen Programmierers nach Jahren der Monokultur aus.

In meinem letzten Projekt habe ich eine interessante Erfahrung gemacht. Es handelt sich bei der Applikation um eine RubyOnRails-Anwendung. Die Datenbank ist eine MongoDB. Die Datenbank spricht also JavaScript und die Daten sind im JSON-Format abgelegt. Ein Teil der Logik unserer Applikation ist clientseitig im Browser implementiert. Es ist ein sehr geschmeidiger Prozess, die Objekte aus der Datenbank zu lesen und beim erzeugen der Webseite nur ‘to_json’ zu sagen, um die JSON-Objekte der Datenbank im JavaScript des Browsers als JavaScript-Objekte zur Verfügung zu haben. Veränderungen der Struktur der Objekte in der Datenbank wandern ohne Übersetzung, Transformation auf die Browserseite: Browser und Datenbank sprechen die gleiche Sprache.

Im Augenblick testen wir node.js (serverseitiges Javascript mit asynchronem IO) als Programmiersprache für Webanwendungen. express ist eine Framework für node.js, das die Funktionen eines einfachen Webframeworks (Rubys Sinatra war Vorbild) implementiert. Mit der Kombination MongoDB, node.js/express, Browser sprechen alle Komponenten der Applikation die gleiche Sprache. Die Datenbank spricht JavaScript und hält ihre Daten in JSON genau so wie auch die Applikationsschicht und der Browser.

Man ist versucht den Ausdruck ‘Monoglottes Programmieren’ zu prägen, aber da ist ein Beigeschmack. Das ‘Monoglotte’ ist nicht die Rückkehr zur alten Monokultur. Die Freude des ‘Polyglotten’ lebt im ‘Monoglotten’ fort. Vielleicht ist das so, weil die Technik so neu ist. Vielleicht ist es auch so, weil sich unter der gleichen Programmiersprache neue Paradigmen in die Programmierung mischen. Die Datenbank folgt jetzt nicht mehr dem relationalen Paradigma, sondern ist NoSQL (no = not only?). Das – NoSQL – ist noch kaum verstanden und die Diskussion um die Bedeutung für die Modellierung beginnt erst. Die Applikation arbeitet nicht multithreaded, sondern mit asynchronem IO: Ein Prozess im Loop und eine Programmierung mit vielen Callback-Routinen, die auf Events reagieren. Wenn NoSQL neu sein sollte, ist node.js noch ganz heiss.

Die Freude am Neuen, die der Ausdruck ‘Polyglottes Programmieren’ anzeigte, lebt im ‘Monoglotten Programmieren’ fort, weil es eigentlich ein ‘Polyparadigmatisches Programmieren’ ist. Aber wer wollte das noch sagen und dabei das Gefühl von Freude haben?

Die XPDays 2009 haben mich sehr beeindruckt. Eine Erkenntnis macht sich seitdem bei mir breit. Andreas Boes beschrieb sie in seinem Vortrag theoretisch, die anwesenden Kollegen von SAP aus praktischer Sicht. In einen Satz gebracht könnte man sagen: Mit der Verbindung von agilen Praktiken als Managementmethode im Operativen und Lean-Management im Großen setzt sich im Bereich der Softwareentwicklung eine Prozessrevolution durch, die in ihrer Bedeutung mit der industriellen Revolution vergleichbar ist. Andreas Boes sprach bei der Durchsetzung der Leanpraktiken im Management von einer zweiten industriellen Revolution. Die Kollegen von SAP sprachen davon, dass durch Leanmanagement – durch entsprechende makroskopische Steuerung und Kennzahlen – erst das wirkliche Potential von agilen Praktiken in ihrer Firma zur Geltung gebracht werde.

Wenn dem so ist, wenn wir als agile Praktiker eines der Herzstücke eines neuen Produktionsparadigmas ins Werk setzen, dann müssen wir auch darüber nachdenken, wie sich dieses Gefüge Produktionskultur insgesamt verändert und was für eine Verantwortung wird dabei haben.

Was ich damit meine, will ich am Beispiel einer kleinen Geschichte, einer wahren Begebenheit, erläutern. In den 90er Jahre gab es eine linke Fraktion der KIF (Konferenz der Informatik-Fachschaften) die JOINT (Jährliche Oldenburger Informatik-Tage) zu der ich mich zählte. Wir haben uns drei oder viermal an einem Wochenende versammelt, um über die Themen zu debattieren, die aus unserer Sicht auf der KIF zu kurz kamen. Zu einem dieser Treffen hatte sich ein Betriebsrat eines großen deutschen Elektronik- und Softwareherstellers, der im Raum einer süddeutschen Großstadt ein großes Werk betreibt – nennen wir den Hersteller Sienix -, eingeladen. Für uns war es sehr spannend zu hören, was sich in so einem großen Konzern tut. Sienix hatte begonnen die inneren Prozesse zu restrukturieren und dabei an die Stelle von großen Fachabteilungen kleine Crossfunctional-Teams gesetzt, die untereinander marktförmig verbunden waren und auch nach außen selbständig am Markt agierten. Was der Betriebsrat in diesem neuen Konstrukt feststellte waren vor allem zwei Dinge. Erstens: in einem Geflecht von selbständig miteinander interagierenden kleinen Einheiten hat ein Betriebsrat keinen Platz mehr. Historisch ist der Betriebsrat als Teil der Kommando- und Kontrollpyramide eines Unternehmenes entstanden. Er ist das interessenvertretende Gegenüber der operativen Unternehmensleitung. Wenn es dieses Gegenüber nicht mehr gibt, dann verliert auch der Betriebsrat seinen Sinn, bzw. seine Art des Handelns funktioniert nicht mehr. Zweitens: die Mitarbeitenden bei Sienix – in der Regel Akademiker – entwickelten intrinsische Motivation an ihrer Arbeit. (Zur Erklärung: Intrinsische Motivation ist die Motivation, die aus der Sache selbst erwächst, den Gegensatz dazu bildet extrinsische Motivation. Wenn ich durch Gehalt und Freizeitausgleich motiviert werde etwas zu tun, was mir keinen Spass macht, handelt es sich um extrinsische Motivation.) Diese intrinsische Motivation führte dazu, dass ein ganzes Regelsystem extrinsischer Motivation, welches die innerbetrieblichen Prozesse regelte, ad absurdum geführt wurde und sich als dysfunktional unter den neuen Bedingungen erwies. Was das heisst lässt sich am Beispiel der Überstundenregelungen erklären. In deutschen Unternehmen, zumindest in größeren, müssen Überstunden durch den Betriebsrat genehmigt werden. Das ist eines der zentralen Druckmittel, mit denen der Betriebsrat seine Forderungen durchsetzen kann. Wenn nun aber Mitarbeitende mit ihrer Abteilung eigenständig am Markt agieren und ein eigenes Interesse entwickeln ihre Arbeit zu einem bestimmten Zeitpunkt fertig zu haben, dann greifen Verbote oder Erlaubnisse von Überstunden nicht mehr. Bei Sienix hatte das dazu geführt, dass Mitarbeitende am Wochenende die Zäune der Firma überstiegen um unerkannt an ihren Arbeitsplatz zu gelangen.

Was bedeutet das alles für uns, für die agile Bewegung? Wenn es so ist, dass sich agiles Arbeiten als zentraler Bestandteil eines neuen Produktionsparadigmas durchsetzt und wenn es so ist, dass dieses neue Paradigma die zentralen Mechanismen verändert, mit denen der soziale Organismus Betrieb bisher interpretiert und gesteuert wurde, dann tragen wir auch eine Verantwortung, über die Konsequenzen unseres Handelns in einem umfassenderen Sinne nachzudenken als wir das bisher tun. Die Zeit der Unschuld ist vorbei! Der Sozialraum Betrieb hat in den letzten 150 Jahren umkämpfte Interpretationen erfahren. Diese Interpretationen sind immer temporär, sie drücken sich aus in den Regelungen und Institutionen, die die verschiedenen Interessen artikulieren und schützen. So sind z.B. die Betriebsräte und ihr Handeln Versuche die Interessen derjenigen im Betrieb zum Ausdruck zu bringen, die nicht qua Position oder Eigentum das Sagen haben. So sind viele soziale Regelungen, die uns oftmals als sperrig erscheinen, gesetzlicher Ausdruck der Interessen der strukturell Schwachen: Überstundenregelungen, Pausenregelungen, Auflagen für die räumliche Bedingungen, innerbetriebliche Genehmigungsverfahren.

Wenn Agilität und Leanmanagement zumindest partiell Command- and Controlmanagement durch Selbstorganisation und extrinsische durch intrinsische Motivation ersetzen, dann hebeln sie viele gewachsene Mechanismen aus, die in den neuen Strukturen nicht mehr funktionieren. Wenn dem so ist, müssen wir darüber nachdenken, was dann an die Stelle der alten Mechanismen tritt, wie wir den Sozialraum Betrieb gestalten wollen.

Es gibt diesen einen Test. Diesen Test, der die Story – genauer: das Szenario – in die Sprache der Applikation übersetzt. Und ich suche nach einem Namen. Wenn die Story mit den Szenarien die Akzeptanzkriterien ausdrückt. Und wenn ein Akzeptanztest diese Kriterien in die Sprache der Applikation übersetzen, dann handelt es sich bei diesem einen Test, um den der den Akzeptanztest als Unittest implementiert.
Akzeptanztests können auf ganz unterschiedliche Weise implementiert sein. Es mag sich um Test mit Hilfe eines Akzeptanztest-Frameworks handeln, wie bspw. Fitness, Fit oder Cucumber. Es mag sich um einen Test handeln, der über das Userinterface auf die Anwendung zugreift, wie bspw. Seleniumtests die Webschnittstelle adressieren. Oder es kann sich um Akzeptanztests handeln, die ein Unittestframework nutzen um ausgedrückt zu werden. In jedem dieser Fälle ist es wichtig, dass der Test die gesamte Anwendung testet, dass der Test anzeigt, ob die Funktionalität in der angezielten Weise implementiert ist oder nicht.
Unittest übernehmen eine andere Aufgabe. Sie zeigen auf, dass diese Klasse oder diese Gruppe von eng kollaborierenden Klassen eine bestimmte Funktion erfüllt. Um den gleichen Umfang wie der Akzeptanztest abzudecken, ist eine ganze Kette von Unittests notwendig. Und unter diesen ist der oberste, derjenige der die Story in die Sprache der Applikation (eben auch in die Programmiersprache) übersetzt, der erste unter gleichen – primus inter pares.
Wenn die Akzeptanztests in der Sprache der Anwendung geschrieben sind, ist der Unittest in gewissem Sinne mit dem Akzeptanztest identisch. Sein Setup ist ein anderes, er legt Wert darauf die Funktionalität an einer Klasse in Isolation zu testen, aber die Schnittstelle, die er benutzt, sollte die gleiche sein. [Wenn das nicht so ist, weil die Story bspw. gar keinen spezifischen Ort in der Applikation hat, ließe sich von einem Code Smell sprechen. Aber das - der Ort einer Story in der Applikation (UseCaseController, Manager, anämisches Objektmodell) - ist Thema für eine andere Gelegenheit.]
Die Rolle des Ersten unter den Unittests ist in unserem Coding-Dojo aufgetaucht. Immer wenn wir diesen Test nicht hatten, verloren sich Entwicklungen in tieferen Schichten der Applikation im Spekulativen, wenn er da war, gab er den anderen eine Richtung vor. Wir haben das zunächst als Primat des Top-Down-Ansatzes verhandelt. Erst mit dem Gedanken des Top-Down-Ansatzes wurde im Dojo explizit, dass es sich besser anfühlt, wenn man die Frage beantwortet hat, welches ist die zentrale Einstiegsfunktion für die Story und wie sehen die Tests für diesen Einstiegspunkt aus. Aber – und deshalb wiederstrebt es mir hier von einem Top-Down-Ansatz zu sprechen – wenn der oberste Unittest erst einmal gefunden ist, ist es auch möglich in unteren Schichten der Applikation zu beginnen, ohne sich zu verlieren. Der oberste Unittest gibt der Implementierung eine Richtung, auch wenn diese syntaktische und programmatisch noch nicht in allen Ebenen und Schichten explizit ist. In einer anderen Sprache und einem anderen Land könnte man vielleicht von Führung und einem führenden Test sprechen, aber bei uns?

Es gibt Beispiele, die sind komplizierter als das, was sie illustrieren sollen. Aber irgendwie – und dieses irgendwie muss man groß schreiben – IRGENDWIE veranschaulichen sie einen Aspekt so überdeutlich, dass sie doch wichtig sind.
So geht es mir mit der Frage des Übergangs. Ich habe einmal in einer Veranstaltung gesessen, ich weiß heute nicht mehr wie ich dahin kam, in der es um die Entstehung der 12-Ton-Musik ausgehend vom späten Bruckner ging. Ich verstehe eigentlich nichts von Musik, ich kann mit der 12-Ton Musik Schönbergs, wenn ich sie höre, nichts anfangen, und ich kenne kein einziges Werk des späten Bruckner mit Namen, aber die Veranstaltung beschrieb ein Muster so plastisch und anschaulich, dass ich fasziniert war.
Musikstücke – jetzt sollte jeder Nichtlaie weghören – haben eine Tonart. Ich kann mir das am einfachsten am Klavier vorstellen. Die 8 weißen Tasten angefangen beim C bilden die Grundtöne der Tonart C-Dur. Die Abstände der Tasten beim Klavier – egal ob weiß-weiß oder weiß-schwarz – bestehen aus einem Halbton. Da nicht zwischen allen weißen Tasten eine schwarze ist, gibt es weiße Tasten, die einen halben Ton und weiße Tasten, die einen ganzen Ton auseinander liegen. Wenn ich beim C anfange und nur die weißen Tasten drücke, habe ich eine Tonleiter, die klingt. Dabei habe ich zwei Ganztonsprünge, einen Halbtonsprung, dann wieder drei Ganztonsprünge und einen Halbtonsprung. Diese Reihe (1-1-0,5-1-1-1-0,5) kann ich jetzt bei jedem Ton starten. Wenn ich z.B. beim G beginne habe ich die G-Dur-Tonleiter. Ich muss in den Tonarten entsprechend viele schwarze Tasten drücken, um auf meinen Grundtönen zu bleiben. Was bleibt sind immer die Abstände der Töne in der Grundtonleiter.
Wo war ich? Ach ja! Musikstücke haben eine Tonart. Diese ist am Anfang eines Stückes markiert. Ich lege damit fest, welche acht Tasten ich drücke darf. Wenn ich nun der Meinung bin, ich brauche mal einen anderen Ton, der jetzt eigentlich nicht erlaubt ist, kann ich diesen einzelnen Ton mit einem Vorzeichen versehen und darf außer der Reihe drücken. Der Vortrag, von dem ich erzählen wollte, beschäftigte sich mit der Musik des ausgehenden 19. und beginnenden 20. Jahrhunderts, insbesondere mit der Musik Anton Bruckners. Es hieß im Spätwerk Bruckners würde eine schwebende Tonalität herrschen. Das meinte, die Stücke hätten zwar eine Tonart – ganz am Anfang des Stücks wäre eine notiert – es gäbe aber so viele Vorzeichen an einzelnen Noten im Stück, dass diese Tonart kaum noch zu erkennen sei – eben schwebend. Bruckner hätte mit den Mitteln der klassischen Tonalität das ausgereizt, was sich komponieren liesse, wenn man den Begriff der Tonart nicht aufgeben wolle. Den nächsten Schritt, ob das musikhistorisch überhaupt Sinn macht kann ich nicht beurteilen, stellte die 12-Ton-Musik Arnold Schönbergs dar. Schönberg ‘befreite’ die Musik vom Korsett der Tonalität. Er schuf eine Musik, die alle Tasten (12) gleichberechtigt nebeneinander stellte. Damit wäre es leicht gewesen, die Musik zu notieren, die der späte Bruckner komponiert habe. Mit der Befreiung von der Tonalität entstanden ganz neue Möglichkeiten von Musik, die neue Notation eröffnete Felder, die im Kontext der alten Notation nur als Randgebiete sichtbar waren.
Mich faszinierte an dem Vortrag das Muster, welches überdeutlich wurde. Das Neue – Schönbergs 12-Ton-Musik – was keine Erfindung, mit der man dann neue Sachen machen konnte. Im Gegenteil. Das Alte, die klassische Form der Musik hatte sich an eine Stelle entwickelt, an der ihr formales Gerüst bis an ihre Grenzen belastet wurde, an eine Stelle, an der sich die Sinnhaftigkeit dieser formalen Struktur stellte. Das Neue befreite nur den schon vorhandenen neuen Inhalt aus der alten Form und ließ ihm Raum sich weiter zu entwickeln.
Ich denke dass es sich mit vielen neuen Dingen so verhält, das sie auf dem Boden des alten entstehen, dieses bis an die Grenzen des Sinnhaften beanspruchen und so den Übergang zu etwas Neuem – nicht nur vorbereiten -, sondern erzwingen.
Wer zum Beipiel den Text von Winston Royce ‘Managing the Development of Large Software Systems’ liest, der gemeinhin als Manifest des Wasserfallmodells gilt, wird finden, dass dieser Aufsatz im Gegenteil sehr viele Anmerkungen zum Wasserfallmodell macht, die in Richtung einer agilen Sofwareentwicklung weisen. Mehr Agilität geht im Modell des Wasserfalls wahrscheinlich gar nicht. (Ich habe versucht das hier auszuführen.)
Etwas ähnliches scheint sich im Moment im Bereich Scrum/Kanban zu vollziehen. Wir setzen auf der Arbeit in unseren Projekten Taskboards ein. Die genaue Gestalt variiert von Team zu Team, aber ein Taskboard haben fast alle. Wenn ich mir die Boards der Projekte anschauen, die Tagesbetrieb/Wartung und Kleinprojekte machen, dann haben die nie den Charakter eines Scrum-Taskboards. (Ein echtes Scrum-Taskboard: Am Anfang der Iteration sind alle Karten links und am Ende rechts.) In den Tagesbetriebsprojekten führt es dazu, dass die Wochenplanungen immer wichtiger werden als die Releasemeetings, sofern es sie für das ganze Projekt noch gibt. Und es führt dazu, dass das Team das Gefühl hat, etwas falsch zu machen. ‘Eigentlich muss das doch anders gehen.’ Das Werkzeug ‘Prozess’ verwandelt sich in ein Korsett. Die Stellschrauben, die Scrum einführt, greifen in diesen Projekten nicht wirklich. Das Messen der Geschwindigkeit funktioniert nicht wirklich, weil sehr viele Aufgaben als dringende während des Sprints dazukommen. Das widerspricht zwar dem Gedanken des Sprints ist aber in Wartungsprojekten unerläßlich. Natürlich gibt es Workarounds: rote Karten, die nicht mitgemessen werden oder Puffer, die von vornherein für Wartung und Bugfixing reserviert werden. Es ist aber nicht sehr befriedigend einen großen Teil der Arbeit während eines Sprints nicht in die Messung einzubeziehen.
Die Kanban-Diskussion hat den befreienden Effekt, dass sie die Diskussion in eine andere Richtung lenkt. Es heisst nicht mehr Scrum Ja oder Nein, sondern es werden Instrumente sichtbar, mit denen man einen Prozess gestalten kann, der in einem Umfeld stattfindet, das keine feste Timebox mehr erlaubt. Die Diskussion um Kanban zeigt bspw. wie man den Durchsatz messen kann, wenn es einem nicht möglich ist die Geschwindigkeit im klassischen Sinne zu messen. Mit Beschränkungen der Warteschlangengrößen wird eine Stellgröße sichtbar, die der klassische Scrumprozess nicht kannte und auch nicht brauchte, da er in einem andern Umfeld zu hause ist. Insofern habe ich dass Gefühl Kanban ist das Neue, was auf dem Boden des Alten entstanden ist. Jetzt gilt es allerdings nicht mehr die Diskussion Alt gegen Neu zu führen, sondern auszuprobieren, wie sich die Instrumente, auf die Kanban die Aufmerksamkeit lenkt, einsetzen und erweitern lassen. Die Beipiele, die ich bisher in den verbreiteten Präsentationen gesehen habe – vor allem Verklemmungen beim Deployment – haben etwas Triviales, man hat den Eindruck, hier hätte nicht Kanban, sondern etwas gesunder Menschenverstand genügt.

Die MIT-Studie über die zweite Revolution in der Automobilindustrie unterscheidet drei Weisen der Produktion. Die fordistische, amerikanische Massenproduktionsweise, die japanische Produktionsweise und die skandinavische Manufakturproduktionsweise. Da es einige Beispiele dafür gibt, Produktionsweisen am Beispiel des Eintütens von Briefen zu verdeutlichen, will ich in diesem Bild bleiben und versuchen den Unterschied der drei Weisen zu verdeutlichen.

Die Aufgabe besteht darin, 100 Briefe mit 100 DIN A4-Blättern zu füllen, die Umschläge zu zu kleben und diese mit 100 Briefmarken zu frankieren. Die erste – auch historisch erste – Form das Problem zu erledigen, die Manufakturproduktion, besteht darin, alle Briefe einzeln zu bearbeiten. Arbeiter 1 nimmt sich einen Brief, versieht ihn mit Inhalt, klebt ihn zu und frankiert ihn. Wären mehrere Arbeiter zugange, würde sie ebenfalls diese Tätigkeit ausführen. Jeder macht das gleiche. Der Arbeitsprozess zerfällt nicht in seine Bestandteile, jede Arbeitskraft vollzieht ihn ganz.

Die zweite Form das Problem zu lösen, die fordistische Produktionsweise, besteht darin, den Prozess zu zerlegen und ihn durch ein Medium wie das Fließband wieder zusammen zu setzen. Arbeiter 1 füllt die Briefe und gibt sie weiter. Arbeiter 2 klebt die Briefe zu und gibt sie weiter. Arbeiter 3 frankiert sie und legt sie auf den Stapel der fertigen Briefe. Jede Arbeitskraft vollzieht nur noch einen Teil der gesamten Arbeit. Weil die Arbeiten  unterschiedlich lange dauern, werden zwischen den unterschiedlichen Stationen Puffer aufgebaut und die Stationen werden skaliert. Es gibt drei Tütenkleber, zwei Frankierer und einen Füller. Jede Station wird optimiert. Möglichst schnell füllen, möglichst schnell frankieren und möglichst schnell kleben. Diese zweite Form der Produktion verdrängte historisch in vielen Bereichen die Manufakturproduktion und wurde als industrielle Produktionsweise bekannt.

Die Manufakturproduktionsweise wird in den Bereichen geschätzt, in denen Qualität wichtig ist. So gab es – vom MIT in der Studie untersucht – in der skandinavischen Automobilindustrie Versuche die Manufakturarbeitsweise unter industriellen Bedingungen wieder zu beleben. Man setzte bspw. ein Team auf das Fließband, ließ es an allen Stationen vorbeifahren und ein Auto als Ganzes montieren.

Die dritte Form der Produktion – die toyotistische Massenproduktion – trat historisch auf den Plan, als die zweite, Fließband, Industrie, über die erste, Manufaktur, gesiegt hatte. Wie wird hier der Brief eingetütet. Der Grundgedanke ist: Arbeitsteilung wie in der Industrie, Arbeitsfluss wie in der Manufaktur. Was meint das? Wenn ich mich kurz in einen Brief verwandle, dann fühlt sich die erste Arbeitsweise so an, dass ich in einem Fluss gefüllt, verklebt und frankiert werde. Bei der zweiten Weise werde ich gefüllt und muss warten, werde verklebt und muss warten, werde frankiert und bin fertig. Bei der toyotistischen Arbeitsweise -besser: ihrem Ideal – fühlt es sich wieder so an wie in der ersten, ich werde in einem Rutsch gefüllt, verklebt, frankiert. Und das obwohl Arbeitsteilung herrscht und die füllenden, klebenden und frankierenden Hände unterschiedliche sind. Man nennt das ‘Single Piece Flow’. Die Kunst bei der dritten Weise der Produktion ist es also die Vorteile der zweiten Weise beizubehalten, aber ihre Nachteile, Warteschlangen, Verschwendungen, die den Prozess stocken lassen, zu überwinden. Single Piece Flow ist dabei ein Maßstab um den Prozess zu verbessern. Es ist kein Ideal in sich selbst. Gemessen am Single Piece Flow werden die Verschwendungen des Prozesses sichtbar und es kann an seiner Verbesserung gearbeitet werden. Hätte das Ideal einen Wert in sich, wäre es eine mögliche Option, zur alten Weise der Produktion – zur Manufaktur - zurückzukehren, doch diese Option besteht leider (?) nicht.

Wir machen auf der Arbeit regelmäßig ein Coding-Dojo: vier Leute, drei Monate, zwei mal in der Woche anderhalb Stunden, eine Aufgabe, rotierendes Pairprogramming am Beamer. Die Frage nach der Rolle des Navigators, des Beifahrers, beim Pair Programming hat uns dabei schon öfter beschäftigt. Wir rotieren alle 5 Minuten (btw: Minuteur ist ein wuenderbares Tools um das auf dem Mac zu steuern). In der Literatur, in Vorträgen findet sich ein gängiges Muster: Der Fahrer sei zuständig für die taktischen Fragen, der Navigator für die Strategie. Den Fahrer kümmere die Syntax, den Navigator der große Plan, die Route. Obwohl diese Beschreibung sich durchgängig findet, hat das Beschriebene bei uns einfach nicht funktioniert. Das mag  verschiedene Gründe haben: falsch angewendet, unerfahren, unqualifiziert, zu wenig Disziplin, eine falsche Vorstellung davon wie es auszusehen hat.

Und nun sind wir auf zwei Studien gestoßen: Pair Programming an the Mysterious Role of the Navigator und The Social Dynamics of Pair Programming. Beide untersuchen die Frage der Kommunikation beim Pair Programming empirisch. Und beide Studien kommen zu dem Ergebnis, dass es die Rollenaufteilung in Navigator und Fahrer nicht gibt. Die Anteile beider Rollen an verschiedenen Ebenen der Betrachtung des Programms sind gleichverteilt. Es gibt keinen Unterschied in dem, was ich betrachte – und dann auch verbalisiere -, der sich aus meiner Rolle ableiten läßt. Und dass obwohl die Beteiligten selber ihre Rollen vor dem Experiment als Fahrer und Navigator beschrieben und der Meinung waren, so funktioniere ihr Pairing. Wenn die Rolle des Navigators als permanentem Code Reviewer oder als Steuermann eine Chimäre ist, was kennzeichnet denn dann das Gespräch zwischen den beiden? Die Rollen seien zumindest nicht sehr unterschiedlich, sehe man einmal vom trivialen Umstand ab, dass der eine die Tastatur hat und der andere nicht. Das Gespräch spiele sich eher auf einer Ebene von ‘abstract chunks of code’ ab. Damit seien Fragen von Namensstandards, Fragen allgemeiner Programmierstrategien, Umsetzungen von Programmstrategien im konkreten Programm gemeint. Der Bereich – so die eine Studie – der ‘abstract chunks of code’ sei der Vermittlungsbereich zwischen der Diskussion über konkrete Methode, Variablen und Syntax auf der einen und Fachdomänen bzw. der Übersetzung von Fachdomänenfragen ins Programm auf der anderen Seite. Pair Programming sei am effektivsten, wenn beide Teilnehmer ständig beide Rollen ausfüllten.

Einen wirklichen Unterschied sieht die eine Studie, wenn erfahrene mit unerfahreneren Programmierern pairen. Bei einem grossen Unterschied werde der unerfahrene Programmierer passiv. Diese Passivität führe dazu, dass er nicht mehr wirklich handle, sondern mehr zuschaue, und nicht mehr viel lerne. Pair Programming eigne sich nicht für den Wissenstransfer bei grossen Unterschieden in der Erfahrung oder Qualifikation. Die eine Studie schliesst eine Beobachtung an, die sie nicht mehr verifiziert, weil sie beendet wurde. Neu ins Team gekommene Programmierer, hätten nicht so viele Probleme die Erfahrenen zu unterbrechen, sie würden nicht so schnell passiv werden, das könne ein Indiz sein, dass bei ihnen der Transfer auch bei einem grossen Wissensunterschied noch funktioniere.

Die Lektüre der zwei Studien wirkte sich befreiend aus. Vorher hatte ich das Gefühl, unsere Betrachtungen müssten in die Richtung eigener Unzulänglichkeiten gehen, warum machen wir das noch nicht richtig. Danach würde ich sagen, die Frage, wie Pair Programming zu lehren uns zu kultivieren sei ist wieder offen oder aber schon beantwortet, weil man sich eben so verständigt, wie man sich verständigt: auf der mittleren Ebene und gleichberechtigt.

Auf der JAOO hatte ich das Glück ein Tutorial zum  Thema domänenspezifische Sprachen (Domain Spezific Language – DSL) besuchen zu können. Interessant war es, die verschiedenen Elemente des Themas einmal in einen Zusammenhang gebracht zu bekommen. Und wie immer, wenn Martin Fowler etwas darstellt, bekommt man ein paar neue Begriffe beigebracht, die es erlauben das bisher Gesehene und Gefühlte besser zu benennen und in einen systematischen Zusammenhang zu stellen.

Fluent Interfaces sind eine Form einer DSL, genauer einer internen DSL, genauer: sie sind ein syntaktisches Mittel eine interne DSL zu realisieren. Und Fluent Interfaces sind angesagt. Ich habe gesehen wie in einigen Projekten mithilfe eines Fluent Interfaces ein Bereich modelliert wurde. Mein Arbeitsfeld ist der eCommerce und so sind es oftmals Regeln, die den Checkout-(Bezahl-)Prozess steuern, die so modelliert werden. Ich kenne diese Form des Interfaces aber auch aus Konvertern, die eine Form von Daten in eine andere übersetzen. Bisher, vor dem Tutorial, hatte ich ein ungutes Gefühl, wenn ich die Beschreibung der Regeln in einem Fluent Interface sah und die Implementierung der Regeln mit der Interpretation der internen DSL verbunden war. Seitdem, seit dem Tutorial, kann ich das etwas genauer beschreiben. DSLs seien, so Fowler, dafür da ein Semantisches Modell zu instantiieren. Das Sematische Modell modelliere den Gegenstandsbereich. Es sei kein Domänenmodell, weil auch Bereiche, die nicht zur Domäne gehörten, mit einer DSL modelliert werden könnten. (Insofern sei aber jedes Domänenmodell ein Semantisches Modell.) Nehmen wir das Beispiel des Regelwerks für einen Checkoutprozess. Ich brauche ein Sematisches Modell, das meine Regeln, meine Lieferzeiten, meine Bezahlarten modelliert. Dieses Modell ist als solches testbar. Um jetzt für einen konkreten Shop ein spezifisches Regelwerk zu instantiieren, benutze ich eine DSL. Die kann ich ebenfalls separat testen. Der Test besteht darin, zu kontrollieren ob eine bestimmte Beschreibung eine bestimmte Form des Regelwerkes instantiiert. Der Test ist vollständig entkoppelt vom Test der Funktion des Regelwerks. Das entscheidende in diesem Zusammenhang ist das Sematische Modell. Es ist substantiell, dass hier der Bereich, der abgebildet werden soll, möglichst explizit modelliert ist. Ich kenne Implementierungen, die die DSL nutzen um eine sehr allgemeine Datenstruktur zu befüllen, bspw. einen Hash, und diese dann in entsprechend imperativen Code nutzen. Hier ist die DSL eher kontraproduktiv, weil sie verdeckt, dass die Domäne nicht wirklich modelliert wurde. Durch die DSL entsteht der Eindruck, es gäbe die Konstrukte, die die Domäne abbilden.

Der Sinn einer DSL lässt sich, Fowler folgend, auch so beschreiben: Anstatt das Command/Query-API des Sematischen Modells zu benutzen, wird eine Fluent Interface eingesetzt, um das Modell zu popularisieren.Das Semantische Modell stellt ein alternatives Berechnungsmodell dar – bspw. ein Regelwerk. Wird das Command/Query-API dieses Modells benutzt, ist das alternative Programm – implizit in der Instantiierung des konkreten Regelwerks enthalten – unsichtbar. Die DSL erlaubt es das alternative Programm als solches sichtbar zu machen.

(Fussnote: Wer mit einer internen DSL programmiert hat oftmals das Gefühl einem deklarativeren Programmierstil zu folgen. Das liegt nicht daran, dass DSLs per se einem deklarativeren Programmierstil folgen, sondern daran dass ein Semantisches Modell instantiiert wird, welches ein regelorientiertes Paradigma ausdrückt.)

Ein ganz kleines Beispiel: Mocha, die Ruby-Mock-Library, mit einem fiktiven Command/Query-API. Hier wird ein Mock programmiert.

# Command/Query-API
object = mock()
expectation = object.create_expectation()
expectation.set_method_name(:expected_method)
expectation.set_parameters([:p1, :p2])
expectation.set_return_value(:result)


Das Gleiche als interne DSL (mit Original-Mocha-Syntax)

# Fluent Interface
object = mock()
object.expects(:expected_method).with(:p1, :p2).returns(:result)

Im zweiten Fall ist die Programmierung des Mocks deutlich zu erkennen. Seine Programmierung nähert sich dem programmierten Methodenaufruf an. Im ersten Fall muss ich mir den zu erwartenden Methodenaufruf beim Lesen im Kopf zusammensetzen.

(Fussnote: Der Begriff Command/Query-API meint ein sinnvolles Prinzip für die Konstruktuion von Objekten. Eine Methode sollte entweder eine Query sein, das bedeutet, sie liefert einen Wert zurück und ändert den Zustand des Objektes nicht, oder ein Command, was bedeutet, dass die Methode eine Zustandveränderung des Objektes bewirkt, aber keinen Wert zurückliefert (Javasprech: void). Ein Fluent Interface gegen die Unterscheidung, weil es in der Regel den Zustand eines Objektes verändert und das Objekt zurückliefert, damit solche Methodenketten wie oben möglich werden.)