Posts
-
Wege zur Psychologischen Sicherheit
Der erste Teil dieses Artikel widmete sich der Frage was Psychologische
Sicherheit (PS) sei. (Hier ist er nachzulesen.) Er verwies auf eine Google Studie, die PS als
kritischen Faktor für Teamerfolg auswies und die Amy Edmondson mit ihrer
einschlägigen Defintion folgte: PS sei “a shared belief held by members of a
team that the team is safe for interpersonal risktaking.”
-
'What makes a team great?' - Psychologische Sicherheit!
Was macht das perfekte Team aus? Google startet im Jahre 2012 ein Projekt, um
das herauszufinden - das Projekt Aristotle. Google misst schon lange alle
Parameter seiner Projekte. Wer, wenn nicht sie, sollte in der Lage sein, die
Frage zu beantworten? Im Rahmen des Projektes werden mehr als 200 Interviews
geführt und mehr als 250 Eigenschaften von über 180 Teams untersucht? Das
Ergebnis: Psychologische Sicherheit ist der wichtigste Faktor.
-
The Weakness of Strong Ties
Persönliche Erfahrungen in den Zeiten der Pandemie.
-
Selbstorganisation und Kapitalismus
“Selbstorganisation: Ja! - Kapitalismus:
Nein??”
titelt eine Episode des Gründerplausch aus dem April 2020. Lars Vollmer und
Mark Poppenborg fragen, ob das Bekenntnis für Selbstorganisation, wenn man es
zu Ende denke, nicht auch eines für den Kapitalismus und insbesondere für den
Markt sei. Ich möchte widersprechen. Aus Empörung beim Hören wurde im Laufe
des Nachdenkens ihrer Argumente dieser Artikel. Ich versuche ihr Argument zu
rekonstruieren. Im Anschluss beschäftige ich mich genauer mit ihrem Begriff
des Marktes und mit der Kopplung gesellschaftlicher Funktionssysteme. Eine
eigene These beschließt diesen Artikel.
-
Wiederbelebung
Der letzte Eintrag in meinem Blog ist von 2014. Fünf Jahre her. Seitdem habe
ich ein paar Beiträge für unseren Firmenblog
verfasst, aber nichts mehr hier.
-
Mikrosystems vs. Mikroservices
Der Begriff Mikroservice ist IN. Nicht ohne Grund. Erfahrungen der letzen 10 Jahre, insbesondere mit großen Webanwendungen, haben dem Mikroservicegedanken den Boden bereitet. Zu große Anwendungen, zu komplizierte und seltene Deployments, unklare Verantwortlichkeiten dienen in der Diskussion als Begründung des neuen Architekturstils. Am Begriff Mikroservice haben sich einige Kontroversen entzündet. Mikroservice vs. Monolith: An die Stelle einer großen Anwendung, die als ganze deployt wird, treten viele kleine Services, die als deploybare Einheiten eine Anwendung in Fachlichkeiten dekomponieren. Mikroservice vs. Nanoservice: Wie viele Zeilen Code soll ein Service enthalten? 100? Ist die Frage sinnvoll - unabhängig von Programmiersprache und Kontext? Vielleicht ist sie nur Symptom der Frage: Wie weit kann und soll man die Mikrofizierung treiben?
-
DDD: Ports und Adapter
Vaughn Vernon bespricht in seinem Buch Implementing Domain Driven Design verschiedene Arten, wie ein System intern geschichtet werden kann. Sein favorisiertes Muster ist 'Ports und Adapter' oder - wie es an der Quelle des Ansatzes dem Artikel von Alistair Cockburn heisst - Hexagonale Architektur.
-
DDD: Die Grenzen eines Aggregats
Auf der Arbeit kultivieren wir gerade Eat'n'Read. Jeden Freitag sitzen wir zusammen, essen und lesen Implementing Domain Driven Design von Vaughn Vernon. Vernon arbeitet die Gedanken auf, die Eric Evans in Domain Driven Design entwickelt hat. Ein paar Dinge sind neu - Domain-Events - andere werden anders strukturiert, Schwerpunkte sind verschoben aber im Großen und Ganzen versucht sich Vernon am Original (?) zu orientieren. Um so interessanter ist es sich die Frage zu stellen, wo nun die Unterschiede zwischen Evans und Vernon sind.
-
Conways Law Revisited
Wenn man in einer Woche zweimal in unterschiedlichen Kontexten mit einer Sache
konfrontiert wird, ist das ein Zeichen. Wofür auch immer. So ist es mir in der
letzten Wochen mit Conways Law ergangen. Bisher kannte ich Conways Law als
das Gesetz, das besagt, dass sich über kurz oder lang die Strukturen eines
sozialen Systems in einem technischen System wiederfinden werden. Wenn ich ein
Programm schreibe, mit dem später zwei Fachabteilungen arbeiten werden, wird
sich diese Trennung auch im technischen System - dem Programm - ausdrücken.
-
Composed Method Revisited
Ich habe das erste Mal von Composed Method in dem Buch Smalltalk - Best Practice Patterns von Kent Beck (1996) gelesen. Das Buch ist eine Sammlung von Mustern für das Programmieren im Kleinen. Das Problem, das Composed Method adressiert, ist:
-
Selbstorganisation
Am letzten Freitag hatte ich das Glück am it-camp der oose teilnehmen zu können. Das Thema war Selbstorganisation. Der Referent war einer der führenden Köpfe systemischer Organisationsberatung und Therapie in Deutschland: Fritz B. Simon. Er erklärte in seinem Referat die Grundbegriffe der systemischen Organisationstheorie. Im Anschluss gab es ein Worldcafe, das sich sehr stark um alle Aspekte der Selbstorganisation von Teams dreht. Das Ende der Veranstaltung war ein Open-Space. Ich habe dort mit anderen versucht einige Verwirrungen um den Begriff der Selbstorganisation, wie er im Referat entfaltet wurde und wie er uns in den Diskussionen umtrieb, aufzulösen.
-
Software als Handwerk?
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?
-
Vortrag auf den XPDays 2010
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:
-
Monoglottes Programmieren?
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.
-
Die Zeit der Unschuld ist vorbei
Die Zeit der Unschuld ist vorbei
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 Verbidnung von agilen Praktiken als Managementmethode im Kleinen, 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 wird.
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). Dort haben wir uns drei oder viermal zu einem Wochenende versammelt, um über die Themen zu debattieren, die auf der KIF zu kurz kamen. Zu einem dieser Treffen hatte sich ein Betriebsrat eines großen deutschen Elektronik- und Softwarehersteller Herstellers, 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 diese zentrale Leitstelle 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 Veantwortung ü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 ein umkämpfte Interpretion erfahren. Diese Interpretation ist immer temporär, sie drückt sich aus in den Regelungen und Institutionen, die die verschiedenen Interessen ausdrücken 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 Genehmigunsverfahren.
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.
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.
-
Primus inter pares
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.
-
Kanban, Scrum und die Frage des Übergangs
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.
-
Leanproduction und das Eintüten eines Briefes
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.
-
Der Tod des Navigators
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.
-
Sinn und Grenzen eines Fluent Interfaces
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.
-
Platzen oder Lean & Zen
Ich habe manchmal das Gefühl, ich platze gleich, wenn ich eine Idee nicht loswerde, wenn ich nicht über etwas reden kann, was mich gerade bewegt.
Ich bin im Moment in Arhus und habe an der JAOO teilgenommen. Die ersten Tage waren so lala. Das mag an mir liegen. Ich hatte mir vor allem Talks ausgesucht, bei denen ich schon etwas von den Sprechern gelesen hatte. Ich wollte sie gerne mal live sehen und als Mensch erleben. In der Regel finde ich das sehr spannend, weil mein Bild von dem, was sie schreiben, sich präzisiert. (So ist es mir bspw. auch mit der Stimme von Stefan Tilkov gegangen, seitdem ich ihn beim heise-Developer-Podcast gehört habe, lese ich seinen Blog ganz anders.) Nun denn - ich habe die Leute jetzt gesehen, habe ein präziseres Bild von ihnen, aber was sie gesagt haben, hat micht nicht überrascht, wie auch, wenn ich vorher schon ein paar ihrer Gedanken kannte. Ich war ein wenig enttäuscht.
-
El-Oh-De revisited
Einmal im halben Jahr komme ich an Dan Mangles' Blogeintrag über Missverständniss des Gesetz von Demeter vorbei. Und meistens - das scheint eine Eigenart von mir zu sein - lese ich ihn nochmal. So auch vor ein paar Tagen. Und auch dieses Mal habe ich das Gefühl ihn bisher noch nicht richtig gelesen zu haben.
-
GIT oder die Suche nach der richtigen Abstraktion
Ich glaube von Marshall McLuhan stammt der Gedanke, dass neue Medien immer in Gestalt der alten die Welt erblicken. Sie finden ihre eigene Form erst im Laufe ihrer Entfaltung. Der Gedanke ist wahrscheinlich eine spezifische Fassung eines Allgemeineren. Das Neue tritt prinzipiell immer zuerst in Gestalt des Alten auf und wird auch in seinen Kategorien gedacht. So war das Auto zunächst eine Kutsche ohne Pferde und das Internet war ein Sammelsurium von Texten.
-
GIT und warum SVN-Merges keine Merges sind
Seit zwei Wochen arbeiten wir im Projekt wirklich mit GIT. Bisher kannte ich es nur als Tool, um Open-Source-Projekte zu bekommen, oder für Spielzeug-Repositories auf der eigenen Platte. Die wirklichen Fragen kommen erst jetzt - im realen Leben. 'Bekomme ich wirklich jedesmal alle Updates aller Branches aus dem Repository oder nur den HEAD?' 'Wie läuft denn das mergen, wenn ich gleichzeitig mehrer Branches bekomme?' Ich merke bei meinen Fragen, dass ich noch in SVN denke.
-
Kanban versus Scrum
Im März waren Arthur und ich in Hamburg bei einer Veranstaltung des ObjektForum Nord zum Thema Lean Software Development. Referent war Stefan Roock. Der Vortrag bestand aus zwei Teilen. Im ersten referierte Stefan die Thesen der Poppendieks zum Thema Lean Software Development, wie sie auch in ihren Büchern veröffentlicht sind. Im zweiten Teil beschrieb er Kanban und Kanban-Boards wie sie im Moment im Scrum-Kontext diskutiert werden.
-
Klassisches Testen von Software versus TDD
Im Januar hatte die Agile Grupppe Bremen Andreas Spillner zu Gast. Andreas hat an der Hochschule Bremen eine Professur, sein Gebiet ist das klassische Testen von Software. Er stellte beim Treffen der Agilen Gruppe vor, was das sei: Testen von Software. Die Diskussion drehte sich um die Frage, ob denn TDD klassisches Testen ersetze oder wie das Verhältnis zu bestimmen sei.
Wege zur Psychologischen Sicherheit
Der erste Teil dieses Artikel widmete sich der Frage was Psychologische Sicherheit (PS) sei. (Hier ist er nachzulesen.) Er verwies auf eine Google Studie, die PS als kritischen Faktor für Teamerfolg auswies und die Amy Edmondson mit ihrer einschlägigen Defintion folgte: PS sei “a shared belief held by members of a team that the team is safe for interpersonal risktaking.”
'What makes a team great?' - Psychologische Sicherheit!
Was macht das perfekte Team aus? Google startet im Jahre 2012 ein Projekt, um das herauszufinden - das Projekt Aristotle. Google misst schon lange alle Parameter seiner Projekte. Wer, wenn nicht sie, sollte in der Lage sein, die Frage zu beantworten? Im Rahmen des Projektes werden mehr als 200 Interviews geführt und mehr als 250 Eigenschaften von über 180 Teams untersucht? Das Ergebnis: Psychologische Sicherheit ist der wichtigste Faktor.
The Weakness of Strong Ties
Persönliche Erfahrungen in den Zeiten der Pandemie.
Selbstorganisation und Kapitalismus
“Selbstorganisation: Ja! - Kapitalismus: Nein??” titelt eine Episode des Gründerplausch aus dem April 2020. Lars Vollmer und Mark Poppenborg fragen, ob das Bekenntnis für Selbstorganisation, wenn man es zu Ende denke, nicht auch eines für den Kapitalismus und insbesondere für den Markt sei. Ich möchte widersprechen. Aus Empörung beim Hören wurde im Laufe des Nachdenkens ihrer Argumente dieser Artikel. Ich versuche ihr Argument zu rekonstruieren. Im Anschluss beschäftige ich mich genauer mit ihrem Begriff des Marktes und mit der Kopplung gesellschaftlicher Funktionssysteme. Eine eigene These beschließt diesen Artikel.
Wiederbelebung
Der letzte Eintrag in meinem Blog ist von 2014. Fünf Jahre her. Seitdem habe ich ein paar Beiträge für unseren Firmenblog verfasst, aber nichts mehr hier.
Mikrosystems vs. Mikroservices
Der Begriff Mikroservice ist IN. Nicht ohne Grund. Erfahrungen der letzen 10 Jahre, insbesondere mit großen Webanwendungen, haben dem Mikroservicegedanken den Boden bereitet. Zu große Anwendungen, zu komplizierte und seltene Deployments, unklare Verantwortlichkeiten dienen in der Diskussion als Begründung des neuen Architekturstils. Am Begriff Mikroservice haben sich einige Kontroversen entzündet. Mikroservice vs. Monolith: An die Stelle einer großen Anwendung, die als ganze deployt wird, treten viele kleine Services, die als deploybare Einheiten eine Anwendung in Fachlichkeiten dekomponieren. Mikroservice vs. Nanoservice: Wie viele Zeilen Code soll ein Service enthalten? 100? Ist die Frage sinnvoll - unabhängig von Programmiersprache und Kontext? Vielleicht ist sie nur Symptom der Frage: Wie weit kann und soll man die Mikrofizierung treiben?
DDD: Ports und Adapter
Vaughn Vernon bespricht in seinem Buch Implementing Domain Driven Design verschiedene Arten, wie ein System intern geschichtet werden kann. Sein favorisiertes Muster ist 'Ports und Adapter' oder - wie es an der Quelle des Ansatzes dem Artikel von Alistair Cockburn heisst - Hexagonale Architektur.
DDD: Die Grenzen eines Aggregats
Auf der Arbeit kultivieren wir gerade Eat'n'Read. Jeden Freitag sitzen wir zusammen, essen und lesen Implementing Domain Driven Design von Vaughn Vernon. Vernon arbeitet die Gedanken auf, die Eric Evans in Domain Driven Design entwickelt hat. Ein paar Dinge sind neu - Domain-Events - andere werden anders strukturiert, Schwerpunkte sind verschoben aber im Großen und Ganzen versucht sich Vernon am Original (?) zu orientieren. Um so interessanter ist es sich die Frage zu stellen, wo nun die Unterschiede zwischen Evans und Vernon sind.
Conways Law Revisited
Wenn man in einer Woche zweimal in unterschiedlichen Kontexten mit einer Sache konfrontiert wird, ist das ein Zeichen. Wofür auch immer. So ist es mir in der letzten Wochen mit Conways Law ergangen. Bisher kannte ich Conways Law als das Gesetz, das besagt, dass sich über kurz oder lang die Strukturen eines sozialen Systems in einem technischen System wiederfinden werden. Wenn ich ein Programm schreibe, mit dem später zwei Fachabteilungen arbeiten werden, wird sich diese Trennung auch im technischen System - dem Programm - ausdrücken.
Composed Method Revisited
Ich habe das erste Mal von Composed Method in dem Buch Smalltalk - Best Practice Patterns von Kent Beck (1996) gelesen. Das Buch ist eine Sammlung von Mustern für das Programmieren im Kleinen. Das Problem, das Composed Method adressiert, ist:
Selbstorganisation
Am letzten Freitag hatte ich das Glück am it-camp der oose teilnehmen zu können. Das Thema war Selbstorganisation. Der Referent war einer der führenden Köpfe systemischer Organisationsberatung und Therapie in Deutschland: Fritz B. Simon. Er erklärte in seinem Referat die Grundbegriffe der systemischen Organisationstheorie. Im Anschluss gab es ein Worldcafe, das sich sehr stark um alle Aspekte der Selbstorganisation von Teams dreht. Das Ende der Veranstaltung war ein Open-Space. Ich habe dort mit anderen versucht einige Verwirrungen um den Begriff der Selbstorganisation, wie er im Referat entfaltet wurde und wie er uns in den Diskussionen umtrieb, aufzulösen.
Software als Handwerk?
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?
Vortrag auf den XPDays 2010
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:
Monoglottes Programmieren?
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.
Die Zeit der Unschuld ist vorbei
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.
Primus inter pares
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.
Kanban, Scrum und die Frage des Übergangs
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.
Leanproduction und das Eintüten eines Briefes
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.
Der Tod des Navigators
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.
Sinn und Grenzen eines Fluent Interfaces
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.
Platzen oder Lean & Zen
Ich habe manchmal das Gefühl, ich platze gleich, wenn ich eine Idee nicht loswerde, wenn ich nicht über etwas reden kann, was mich gerade bewegt.
Ich bin im Moment in Arhus und habe an der JAOO teilgenommen. Die ersten Tage waren so lala. Das mag an mir liegen. Ich hatte mir vor allem Talks ausgesucht, bei denen ich schon etwas von den Sprechern gelesen hatte. Ich wollte sie gerne mal live sehen und als Mensch erleben. In der Regel finde ich das sehr spannend, weil mein Bild von dem, was sie schreiben, sich präzisiert. (So ist es mir bspw. auch mit der Stimme von Stefan Tilkov gegangen, seitdem ich ihn beim heise-Developer-Podcast gehört habe, lese ich seinen Blog ganz anders.) Nun denn - ich habe die Leute jetzt gesehen, habe ein präziseres Bild von ihnen, aber was sie gesagt haben, hat micht nicht überrascht, wie auch, wenn ich vorher schon ein paar ihrer Gedanken kannte. Ich war ein wenig enttäuscht.
El-Oh-De revisited
Einmal im halben Jahr komme ich an Dan Mangles' Blogeintrag über Missverständniss des Gesetz von Demeter vorbei. Und meistens - das scheint eine Eigenart von mir zu sein - lese ich ihn nochmal. So auch vor ein paar Tagen. Und auch dieses Mal habe ich das Gefühl ihn bisher noch nicht richtig gelesen zu haben.
GIT oder die Suche nach der richtigen Abstraktion
Ich glaube von Marshall McLuhan stammt der Gedanke, dass neue Medien immer in Gestalt der alten die Welt erblicken. Sie finden ihre eigene Form erst im Laufe ihrer Entfaltung. Der Gedanke ist wahrscheinlich eine spezifische Fassung eines Allgemeineren. Das Neue tritt prinzipiell immer zuerst in Gestalt des Alten auf und wird auch in seinen Kategorien gedacht. So war das Auto zunächst eine Kutsche ohne Pferde und das Internet war ein Sammelsurium von Texten.
GIT und warum SVN-Merges keine Merges sind
Seit zwei Wochen arbeiten wir im Projekt wirklich mit GIT. Bisher kannte ich es nur als Tool, um Open-Source-Projekte zu bekommen, oder für Spielzeug-Repositories auf der eigenen Platte. Die wirklichen Fragen kommen erst jetzt - im realen Leben. 'Bekomme ich wirklich jedesmal alle Updates aller Branches aus dem Repository oder nur den HEAD?' 'Wie läuft denn das mergen, wenn ich gleichzeitig mehrer Branches bekomme?' Ich merke bei meinen Fragen, dass ich noch in SVN denke.
Kanban versus Scrum
Im März waren Arthur und ich in Hamburg bei einer Veranstaltung des ObjektForum Nord zum Thema Lean Software Development. Referent war Stefan Roock. Der Vortrag bestand aus zwei Teilen. Im ersten referierte Stefan die Thesen der Poppendieks zum Thema Lean Software Development, wie sie auch in ihren Büchern veröffentlicht sind. Im zweiten Teil beschrieb er Kanban und Kanban-Boards wie sie im Moment im Scrum-Kontext diskutiert werden.
Klassisches Testen von Software versus TDD
Im Januar hatte die Agile Grupppe Bremen Andreas Spillner zu Gast. Andreas hat an der Hochschule Bremen eine Professur, sein Gebiet ist das klassische Testen von Software. Er stellte beim Treffen der Agilen Gruppe vor, was das sei: Testen von Software. Die Diskussion drehte sich um die Frage, ob denn TDD klassisches Testen ersetze oder wie das Verhältnis zu bestimmen sei.
subscribe via RSS