One Man Think Tank Gedanken: Dezember 2015

Dienstag, 8. Dezember 2015

Teaser: Der dunkle Bruder des Feedback

Feedback ist nötig. Umso mehr, je unsicherer ist, was eigentlich geleistet werden soll und ob man das schon geleistet hat. Deshalb sind in der Agilität zwei Feedbackschleifen explizit institutionalisiert: Durch automatisierte Tests bekommen Entwickler innerhalb von Sekunden oder Minuten Feedback, ob Veränderungen zu Regressionen geführt haben. Durch Reviews des Implementierten mit Stakeholdern am Ende kurzer Iterationen bekommen Entwickler Feedback innerhalb von Tagen oder wenigen Wochen, ob sie ihr Werkstück näher an die Zielvorstellung jener heranentwickelt haben.

Mit der Agilität ist das Feedback aus dem Schatten von Gevatter Plan getreten. Das ist eine zentrale Leistung der Agilität.

Doch irgendetwas stimmt nicht. Es herrscht jetzt nicht einfach Friede. Die Entwicklung schreitet nicht einfach zügig voran. Ganz merkwürdig zagt und stolpert sie immer noch – trotz des klaren, sauberen Anführers Feedback.

Das liegt an einer Kraft, die bisher unbenannt ist. Sie beeinflusst den Fortschritt stark, doch niemand benennt sie so recht. Alle kennen sie, aber man räumt ihr keinen gleichwertig offiziellen Platz neben dem Feedback ein. Ich will sie deshalb den dunklen Bruder des Feedback nennen.

[Lesen Sie weiter in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Freitag, 4. Dezember 2015

Teaser: Microservices verbinden in Datenflüssen

Mir hat der Blogartikel von Tobias Flohre gut gefallen, in dem er die Kommunikation zwischen Microservices mit asynchronen Events beschreibt. Er tut das als Gegenentwurf zu einer Darstellung mit BPMN und einer Implementation auf der Basis einer Workflow-Engine.

Entkoppeln mit Events

Gut gefallen hat mir der Artikel, weil Tobias damit eine Lanze für das Principle of mutual Oblivion (PoMO) bricht. Es besagt, dass Funktionseinheiten in Software nicht funktional abhängig von einander sein sollen. Logik in der einen sollte Logik in der anderen nicht kennen, nicht nutzen. Jede Funktionseinheit sollte vielmehr quasi selbstvergessen “nur ihr Ding machen” und sich nicht um die Umwelt scheren. So tut das in einem Organismus jede Zelle; warum also nicht auch jede Funktionseinheit in einer Software? (Das ist aus meiner Sicht sogar, was Alan Kay ursprünglich unter Objektorientierung verstanden hat. Hier dazu eine Artikelserie von mir: OOP as if you meant it.)

Ich schreibe hier bewusst “Funktionseinheit”, weil ich auf konzeptioneller Ebene spreche. Eine Funktionseinheit kann im Code eine Funktion oder eine Klasse… oder eben auch ein Microservice sein. Eben ein Modul als Träger von Verhalten herstellender Logik.

Eine PoMO-konforme Funktionseinheit bekommt von irgendwoher “etwas”, arbeitet daraufhin und liefert anschließend “etwas anderes” ab. Woher “etwas” kommt, wohin “etwas anderes” geht, das ist der Funktionseinheit einerlei. Das mag seltsam klingen – doch Sie sind damit ganz vertraut. Jede Funktion T f<S,T>(S s) arbeitet so.

Hier ein Beispiel für eine solche Funktionseinheit aus Tobias’ Artikel:

[Lesen Sie den ganzen Artikel in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Donnerstag, 3. Dezember 2015

Teaser: Ziele erreichen mit tugendhafter Emergenz

Manche Ziele scheinen mir so schwer erreichbar, dass ich denke, man kann sie gar nicht direkt erreichen.

Wie sieht es mit einem erfolgreichen Unternehmen aus? Oder was tun, um Software stets wandlungsfähig zu halten? Kann man auf diese Ziele Maßnahme für Maßnahme zugehen?

Probleme zentraler Steuerung

Es wird schwer, auf ein Ziel zuzusteuern, wenn man die dafür relevanten Teile und Aktivitäten nicht mehr überblickt. Solange man sie überblickt, kann man versuchen, sie direkt anzusteuern. Jenseits des Überblicks jedoch… das stellt sich schnell ein Gefühl des Kontrollverlustes ein – umso mehr, je stärker man glaubt, doch eigentlich zu wissen, was zu tun nötig ist.

Unabhängig vom Überblick kann es aber auch an Zeit mangeln. Selbst wenn eine zentrale Instanz wüsste, wie Teile zu steuern wären, kann es schlicht zu lange dauern, sie zu informieren und auf Antwort zu warten, um angemessen schnell zu reagieren.

Und schließlich noch die Inkompetenz. Egal wie groß die Zahl der Teile und wie lang die Kommunikationswege: wenn die Komplexität wächst, werden in Bezug zu ihr zentrale Entscheider zunehmend inkompetent. Sie können einfach nicht mehr wissen, was zu tun ist, um gewünschte Zustände durch konkrete Steuerungsmaßnahmen zu erreichen. Das ist nur möglich, solange die Situationen kompliziert sind.

[Lesen Sie weiter in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Dienstag, 1. Dezember 2015

Teaser: Bereiche der Schätzbarkeit

In den letzten beiden Tagen habe ich mal wieder zusammen mit Andrea Kaden einen Zeitmanagement-Workshop für Softwareentwickler gegeben. Natürlich kamen wir dabei auch auf das Thema Schätzung. Das treibt Entwickler immer wieder und immer noch sehr um. Sie empfinden schlicht großen Stress, wenn es vorhersagbar nicht klappt, Schätzungen einzuhalten. Sie fühlen sich unwohl, zur Unehrlichkeit gezwungen zu werden.

Das verstehe ich sehr gut. Deshalb bemühe ich mich, Hilfestellung bei diesem Thema zu geben. Ich versuche zu erklären, warum es mit dem Schätzen schwer bis unmöglich ist. Ich versuche, einen alternativen Weg aufzuzeigen, auch ohne Schätzungen verlässlich wertvolle Software herzustellen. Ich verweise auf andere, die auch versuchen, Entspannung zu vermitteln.

Deshalb heute auch dieser Blogartikel. Ein weiterer Versuch, Softwareschätzungen besser verständlich zu machen. Und zwar ausgehend von einer Analogie.

[Lesen Sie weiter in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.