Event Sourcing ist für mich die Zukunft der grundsätzlichen Zustandshaltung in Software. Alles andere ist eine Optimierung, die man nicht leichtfertig und schon gar nicht vorzeitig vornehmen sollte.

Mit Event Sourcing verdrängt endlich Konstruktivismus den bisherigen Materialismus des immer noch dominierenden RDBMS/OO-Denkens.¹ Und ich halte Event Sourcing für die Grundlage von Antifragilität in der Softwareentwicklung.²

Ich finde Event Sourcing also sehr spannend und wichtig – nur leicht ist es nicht. Denn auch wenn Event Sourcing auf das eine Datenmodell, die eine große Datenstruktur verzichtet, bedeutet das nicht, dass man sich keine Gedanken um Datenmodelle machen muss.

Damit meine ich nicht die vielen situationsspezifischen Strukturen, die nun sehr einfach möglich werden. Für jede Interaktion mit einer Software kann es nun ein daraufhin optimiertes Datenmodell geben.

Ich meine die Events, die beim Event Sourcing in einem stetig wachsenden Strom gespeichert werden und den sich entwickelnden Systemzustand repräsentieren. Statt des einen großen Datenmodells gibt es im Event Sourcing ein Granulat bestehend aus kleinen und kleinsten Datenstrukturen, den Events.

Das ist für das RDBMS- oder auch Dokumenten-gewohnte Denken eine Umstellung. Während man bisher versuchen konnte, „die Struktur der Welt“ zu erkennen und möglichst realitätsgetreu in Software abzubilden, geht es jetzt um ihre Entfaltung über die Zeit. Es geht nicht mehr um statische Resultate von letztlich irrelevanten Ereignissen, sondern um höchst relevante Ereignisse, aus denen alle möglichen Resultate in Zukunft abgeleitet werden können.

Die Welt der Zustandshaltung steht damit Kopf, würde ich sagen.🙃😁

Gedanken muss man sich also beim Event Sourcing um die Events machen. Klingt auch ohne große Einleitungsworte plausible, oder?😉

Wie findet man aber „die besten“ Events? Was sind überhaupt „gute“ Events? Das sind Fragen, die mich deshalb bewegen. Ich suche Prinzipien und Heuristiken, um für gegebenen Anforderungen mindestens „ziemlich gute“ Events zu finden.

Die Challenge

Deshalb habe ich im Domain Driven Design Slack-Workspace „DDD Germany“ mal nachgefragt, wie man dort die Sache sieht. Getan habe ich das mit einer kleinen Aufgabe, die mir einerseits sehr überschaubar scheint, andererseits aber doch ein bisschen Herausforderung bietet.³

Als Aufgabe habe ich die aus Coding Dojos bekannte Bowling Game Kata gewählt:

Es soll ein „Ergebniszähler“ realisiert werden, der die Punktzahl eines Bowling-Spiels bestimmt. Dieser Zähler reagiert auf zwei CQS-Nachrichten: dass ein Wurf registriert und dass das Ergebnis geliefert werden soll. Mehr nicht.

Es gibt also zwei glasklare Interaktionen der Umwelt mit einer Zähler-Software. Darüber muss nicht spekuliert werden. Die einzige Frage, die die Aufgabe stellt, ist die nach den Events.

Die Interaktionen basieren auf gemeinsamem Zustand. Dieser Zustand soll mit Event Sourcing realisiert gedacht werden, d.h. als Strom von Events. Welche Events sollten das sein?

Mehr ist nicht zu liefern, nur die Events. Die Lösung soll gerade nicht komplett implementiert werden, weil es mir ja darum geht, wie Events a priori gefunden werden können.

Event Storming - nomen es omen - ist eine Technik, die dafür zum Einsatz kommen könnte; allerdings sehe ich sie vor allem bei Szenarien, die deutlich größer sind und/oder bei denen es viele Sichtweisen zu berücksichtigen gilt.⁴

Dass man nach Implementation und Betrieb einer Lösung immer schlauer ist und also vielleicht auch eine noch bessere Idee hat, welche Events nützlich wären, scheint mir ausgemacht. Wie bei RDBMS oder umfänglichen Objektmodellen ist eine Änderung der Datenbasis dann jedoch schwierig. Und Event Sourcing verspricht ja, dass man gerade das nicht tun muss/soll.

Events versionieren, weitere Events später nachschieben, einen Eventstrom komplett umschreiben: das kann man alles machen und es mag zuzeiten nötig sein. Doch so, wie es einige Kriterien für RDBMS-Schemata gibt, um nicht gleich mit dem falschen Fuß aufzustehen, so gibt es ja vielleicht auch Kriterien für das Schneiden von Events, um den Zeitpunkt hinauszuzögern, da man sich in eine Ecke gepinselt hat. Was meint die DDD-Community dazu?

Die Lösungen

Ich hatte zuerst für mich selbst die Aufgabe gelöst (und natürlich doch nicht darauf verzichtet, den kompletten Code dafür zu schreiben🤪). Ohne meine Events zu verraten, habe ich dann die Aufgabe der Community vorgelegt und weitere vier Lösungen bekommen.

Ich liste sie einfach mal mit den Slack-Benutzernamen ihrer Einreicher in alphabetischer Reihenfolge:

Die Lösungen wurden in Pseudocode, Typescript, C#, F# eingereicht. Ich habe sie zur besseren Vergleichbarkeit alle nach C# übersetzt. Ein bisschen ging dabei die Ausdrucksfähigkeit von F# (@phj) verloren, aber das finde ich nicht schlimm.

Außerdem habe ich sie insofern vereinheitlicht, als dass ich eine Game ID, die in manchen Lösungen in den Events stand, gelöscht habe. Ich denke, sie trägt in Bezug auf diese Aufgabe nichts zur Erkenntnis von Prinzipien und Heuristiken bei und betrifft einen orthogonalen Belang.

Lösungsebenen

Die Aufgabe war nicht groß. Die Lösungsvorschläge sollten also nicht so weit auseinander liegen. So hatte ich es mir gedacht - und war dann doch überrascht, dass selbst hier eine Lösungsvielfalt entstanden ist.

Ich sehe die Lösungen auf drei Ebenen:

1. Minimallösung (@akii, @bwaidelich): Es wird nur ein Event benötigt, der die über das Kommando gemeldeten geworfenen Pins aufzeichnet.
2. Aufzeichnung von Bonuspunkten (@sebastian): Zusätzlich zum Event der Minimallösung wird aufgezeichnet, dass ein Wurf als Bonus für einen vorhergehenden anerkannt wurde.
3. Aufzeichnung von Frames und Bonuswürdigkeit (@phj, @ralfw): Zusätzlich zu den Events der zweiten Ebene wird aufgezeichnet, falls ein Wurf einen Frame beendet hat und ob der Frame bonuswürdig ist (Spare oder Strike).

Analyse

Die Idee hinter der Aufgabe war, dass ein Event Store befüllt wird mit Events im Rahmen der Verarbeitung des einen Kommandos - und dass die Events während der einen Query zu einem Gesamtergebnis verarbeitet werden.

Die Logik zur Herstellung des Verhaltens würde sich in einer Implementation also auf einen Command- und einen Query-Handler verteilen. Die Wahl der Events hat darauf einen großen Einfluss.

Die Minimallösungen zeichnen im Grunde nur die mit dem Kommando gemeldeten Pins eines Wurfes 1:1 auf. Das ist trivial, so dass die ganze Last der Ergebnisberechnung bei der Query-Verarbeitung liegt. Die Minimallösungen betreiben mithin eigentlich kein Event Sourcing, sondern eher ein Command Sourcing.

Die Bonuspunktlösung verschiebt die Last zum Command-Handling. Bei der Query-Verarbeitung müssen nur die Pins aus den Events für die Würfe und die Bonuspunkte addiert werden. Das ist trivial - dafür muss die Kommando-Verarbeitung allerdings vorher entschieden haben, wann ein Bonuspunkt-Event aufzuzeichnen ist.

Die Frame-/Bonuswürdigkeit-Lösungen vereinfachen die Logik der Query-Verarbeitung nicht weiter; die bleibt trivial. Die zusätzlichen Events wirken sich vielmehr auf das Command-Handling differenzierend aus. Vielleicht wächst die Logik dort noch ein wenig, vor allem scheint es mir aber einfacher, in der Kommando-Verarbeitung Verantwortlichkeiten zu trennen: festzustellen, ob/ab wann ein Bonus gewährt wird, und einen Bonus zuzuweisen, sind eben zwei verschiedene Aufgaben.

Interessant finde ich, dass keine Lösung einen Event zur Anzeige eines Spielendes definiert.⁵ Ist das kein Aufzeichnungswürdiges Ereignis? Oder war die Aufgabe so formuliert, dass alle angenommen haben, dass am Spielende der Eventstrom verschwindet? Dagegen spricht, dass einige Lösungen auch die Aufzeichnung einer Game ID vorgeschlagen haben. Da wurde augenscheinlich größer gedacht.

Oder war die Aufgabe unterspezifiziert insofern, als dass nicht angegeben war, was passieren soll, wenn ein Wurf über die maximale Wurfzahl eines Spiels hinaus gemeldet wird? Damit war sozusagen das Spielende kein Thema in der Aufgabenbeschreibung? Hm…🤔

Diskussion

Was tun mit einem Spektrum an Lösungen? Sind sie alle gleichwertig, gleich gut? Welches Für und Wider gibt es? Genau um diese Erkenntnis ging es mir ja, als ich die Aufgabe gestellt habe.

Augenfällig ist zunächst der Unterschied zwischen den Minimallösungen und den anderen in der Verortung der Logik. Die Minimallösungen brauchen gewiss viel Logik während des Query-Handlings - wie viel sie im Command-Handling tun, ist eine Frage des Anspruchs an Validation/Konsistenzprüfung. Im einfachsten Fall ist dort im Grunde gar keine Logik nötig.

Das Argument der Vertreter dieses Ansatzes ist sehr simpel: „Ein Event reicht.“ Und das ist wahr. Aufzuzeichnen, dass ein Wurf gemacht wurde bedeutet, ein reales Ereignis in der Umwelt aufzuzeichnen. Das wird über ein Kommando gemeldet und ist die einzige Anweisung zur Zustandsänderung. Wenn man sich das merkt, kann der Rest jederzeit daraus abgeleitet werden.

Wenn es so einfach funktioniert, warum sind dann aber 60% der Einreicher auf weitere Events gekommen? Ich denke, das liegt an der Abhängigkeit, die mit der Minimallösung einhergeht: Ein bei der Query nach außen gemeldeter Zustand ist vollständig abhängig von Logik. Ändern sich z.B. die Regeln, können die Ergebnisse alter Spiele u.U. nicht mehr nachvollzogen werden.

Das mag ok sein, wenn eine solche Änderung nicht zu erwarten ist, weil die Domäne sehr stabil ist. Oder es mag ok sein für ein so kleines Beispiel mit angenommener Kurzlebigkeit. Für „richtige“ Software jedoch scheint mir da eine Gefahr fehlender Reproduzierbarkeit zu liegen.

Event Sourcing Lösungen sind mehr von Logik abhängig als Lösungen, die Zustand in einem dauerhaften Modell aktuell halten, weil ständig Projektionen von Events auf temporäre, grundsätzlich flüchtige Modelle stattfinden. Deshalb würde ich mich nicht auf nur den einen minimal notwendigen Event verlassen wollen.

Wie viele Events mehr sollen es dann aber sein?

Events repräsentieren Weggabelungen in der Entwicklung der Welt. Wenn etwas passiert, dann kollabiert ein Möglichkeitsraum; ein Weg ist eingeschlagen worden. Vor dem ersten Wurf ist es noch möglich, dass nach dem Wurf 10, 9, …, 1, 0 Pins abgeräumt sein werden; nach dem Wurf ist klar, dass genau z.B. 4 Pins abgeräumt wurden.

Dasselbe ist der Fall bei Entscheidungen: Sie lassen einen Möglichkeitsraum zusammenschnurren auf genau eine Möglichkeit, nämlich die, für die sich entschieden wurde. Vor einer Entscheidung ist es noch möglich, dass z.B. beim Sturz eines Fußballspielers nach Zusammenstoß mit einem anderen ein Fowl gepfiffen wird oder nicht. Der Schiedsrichter kann sich für oder gegen Fowl entscheiden und er kann sich sogar für ein Fowl mit oder ohne Vorteil entscheiden (wenn ich es recht erinnere). Mit der Entscheidung des Schiedsrichters erst schnurrt der Möglichkeitsraum zusammen auf genau ein Urteil; was passiert ist, ist dann ganz klar z.B. ein Fowl gewesen.

Entscheidungen lassen nichts direkt passieren. Vielmehr deuten sie etwas, das passiert ist - und lassen als Ergebnis wieder etwas passieren. Ein Urteil, eine Entscheidung ist ebenfalls ein Ereignis. Mit jeder Entscheidung verändert sich der Weg eines Systems, d.h. sein Zustand. Wer sich nach links wendet, ist in einem anderen Zustand, als hätte er sich nach rechts gewendet.

Die Aufzeichnung des per Kommando gemeldeten Pins betrifft also quasi ein Ereignis 1. Ordnung, ein unmittelbares Ereignis. Das Programm „erleidet“ dieses Ereignis, es kann nichts dafür.

Die Einreicher von Lösungen oberhalb der Minimallösung haben sich nun überlegt, dass es hilfreich wäre, weitere Ereignisse aufzuzeichnen. Die nenne ich mal Ereignisse 2. und höherer Ordnung. Sie repräsentieren Entscheidungen der Spiellogik.

Bei @sebastian wird nur festgehalten, dass die Logik im Command-Handling erkannt hat, dass ein Wurf als Bonus für einen vorhergehenden Frame zu zählen ist. Das reicht aus, um die Query-Logik drastisch zu vereinfachen.

Die Angriffsfläche von Regeländerungen auf die Berechnung eines Spielergebnisses ist damit deutlich kleiner geworden, würde ich sagen. Es muss zwar immer noch summiert werden, doch das liegt auf der Hand, würde ich sagen. Nur ein Spielende-Ereignis, in dem man das Ergebnis festschreibt, würde noch mehr Robustheit gegenüber Regeländerungen versprechen.

Und was ist mit den darüber hinaus gehenden Events der Lösungen von @phj und @ralfw? Sie dokumentieren auch Entscheidungen; oder ich könnte es auch Erkenntnisse nennen. Die Logik entscheidet, dass mit einem Wurf ein Frame abgeschlossen wurde. Die Logik erkennt den Abschluss eines Frame.

Warum diese Entscheidungen auch noch aufzeichnen? Die Ergebnisberechnung profitiert davon nicht mehr. Vielleicht wird es mit diesen Events aber einfacher, einen Bonuswurf zu erkennen? Das könnte sein. Dann wären es „funktionale“ Events.

Oder dienen sie nur der Dokumentation von Entscheidungen, damit die dauerhaft nachvollziehbar und für zukünftige Nachrichtenbehandlungen nützlich sind? Dann wären es zunächst „dokumentierende“ Events.

@phj hat sein Denken so erklärt:

[M]it nur “roll made” wäre ja nur eine nach events aussehende Fassade vor eine nicht wirklich event-orientierte Lösung gekommen. Das wichtige bei ES ist - und das habe ich versucht damit etwas herauszustellen - dass Logik nur in den Command Handlern, aber nicht in den Projektionen stattfindet. Die Entscheidungen, was ein Frame ist, wann ein Bonus erforderlich wird, etc. mussten damit vor dem Veröffentlichen von Events geschehen, und erfordern daher dann auch spezifische Events.

Etwas zugespitzt formuliert ist der für mich wesentliche Punkt: „dass [Entscheidungsl]ogik nur in Command Handlern“ steht.

@phj sagt weiter:

dass in den Projektionen keine Entscheidungen […] getroffen werden dürfen, [weil] die eventuell nicht dauerhaft in ihrer Struktur oder Parametrisierung sind. […] Ansonsten würde eine zukünftige Regeländerung zu einer nachträglich anderen Interpretation von bereits durchgeführten Spielen führen. Also müssen die Events die Struktur der Vorbedingungen und der Entscheidungsergebnisse der Geschäftslogik festhalten

Das deckt sich mit meinem Verständnis; nicht umsonst sind wir auf sehr ähnliche Lösungen gekommen😉

Ergebnis

Events zu finden für gegebene Kommandos und Queries lässt Raum für Kreativität. Hier wie auch sonst in der Softwareentwicklung ist eine Balance zwischen dem unzweifelhaft jetzt Erkennbaren und dem möglichen Zukünftigen zu finden. Auch beim Schneiden von Events kann man ansonsten wohl vorzeitig optimieren.

Allerdings scheinen mir lieber mehr als weniger Events tendenziell eine relativ harmlose und billige Optimierung im Hinblick auf zukünftige Nachvollziehbarkeit und Events als Ausgangsmaterial für weitere Nachrichtenverarbeitungen.

Sich beim einmaligen Schreiben etwas mehr Mühe zu geben, erleichtert später das häufige Lesen aus unterschiedlichen Blickwinkeln. Event Sourcing unterscheidet sich da nicht von der Programmierung, würde ich sagen.

Die Kunst des Event Sourcing besteht dann wohl darin, schon aus den Anforderungen die wesentlichen, aufzeichnungswürdigen, zu stabilisierenden Entscheidungen herauszudestillieren.

Zu berücksichtigen sind dabei Kommandos wie Queries. Und was man da an Entscheidungen findet, ist in Events zu gießen, die beim Command-Handling generiert werden.

Dass ein Wurf stattgefunden hat, ist keine Entscheidung innerhalb einer Lösung. Aber wenn die Regeln von Frames sprechen, wenn es besondere Wurf-Kombinationen gibt und Boni zugesprochen werden… dann stecken dahinter Entscheidungen und die lohnen der Aufzeichnung „für die Nachwelt“.

Dazu mag noch kommen, Begriffe der Domäne materialisieren. Wenn in den Regeln „Frame“, „Spare“, „Strike“, „Bonus“ als Begriffe vorkommen, dann liegt es nahe zu erwarten, sie in einem Eventstrom zu finden.

Das sind lohnende Erkenntnisse aus der Übung. Ein schönes Beispiel für deliberate practice. Für mich hat sich die Challenge also gelohnt. Ich bin mir klarer geworden über Prinzipien und Heuristiken des Event Sourcing. Damit werde ich in die nächste Challenge gehen… Stay tuned!😁

Endnoten:

1. Materialismus verstehe ich hier als Haltung, die annimmt, dass es außerhalb von Software eine Realität gibt, die es sich lohnt, 1:1 innerhalb der Software mit stabilen Datenstrukturen abzubilden.
   Konstruktivismus hingegen macht für mich keine solche Annahme. Er konstruiert nach Bedarf immer wieder neue Repräsentationen aus „rohen Wahrnehmungen“, die nicht mehr und nicht weniger als nützlich sind. Ob sie einer „objektiven Realität“ entsprechen oder nicht, ist ihm einerlei. ↩
2. Antifragil ist Software bzw. die Softwareentwicklung für mich, wenn sie Änderungswünsche begrüßt. Dann trägt jede Änderung dazu bei, dass Software besser wird und sogar besser im besser werden. ↩
3. Auf eine CRUD-Aufgabe habe ich verzichtet, weil die wohl Naserümpfen bei einigen Event Sourcing Freunden hervorgerufen hätte. Die Meinung, dass Event Sourcing sich nicht für CRUD-Szenarien lohne, hält sich noch. Ich bin allerdings anderer Ansicht. Aber davon ein andermal mehr. ↩
4. Und das Ergebnis scheinen mir dann auch oft Domänenevents zu sein, die ich in CQNS Notifications nenne.
   Domänenevents sind für mich Nachrichten, die zwischen „Akteuren“ fließen. Das bedeutet nicht, dass sie 1:1 in einem Eventstrom aufgezeichnet werden. ↩
5. Nur bei @sebastian gibt es eine Frame-Nummer, die implizit eine relativ leichte Erkennung des Spielendes erlaubt, weil jedes Spiel aus 10 Frames besteht. ↩

Do you remember the story about the magic black box transforming software requirements into release at no cost at all? I wrote about it in a previous article - and since then have received many questions about how it could be deployed in real software projects. Because what I described were simplistic scenarios with just single requirements.

Here’s a short reminder of what this thing is, the magic black box:

Magic Black Box Recap

Imagine you are a product owner. One day a black box appears on your desk with the promise to produce high quality software for your for free. Yes, for free! You just hook it up to a GitHub repository and feed it requirements as issues. The black box works on them one-by-one and drops the finished code as releases into the repository.

The only downside to the magic is, that you don’t know how long it’s going to take the black box to transform an issue into a new release.

But since the black box did not cost you anything you try it out and record the cycle time for some issues from start to finish. Some issues take 1 day, some 3 day, and there is even one with 10 days.

You realize there is some method to the magic. The black box is not at all useless to you, even though you cannot ask it in advance for an estimation of how long it’s probably gonna work on an issue.

Instead of getting an estimate from it, you observe it and make your own forecast.

For example: Based on the issues implemented so far the next one has a 84% chance of being finished in 7 days (or even less).

And if you update your log of cycle times with each issue done, your next forecast will be even more realistic. With three more issues implemented you see how the situation even changes towards the better. 6 days (or less) has moved up from 79% probability to 82%.

I think, this is a much more realistic information compared to some developer’s gut feeling. The simple reason: this prediction is based on facts, on historical data. No wishful thinking, no invisible padding, no deadline-driven distortion. And you did not need to go through frustrating discussions with developers.

So much for a quick recap. Read the previous article for a couple of more details.

Single Black Box, Multiple Issues

Forecasting the implementation time for a single feature is not bad. But it’s not more than a start. Managers and customer are rarely asking „How long will only this one feature take?“ Rather they want to know how long it takes to get the next 5, 17, 31 features done.

For example: What’s your answer to „How long will 4 features take?“ if the answer to the single feature question is „With an 82% chance it’s gonna take 6 days.“? Do you just calculate 6+6+6+6=24 and say „It’s gonna take 24 days with a probability of 82%.“?

No, that’s not gonna work. Or: It works, but then your prediction (cycle time for 4 features) is worse than it needs to be and wrong (with regard to the probability).

Instead what you do is run simulations.

Monte Carlo Simulation

A single simulation looks like this: Sample the historical data 4 times (since you want to forecast the total cycle time for 4 features), i.e. pick 4 cycle times at random. This might result in these cycle times: (1, 1, 3, 7). The total cycle time would be 12 days.

Then do it again: (2, 4, 5, 3)=14.

Then do it again: (9, 1, 3, 7)=20.

And so on, and so on… Do it 1000 or 50000 times. That’s called a Monte Carlo Simulation.

Then for each of the maybe 1000 total cycle times count how often it occurs, e.g. 5=4 times, 9=50 times, 14=98 times, 25=10 times…

Here are the results of 1000 such simulations for 4 features based on the latest historical data from above:

It’s pretty clear that 4 features cannot be done in less than 2 days, since a single issue always took the black box at least 0.5 days. And it’s clear that it cannot be more than 40 days, i.e. 4 times the maximum cycle time so far.

But as you can see from the above simulation both the minimum or maximum might not even happen. At least they did not happen during 1000 „trial runs“.

Now look at the simulation data turned into a histogram. Interesting, isn’t it?

The original distribution had two „humps“ (see above): one at cycle time 2, another at 9. But the distribution of total cycle times does not resemble the original distribution. It’s close to a normal distribution. That’s due to the Central Limit Theorem and was bound to happen. But don’t worry. No need to get deeper into math here.

And of what use is this to answer the question „When will 4 features be done?“? Like with single feature forecasts it’s about percentiles again: How many simulation results are equal or less than a certain total cycle time?

If you still think a bearable risk is 18% then 19 days are your forecast: 82% of all simulation results predicted 19 days or less for 4 features.

Now you see, why 24 days where too much. 24 days, i.e. 4 times the 82% cycle time for a single feature, would offer you even 96% confidence!

That’s why the usual padding of estimations is so wrong: The manager asks developer A for his estimation of feature 1 and gets 10 days including a (unknown) 30% padding. She asks developers B, C, D for three more features each including a padding of 30%. Even these 4x30% padding are too much; they are the same as 24 for the simplistic total cycle time for 4 feature. But nevertheless she adds another 10% to be on the safe side. This decreases the risk, sure, but not explicitly. Receivers of the updated estimates don’t know about it; it might be contrary to their risk attitude. It probably creates a prospect of higher costs than necessary.

But never mind. Those days of excessive padding are over. With forecasting and a black box the predictions are much more realistic: no hidden padding, no excess padding.

You see, predicting the development of multiple features is possible even if you’re working with a black box you cannot ask for an estimation. The math is simple, the approach straightforward. It can be done in some 50 lines of logic in C# plus a bit of Excel for visualization. That’s no rocket science.

Multiple Black Boxes, Multiple Issues

So far the story about the Magic Black Box assumes you as a PO only get one. Since each Black Box probably works best on a single issue at a time, features get implemented in a sequential way.

That’s great for a single project. Work-in-progress is naturally kept to 1. All issues get implemented in the fastest way possible.

But if there are multiple POs working on parts of a larger project and each one was presented with a black box… How can a prediction for the whole project be done? Multiple black boxes surely are working in parallel. Releases get crunched out in parallel.

Maybe 3 POs with their black boxes are supposed to deliver 10 features. How long is that gonna take? For a single black box working sequentially simulation would deliver a result like this:

10 features would take 44 days (or less) with a a probability of 82%.

But that does not take into account any work done in parallel. Working independently on multiple features at the same time sure should take less time. But how much less? How to forecast simultaneous work?

Throughput Instead of Cycle Time

When measuring the productivity of several resources the metric switches away from cycle time. When work starts on an issue K it’s not clear if issue K is the next one to get finished (regardless of the cycle time). Maybe issue J or H is the next to be released.

Hence, what’s more interesting than cycle time is throughput: How many features get finished in a period of time (e.g. a day or a week)?

You can get throughput data from your historical cycle time data if you recorded when a work item got fed to a resource (here: issues to multiple black boxes) and when it was „spit out“ finished:

In this excerpt from a cycle time log, for example issues A and B entered „production“ on July 1st, but A left it on July 3rd and B on July 4th. Their cycle times were 3 and 4 days. Other features just took 2 days, e.g. D, others 10 (M). (Never mind that each day on the table seems to be a work day; no weekends included for simplicity.)

Throughput is not interested in how long each issue takes from start to finish, but how many items get processed and leave the system in a given time period.

As you can see, not every day issues got finished according to the above log. But on some days 1 was released, on others 2 or 3.

Throughput values like cycle time values thus have a frequency distribution:

Simulating Parallel Work

To simulate the production multiple black boxes can achieve, the approach is slightly different. Frequency values don’t get added, but subtracted. A single simulation looks like this:

Pick a throughput value from the list of historical data in the granularity of the relevant time period, e.g. days or weeks.

Then subtract the value picked from the number of features to implement, e.g. 10 features, 2 got picked, the number of remaining features is 8.

Do this until all features are finished, e.g. for 10 features that could look like this: 2:8, 0:8, 1:7, 0:7, 0:7, 1:6, 3:3, 0:3, 0:3, 1:2: 0:2, 0:2, 3:-1.

The number of picks needed is the number of days required to accomplish the features, e.g. 13.

Repeat this a 1000 or more times. The result again is a table of frequencies. But this time they stand for the total number of days needed until completion of the features:

The resulting histogram also again looks almost like a normal distribution:

And based on the percentiles from the table you can highlight the number of days you feel comfortable with for delivering multiple features with multiple black boxes at work. In this case it’s 16 days for 10 features with a risk of 15%.

Please don’t compare these 16 days to the above 44 days for 10 features with a single black box. Both are based on different datasets. They need to, since the above cycle times are just from a single black box. Multiple black boxes sure differ in their cycle time logs; and all those logs get merged. For a forecast it’s not important which black box did what. Only the overall throughput is of interest. The customer does not care which PO with her black box actually works on a feature.

Fin

Can you believe it? Black Boxes happily humming while implementing issues from Github backlogs, but mute, can still be used to deliver on time. You cannot ask them for an estimation - nevertheless you can make a prediction for when multiple features likely will be finished. (With „likely“ being a probability you choose according to your risk attitude.)

Think of all the time and energy saved by not arguing about estimations. Think about the blame avoided because nobody got the padding wrong.

Talking to developers about feature complexity is still worthwhile - but for a different reason. Don’t get prioritization mixed up with prediction.

Talk with developers about complexity and categorization to help you with prioritization.

Don’t talk with developers about estimations. They get it wrong 100% of the time, and everybody is feeling bad sooner or later.

Don’t look into a crystal ball. Look at facts, look at historical data. Do your math! Calculate a probability distribution (or histogram) and pick a number according to the risk you are willing to take. That’s entirely your choice (or whoever wants a prediction anyway).

And then don’t tell the developers about your deadline! That’s crucial. Only that way they will deliver all qualities required: functionality, efficiency, sustainability.

You can even pick two numbers, if you like. The probability distribution is clear. That’s an important improvement compared to any estimation you can possibly get. So pick a number to communicate to the customer, e.g. from the 95% percentile, and another number for internal use, e.g. from the 85% percentile.

After that: Lean back and watch the development unfold… No, don’t lean back. Walk around. Keep yourself informed about the progress towards your personal goal. Actively steer the development with ongoing re-prioritizations, scope reduction, impediment removal.

But don’t take just my work for it. Read the book on it: When Will It Be Done? by Daniel S. Vacanti. There’s more to „predictable software development.“

Fürs Leben lernen wir, nicht für die Schule. Und der Kunde steht stets an erster Stelle. So wird es doch immer wieder beteuert, oder?

Das halte ich für fromme Wünsche. Denn es kann nicht funktionieren. Mein Argument ist aber kein politisches, sondern ein strukturelles. Ich möchte ein Modell beschreiben, mit dem man so manche Verhältnisse erklären kann, über die man sonst nur ratlos den Kopf schüttelt.

Das versuche ich mal mit einer Reihe von Bildern zu erklären. Damit habe ich mich schon einmal in einer Artikelserie beschäftigt, doch damals sah ich noch nicht den Zusammenhang zwischen Schule und Unternehmen.

Die Beteuerungen sind naiv bis hohl, weil sie einen Zielkonflikt übersehen (wollen), der der fundamentalen Struktur der Organisationen Schule bzw. Unternehmen zugrunde liegt. Der sorgt dafür, dass nicht oder nur zufällig oder nur unter übermäßigem Aufwand das beteuerte Resultat entsteht: ein allseits gebildeter Schüler bzw. ein zufriedener Kunde.

Und dieser Zielkonflikt entsteht so…

Bedürfnisse motivieren

Warum tun wir freiwillig, gar selbstständig, was wir tun? Weil wir damit ein Bedürfnis befriedigen. Das ist meine hoffentlich nicht zu simple Weltsicht.

Unsere Bedürfnisse reichen vom Biologischen bis zum „Ideellen“. Manche können wir nicht länger als Sekunden leugnen, andere aber ein Leben lang. Zwischen manchen lässt sich die Befriedigung vereinbaren, zwischen anderen steht sie durchaus im Konflikt. Niemand hat gesagt, dass das Leben einfach sei.

Wenn wir ein Bedürfnis genügend stark empfinden, werden wir tätig, um es zu stillen. Wir interagieren im einfachsten Fall mit der „menschenleeren“ Umwelt. Indem wir auf sie Mühe aufwenden, ernten wir etwas als Lohn, der uns befriedigt.

Wenn ich Durst habe, stehe ich auf und hole mir etwas zu trinken. Eine geringe Mühe für ein lohnendes Glas Wasser. In anderer Situation ist vielleicht kein Wasserhahn in der Nähe, dann muss ich einen weiteren Weg zu einem Supermarkt zurücklegen. Oder in dürregeplagten Weltgegenden müsste ich womöglich viele Kilometer bis zu einem Brunnen laufen, um etwas zu Trinken zu finden.

Manchmal ist die Mühe sekundenkurz, manchmal sind Jahre nötig, um den Lohn der Mühe zu ernten, der ein Bedürfnis befriedigt (oder auch nur einen Wunsch erfüllt).

Selbstbestimmung bedeutet, dass ich wählen kann, welches Bedürfnis ich befriedigen will und wie viel Mühe ich bereit bin, dafür zu investieren. Ob es sich am Ende lohnt, mag ungewiss sein. Doch gerade in Selbstbestimmtheit nehmen Menschen auch Unglaubliches auf sich, um selbst bei geringer Erfolgsaussicht ein tiefes Bedürfnis zu stillen. Man kann ihnen nicht vorwerfen, dass sie „im Naturzustand“ faul oder unwillig seien. Nur muss eben die Motivation stimmen, d.h. ein Bedürfnis stark genug sein. Dann ist ihnen kein Weg zu weit, kein Berg zu hoch.

Bedürfnisbefriedigung in Interaktion

An diesem Grundsätzlichen Willen ändert sich auch nichts, wenn Menschen ihre Bedürfnisse nicht direkt an der „menschenleeren“ Natur stillen, sondern durch Interaktion mit anderen Menschen. Das geschieht zunächst auch ganz natürlich direkt:

Die Mühe des einen richtet sich hier auf einen anderen, der den einen dafür entlohnt. Die Mühe kann sich in einem Haarschnitt ausdrücken und der Lohn in einem Blumenstrauß. Oder die Mühe besteht darin, ein Geschenk zu basteln, und der Lohn in Begeisterung und einer Umarmung. Oder jemand macht sich die Mühe, einem anderen bei der Ernte zu helfen, und erhält dafür Kost und Logis.

Etwas speziell wird es dann jedoch, wenn der Lohn der Mühe Geld ist. Denn Geld ist in unserer Gesellschaft das universelle Mittel, um ganz verschiedene Bedürfnisse zu erfüllen, die man im Moment der Mühsal womöglich noch gar nicht spürt.

Bei einer solchen Interaktion will ich den bedürftig Bemühten Produzent und den belohnenden Empfangenden Kunde nennen.

Für mich ist das im Grunde die Definition von Selbstständigkeit in der Arbeitswelt: Wer ein Produkt genau an den liefert, der genau ihn mit Geld genau für das Produkt entlohnt, ist selbstständig. Denn er kann entscheiden, wie er das Produkt gestaltet und welchen Lohn er dafür angemessen findet, den er mit dem Kunden dann auch aushandelt.

Vielschichtige Tauschbeziehungen

Insbesondere in der Interaktion zwischen Produzenten und Kunden scheint es mir nun so, dass der Austausch nicht immer nur aus dem Offensichtlichen, d.h. Produkt bzw. Lohn besteht. Mehr schwingt und fließt zwischen den Menschen.

Die Mühe, des Produzenten, die sich in der Qualität seines Produktes äußert, befriedigt womöglich nicht nur ein materielles Bedürfnis (z.B. Hunger) beim Kunden, sondern auch ein immaterielles (z.B. den Wunsch nach Respekt).

Und der Lohn, den der Kunde dem Produzenten zahlt, befriedigt womöglich nicht nur zukünftige materielle Bedürfnisse, sonder auch immaterielle (z.B. den Wunsch nach Selbstwirksamkeit).

Das, was zwischen den Parteien fließt ist also mehrschichtig, bunt - und das befriedigende Mischungsverhältnis kann sehr individuell und nicht unbedingt offensichtlich sein.

Die Bedürfnisse der Menschen sind vielfältig, warum sollten die Interaktionen zu ihrer Befriedigung also nicht vielschichtig sein?

Dennoch: primär ist, wenn es sich um Produzent und Kunde handelt, der finanzielle Lohn. Andere lohnende Rückflüsse ergänzen ihn nur oder kompensieren bis zu einem gewissen Grad, falls er geringer als gewünscht ausfällt.

Unternehmen als Interaktionspartner

Die Verhältnisse ändern sich nicht grundsätzlich, wenn Unternehmen die Interaktionspartner sind.

Als „soziale Organismen“ (oder Organisationen) haben sie ebenfalls Bedürfnisse, die sie in Interaktion befriedigen wollen. Lediglich der Lohn für ein Unternehmen scheint mir hier reduzierter auf das reine Geld.

Wie es mit den Menschen im Unternehmen aussieht, ist eine andere Sache. Dazu unten mehr. Zunächst möchte ich Unternehmen als Black Boxes betrachten. So treten sie auf dem Markt auf: B2B wie B2C.

Interaktionsstrukturen

Die „Interaktionsatome“ sind die zwischen Begierigem/Bemühtem und Entlohnendem, sei das „menschenleere“ Natur, Mensch oder Organisation.

Aus ihnen lassen sich allerdings beliebige größere Strukturen zusammensetzen, in denen Beteiligte beide Rollen spielen:

In ihnen gibt es dann z.B. Produktionsketten:

oder es gibt Aggregations- bzw. Integrationsleistungen:

Kunden können mehrere Produzenten entlohnen:

und Produzenten können mehrere Kunden bedienen:

Entlohnung auf Augenhöhe

Egal wie Interaktionsstrukturen zwischen „Marktteilnehmern“ aber aussehen, sie sind grundsätzlich auf Augenhöhe; alle Beteiligten sind selbstständig. Kunde und Produzent stehen in direktem Austausch: der Produzent liefert an den Kunden, der Kunde entlohnt den Produzenten. (Das gilt auch, wenn die Leistung des Produzenten im Handel besteht. Ich verstehe Produktion hier sehr allgemein als Aufwendung einer Mühe gegen Geld. Handeln macht auch Mühe.)

Der Produzent bekommt „am Markt“ unmittelbares Feedback vom Kunden. Das kann in einer mehr oder weniger prompten oder vollständigen Entlohnung bestehen. Oder es wird als zusätzliche Schicht dem Lohnfluss hinzugefügt. Der Produzent wird nicht nur befriedigt, sondern kann sein Produkt dem Kunden - d.h. dem Bedarf, der Nachfrage - anpassen. Will der Produzent weiterhin und mehr Geschäfte mit Kunden machen, ist er gut beraten, dieses direkte Verhältnis auszunutzen. Sensibilität den Kundenwünschen gegenüber und prompte, hochqualitative Produktion helfen, die eigenen Bedürfnisse zu befriedigen.

Das unmittelbare Verhältnis auf Augenhöhe zwischen Produzent und Kunde speist sich aus intrinsischer Motivation beim Produzenten. Zu beobachten ist das sehr schön auf jedem Wochenmarkt.

Dies gilt auch für „B2B“-Interaktionen innerhalb von größeren Strukturen:

Zwar hat der Produzent hier nicht mit dem Endkunden zu tun, sondern „nur“ mit einem weiteren Produzenten. Doch im direkten Verhältnis ist das einerlei. Dem Produzenten von Schnürsenkeln ist ein Verkauf an Schuhhersteller prinzipiell genauso recht wie an Schuhkäufer. Der höheren Marge bei diesen stehen z.B. größere Abnahmemengen bei jenen gegenüber. Das will abgewogen werden. Am unmittelbaren Verhältnis zu beiden ändert das nichts.

Unternehmensstruktur

So weit die Verhältnisse zwischen „Marktteilnehmern“. Sie sind alle unmittelbar und somit intrinsisch auf Produktqualität konzentriert, die zum Preis passt, so dass die Bedürfnisse des Produzenten befriedigt werden.

Der Fokus ist hier auf dem Produzenten, weil der durch seine Bedürfnisse angetrieben wird, aktiv zu werden, d.h. Mühe aufzuwenden oder gar etwas zu produzieren und dafür Kunden zu finden. Der Produzent investiert Mühe in Hoffnung auf Lohn. (Dass Produkte dann Bedürfnisse bei Kunden befriedigen, wofür die willens sind, zu entlohnen, ist eine genauso valide Sicht. Ich nehme sie hier nur nicht ein. Das Henne-Ei-Probleme gehe ich einfach mal von der Henne, dem Produzenten aus an.)

Unternehmen verstanden als Organisationen, d.h. soziale Systeme bestehend aus mehreren Menschen zum Zwecke der Produktion gegen Geld, haben nun eine interessante interne Struktur. Die ist ganz bewusst anders gestaltet als Strukturen zwischen Marktteilnehmern.

Unternehmen bestehen mindestens aus zwei Funktionskategorien. Ich will sie Führung und Operation nennen.

Die Operation wendet die Mühe auf, um Kunden zu befriedigen. Und die Führung definiert die Rahmenbedingungen dafür. Vor allem aber ist die Führung in meiner Betrachtung die Funktion, die das Geld des Kunden empfängt! (Nicht persönlich, aber stellvertretend für das Unternehmen.)

Das ist zentral: Die Operation leistet und die Führung kassiert.

Von außen ist das nicht sichtbar. Dem Kunden tritt das Unternehmen als Black Box entgegen. Er soll gewöhnlich nichts über seine Struktur wissen. Solange das Unternehmen ein preis-wertes Produkt liefert, bezahlt er den Preis. Der Kunde sieht im Grunde keinen Unterschied zwischen einem Unternehmen oder einem Einzelunternehmer/Freelancer, wo Führung und Operation in einer Person zusammenfallen.

Doch diese andersartige Struktur von Unternehmen intern macht einen gewichtigen Unterschied!

Innerhalb von Unternehmen gibt es keinen Markt.

Bedürfnisbefriedigung (vermittelt durch Lohn), gibt es nur grundsätzlich gegen Mühe, also eine Leistung. Und die wird immer erbracht gegenüber dem Entlohner. Warum sonst sollte der auch entlohnen?

Genauer betrachtet sehen die Verhältnisse in Unternehmen daher so aus:

Ich möchte fast sagen:

Die Verhältnisse in Unternehmen sind systematisch „widernatürlich“.

Die ursprüngliche Selbstständigkeit ist verschwunden. Sie ist ja erkennbar an der unmittelbaren Produkt-gegen-Lohn-Beziehung. In Unternehmen existiert die jedoch nicht.

Lohn gibt es in Unternehmen nicht für Produkte! Lohn gibt es für die Einhaltung eines Arbeitsvertrags.

Im Arbeitsvertrag stecken zwar irgendwie die Produkte, aber mehr nicht, nur irgendwie.

• Der, der Mühe aufwendet, bekommt dafür keinen unmittelbaren Lohn vom Kunden. Die Feedbackschleife ist unterbrochen.
• Der, der entlohnt wird, hat dafür nichts direkt geleistet. Die Feedbackschleife ist unterbrochen.
• Der Lohn für die Mühe der Operation kommt intern von der Führung. Aber was bekommt die Führung dafür? Die Feedbackschleife ist unterspezifiziert.

Damit sollte klar sein, dass es interne Kunden in Unternehmen per definitionem nicht geben kann. Egal, was ein Angestellter für einen anderen leistet, nie zahlt dieser jenem einen Lohn dafür.

Noch schlimmer werden die Verhältnisse, wenn die Unternehmensstruktur sich weiter ausdifferenziert, d.h. die Produktionskette länger wird und deshalb vermeintlich darüber eine Führungshierarchie aufgerichtet werden muss:

Positionen tiefer in der Hierarchie und weiter vom Kunden entfernt rücken von der grundsätzlichen Produzent-Kunde-Beziehung immer weiter ab. Sie sind aus der natürlichen Feedbackschleife ausgekoppelt. Ihre Leistungsbeziehungen haben weniger und weniger mit dem Kunden des Unternehmens zu tun, sondern sind zunehmend rein intern. Selbstbeschäftigung entsteht, die man Bürokratie nennen kann. Arbeit wird nicht horizontal auf das Produkt fokussiert, sondern vertikal auf die Hierarchie im Unternehmen.

Intern fließt das Geld nicht mehr aus Richtung des Kunden zurück durch die Operationsstruktur. Darin gibt es keine intrinsische Motivation in Bezug auf das Produkt, jedenfalls keine natürliche durch Geld motivierte. Denn das Geld kommt nicht „von vorne“, d.h. Operationseinheiten downstream zum Kunden hin. Das Geld kommt ausschließlich von oben. Es gibt ja keinen Markt.

Und wofür gibt es Geld von oben? In der Führungshierarchie sitzen keine Kunden, die am Produkt interessiert sind.

Gegenüber der Führungshierarchie ist nicht die Mühe entscheidend, die ins Produkt gesteckt wird, sondern die Mühe, die gegenüber der Führungskraft aufgewandt wird. Diese Mühe jedoch ist eine kategorial andere als die, die ins Produkt geht.

Das „Produkt“ gegenüber Führung ist nicht das Produkt, das zum Kunden fließt, sondern… Gehorsam: Gehorsam gegenüber Regeln - ausgesprochenen und unausgesprochenen - und Metriken.

Für Gehorsam wird Lohn an abhängig Beschäftigte gezahlt.

Angestellte sind abhängig Beschäftigte, weil sie eben keine Freiheit besitzen, ihre Leistung auf einem Markt anzubieten, sobald sie sich einem Unternehmen per Anstellungsvertrag verpflichtet haben; sie sind eben nicht selbstständig. Das Produkt ihrer Mühe und die Empfänger ihrer Mühe werden durch die Führung vorgegeben; dafür werden sie entlohnt. Angestellte sind also zuallererst Weisungsempfänger der Unternehmensführungshierarchie.

Der Begriff „Gehorsam“ wird Ihnen aufstoßen. Ich habe ihn aber mit Bedacht gewählt, um genau dieses gedankliche Stolpern zu erzeugen. Er soll wachrütteln; er soll die Augen öffnen für die wahren Verhältnisse innerhalb von Unternehmen. Wenn er Ihnen aber zu quer sitzt, ersetzen sie ihn durch „compliance“; Englisch klingt das Verhältnis vielleicht etwas businessmäßiger, weniger deutsch-historisch beladen. Aber machen wir uns nichts vor: Solange von disziplinarischen Vorgesetzten gesprochen wird, geht es auch noch um Disziplin und Gehorsam.

Es gibt unternehmensintern keine Kunden, auch wenn der „interne Kunden“ noch so sehr beschworen wird, um irgendwie marktähnliche Verhältnisse zu suggerieren.

Es gibt unternehmensintern keine intrinsische Motivation, ein Produkt zu verbessern. Jedenfalls keine, die durch Geld vom Kunden motiviert würde. Es fehlt schlicht die direkte Beziehung zu ihm. Einzige Ausnahme vielleicht: der Operationsaspekt „Verkauf“. Deshalb gibt es dort auch durchaus erhebliche Provisionen. (Allerdings ist der Verkauf dann wieder von der Produktion entkoppelt. Das macht die Sache also nur vordergründig besser.)

Es gibt unternehmensintern lediglich die Motivation genügend zu tun, um als pflichtbewusst (aka gehorsam) beurteil zu werden – damit der Lohn weiterhin fließt.

Umso mehr gilt das aus meiner Sicht, je größer die Unternehmensstruktur ist und je weiter innen Mitarbeiter in ihr angesiedelt sind.

Das bedeutet im Umkehrschluss: die Kunst der Führung besteht in der Motivation der Mitarbeiter in einer Weise, dass deren Mühe Produkte von hoher Qualität herstellt, obwohl (!) das Hauptaugenmerk aller Mitarbeiter auf der Beziehung zur Führung liegt und nicht auf der zum Kunden bzw. anderen Mitarbeitern downstream Richtung Kunde.

Regeln und Metriken müssen so gewählt werden, dass pflichtschuldiger Gehorsam preis-werte Produkte hervorbringt.

Und nicht nur das! Denn Produkte sind nicht die einzige Leistung von Mitarbeitern. Sie sollen darüber hinaus auch noch etwas anderes herstellen: Veränderungen. Mitarbeiter sollen gerade heute ja auch innovativ sein und willig und fähig, „Change“ aller Art mitzumachen.

Das Kunststück von Führung wird mit jedem Tag größer, würde ich sagen. Geradezu unglaublich, dass Unternehmen überhaupt so funktionieren. Ja, wie kann das sein?

Ich glaube, es liegt an der Vielschichtigkeit von Lohn. Abhängig Beschäftigte empfangen nicht-monetären Lohn im Rahmen der Unternehmensstruktur und auch von außerhalb aus vielen Richtungen.

Allerdings dort, wo es diesen inoffiziellen „lohnenden Rückfluss“ nicht gibt… da allemal droht mindere Produktivität durch Dienst nach Vorschrift, Unachtsamkeit und mangelnde Qualität oder gar Burn-Out.

Und da, wo inoffizieller, unsichtbarer Lohn fließt, sind die Verhältnisse nur schwer zu kontrollieren. Denn wo ansetzen mit einer Intervention, wenn sich etwas verändern soll? Die Situation ist gerade dann sehr komplex, weil die Motivationsverhältnisse unklar sind.

In einer Tayloristischen Organisation, die nur über Geld motivieren will, steckt also schon einige Weisheit. Nur funktioniert es nicht (mehr) so. Weil die Angestellten mehr wollen als Geld. Weil die Kunden mehr wollen, als die Qualität und die Reaktionsfähigkeit, die solche simplifizierten Unternehmen herstellen können.

Der Zielkonflikt

Der Zielkonflikt besteht zwischen den zwei Empfängern von Mühe, denen sich jeder Mitarbeiter gegenüber sieht.

• Soll er sich für den Kunden Mühe geben, sich downstream orientieren?
• Oder soll er sich für die Führungshierarchie Mühe geben, sich orthogonal zum Produktionsfluss orientieren?

Das ist nicht dasselbe, auch wenn sich Führung darum bemüht oder etwas anderes suggeriert. Es gibt den Winkel ϕ immer. Fragt sich nur, wie klein ihn Führung machen kann.

Im Zweifelsfall siegt denn auch die Mühe gegenüber der Führung. Die Oberhand wird im offensichtlichen Konfliktfall der Gehorsam haben. Helden sind einfach so selten. Gehorsam einen Kundenwunsch nicht zu erfüllen findet im Verhältnis mehr Akzeptanz (bei der disziplinarisch relevanten und belohnenden Führung) als ungehorsam nicht belohnende Kunden zufrieden zu stellen.

Wann immer es heißt „Da kann ich Ihnen leider nicht helfen, das ist bei uns so Vorschrift.“ sollte das sonnenklar sein. Behörden und große Unternehmen sind dafür bekannt. Aber auch bei kleinen Unternehmen kann man solche Antworten erhalten.

Die Aufgabe von Führung besteht nun darin, würde ich sagen, den Winkel (ϕ für „Führungswinkel“) zwischen den „Zielrichtungen“ möglichst klein zu gestalten. Je weniger „in Linie“ (aligned) die Mühe in Richtung Hierarchie mit der Mühe in Richtung Kunde (downstream) ist, desto weniger Energie kommt dem Unternehmensprodukt zugute.

Das funktioniert umso besser, je mehr Führung tatsächlich „hinter dem Kunden steht“. Poster an der Wand mit markigen Sprüchen, sind dafür allerdings ungenügende Lippenbekenntnisse.

Abteilungen vs. Prozesse

Umso größer ist das Gewicht des Gehorsams für die täglichen Entscheidungen jedes Mitarbeiters, je vertikaler ein Unternehmen organisiert ist. Wo Abteilungen die vordringliche Organisationsform sind, wird schlicht informelles Feedback unterdrückt. Und auch der Produktionsfluss muss immer wieder Barrieren überwinden.

Eine Rückkopplung entlang des Produktionsflusses ist hier schwierig. Eine Operation im Sinne kundenorientierter Prozesse existiert quasi nicht. Wie soll da auch noch immaterieller Lohn upstream schwimmen?

Das ist umso schlimmer, je mehr die Produktion nicht nur „durch Wände“ arbeiten muss, sondern auch noch die Hierarchie entlang. Führungskräfte sind gern mal in Doppelrollen unterwegs als „Expertenfachkraft“ plus Führungskraft. (Verständlich ist das, da ja oft Führungskräfte früher tiefer in der Hierarchie als operierende Fachkraft tätig waren. Davon kann man später nur schwer die Finger lassen. Allemal scheint aber auch die Einmischung in die Produktion dem Bild nach oben zu dienen. Ist das nicht pflichtschuldiges Handeln, Dinge zu kontrollieren und anzuweisen?)

Anders ist das, wenn Produktionsprozesse im Vordergrund stehen.

Hier hat immaterielles Feedback eine Chance, zu befriedigen und zu motivieren. Cross-funktionale, kundenorientierte Organisation hilft, die negativen Effekte von Hierarchien zu mildern.

And now for something completely different… (or maybe not)

Die Hierarchie des Lernens

Natürliches, intrinsisch motiviertes Lernen findet unmittelbar gegenüber den Lerngegenstand statt:

Der Lohn der Mühe besteht in positivem Feedback. Neugierde wird befriedigt, Wissen wird gewonnen, Fähigkeiten werden erworben.

Lernen verändert sich jedoch grundsätzlich, wenn der Lernstoff erstens nicht selbst gewählt ist und zweitens das Feedback in Form von Zensuren gegeben wird. Lernen in der Schule ist eine ganz eigene Sache:

Wie beim abhängig Beschäftigten ist hier das natürliche Verhältnis aufgebrochen: der Lohn für die Mühe kommt nicht aus der Sache, sondern aus einer anderen Quelle, dem Lehrer. Und es wird dafür eine „Währung“ eingeführt: Zensuren.

Die Verhältnisse ähneln denen in Unternehmen. Es gibt eine Hierarchie, die in die natürlichen, unmittelbaren Verhältnisse eine Indirektion einführt. Dort stellt sich dem Feedback Führung in den Weg, hier der Lehrer.

Und auch in der Schule stellt sich die Frage, was die Mühe des Schülers gegenüber dem Lehrer ausmacht.

Die Mühe des Schülers besteht in angepasstem, zensurenoptimierendem Verhalten. Zensuren sind ja nicht nur das Produkt solider Kompetenz, wie die Schule es sich vielleicht wünscht. Nein, Zensuren können optimiert werden durch spezielles Verhalten, das nichts mit der Beherrschung des Lernstoffs zu tun hat. Das kann explizit gegenüber dem Lehrer sein; das kann aber auch darin bestehen, mit dem Lernstoff in bestimmter Weise umzugehen. Wer für gute Zensuren lernt, der lernt anders als für „Lebenskompetenz“.

Allemal wird diese Zensurenoptimierung plausibel, wenn man die Umwelt einbezieht, die in Zensuren belohnenswerte Mühe sieht:

Der Zielkonflikt

Der Zielkonflikt beim schulischen Lernen besteht im Lernen für gute Zensuren vs Lernen für’s Leben, d.h. für echte Kompetenz und Retention.

Eine gute oder schlechte Zensur - allemal für einen nicht selbst gewählten Lernstoff - ist etwas anderes, als das unmittelbare Feedback, wenn man sich an einem selbst gewählten Problem versucht.

Das hat man in der Schule inzwischen auch durchaus erkannt. Fächerübergreifendes, projektbezogenes Lernen nimmt zu, um die Motivation durch Steigerung der Relevanzempfindung zu erhöhen und das Behalten durch Vernetzung verschiedener Sinneskanäle und Themen zu fördern. Auch Zensuren scheinen hier und da auf dem Rückzug.

Einstweilen jedoch sind Zensuren noch das vorherrschende Mittel für Feedback, mündliche wie schriftliche. Und damit befinden sich Lernende in einem irreführenden und kräftezehrenden Zielkonflikt.

Aber vielleicht soll der sie auf die Unternehmenswelt vorbereiten?

Zusammenfassung

Mir scheint das wesentliche Merkmal eines Marktes die Freiwilligkeit und Selbstständigkeit. Austauschbeziehungen entstehen, wo Befriedigung möglich erscheint. Qualität entsteht, um Befriedigung aufrecht zu erhalten.

Wird der Markt jedoch ausgehebelt und die darin herrschenden unmittelbaren Beziehungen gekappt, d.h. werden die Freiheit beschränkt und die natürliche Feedbackschleife unterbrochen, dann sinkt die Qualität der Produkte. Und nicht nur die Qualität sinkt, es sinkt auch die Motivation in Bezug auf die Produkte. Der Blick wendet sich ab vom Empfänger der Produkte hin zum Belohnenden.

Es entsteht Verschwendung.

Statt die Mühe, d.h. die aufgewandte Energie wie einen Laser zu fokussieren, strahlt man sie in verschiedene Richtungen. Ohne „Marktverhältnisse“ werden Menschen allzu leicht zu Glühbirnen – die auch mal durchbrennen.

Eine Gesellschaft, die ganz allgemein immer weniger Gehorsam als Wert hat, die diskursiv sein will, kann sich an solchen hierarchischen Verhältnissen nur reiben. Die Menschen und auch die Aufgaben im Rahmen komplexer Produkte sind nicht mehr so, dass per Gehorsam die Energie vor allem der Sache zugute kommen würde.

Solange die Not des Einzelnen groß ist und die Sache einfach, mag es funktionieren. Beides ist aber nicht mehr der Fall. Deshalb hat aus meiner Sicht die disziplinarische Hierarchie, allemal die große, ausgedient.

Und was ist die Alternative?

Kleinere Einheiten. Unmittelbarere Verhältnisse. Aufgabe des Kontrollwahns.

Unternehmen wollen durch den Aufbau der internen Hierarchie etwas sparen und etwas gewinnen: weniger Transaktionskosten, die sie am Markt hätten, mehr Kontrolle, die sie am Markt nicht hätten. Das ist verständlich und funktioniert – aber eben nur bis zu einem gewissen Grad.

Hier gespartes Geld und gewonnene Kontrolle werden dort bezahlt mit zunehmender Inflexibilität, abnehmender Motivation, sinkender Qualität, untreuer Kundschaft.

Ich glaube, da hilft nur ein Umdenken: Das, was man als lästige Kosten am Markt ansieht, was man als Kontrollmangel empfindet, ist Schmierstoff, der flexibel hält. Und es ist nicht mehr Effizienz, an der es mangelt, sondern Flexibilität.

Es wäre schön, wenn Unternehmen wie Schulen sich wieder mehr auf die natürlichen, nährenden, motivierenden Beziehungen besinnen würden. Das sind für mich die, in denen der primäre Austausch stattfindet: beim Unternehmen der mit dem Kunden, beim Schüler der mit dem Lehrstoff.

Menschen sind willig zur Veränderung, wenn sie fühlen, dass das Sinn macht. Und Sinn macht, was erleichtert, Lohn zur Befriedigung der eigenen Bedürfnisse zu erhalten. Das bedeutet für mich im Umkehrschluss: Veränderungen funktionieren vor allem in Bezug auf lohnenswerte Mühe. Wer Veränderungen bei anderen anstoßen will, muss sich daher erstmal im Klaren darüber werden, welche Beziehungen die als lohnenswert empfinden – und ob das dieselben sind, die verändert werden sollen.

Sind das nicht dieselben, besteht ein Konflikt, der Leistungen und Veränderungen am Ziel vorbeischießen lässt.

There are already a few different styles of TDD out there. Still, though, my feeling is something is missing in the realm of test-first or test-driven development. I tried to explain that in my posting introducing the „Hamburg style TDD“. And then I showed what that meant in practice in a second article applied to the Diamond kata.

But knowing how hard it is to get the nuances (or even the obvious aspects) of a method across in writing (or with a video), I think I need to provide more examples of the application of Hamburg style TDD.

As a second example I’m choosing the kata Macro Emrich used to compare the established TDD styles: the Bank kata. If you like, check out Marco’s code samples in this presentation he did at the DWX 2019 conference.

Following I’ll share my version of the kata like I did with the Diamond kata. It differs from the Diamond kata in quite some aspects. Problem solving requires some breadth of approaches. Red-green-refactor + KISS is too simplistic.

Problem description

This is what I’ve distilled from descriptions of the Bank kata I found on the web. It’s a bit more specific than usual, I guess. But I like it that way. Without specific requirements software development is bound to become even more complex.

An excerpt from my in-project .md documentation of my „stream of consciousness“ while working on the problem:

A user should be able to deposit/withdraw funds from a bank 
account (object).
At any time a statement can be "printed" (requested) listing the 
timestamped transactions and the updated account balance.

Example:

`
Date       Amount  Balance
1.7.2019    +1000     1000
2.7.2019     -200      800
3.7.2019     +500     1300
`

Integer amounts are sufficient as are transaction timestamps with dates only.

No transaction is rejected, even if it leads to a negative account balance.

1. Analysis

With the problem description in hand I sit down and analyze it. I log my thoughts in a .md file. (The more I do that, the more I like it. It makes my thinking open for scrutiny.)

## Analysis
Essentially the problem is about an event stream for which a report 
is generated.

There are two commands:

* deposit
* withdraw

And a single query:

* print statement

For testing purposes and also as to not dilute the responsibility of 
the account the statement should not really be printed 
(output to a device), but just generated as a data structure.

For the timestamp the current time is used, ie. a dependency to the 
system is needed.

Transactions will not be persisted. An account's state will be limited 
to the lifetime of it's object.

### 1. Functions

#### Deposit command
`
void Deposit(int amount)
`

#### Withdraw command
`
void Withdraw(int amount)
`

#### Print statement query
`
Statement PrintStatement()
`

#### Classes
The request handling functions can be aggregated by a single class `Account`.

More classes are needed for the statement if access to the statement 
details is needed:

`
class Statement
    Transaction* Transactions
    
class Transaction
    DateTime Date // set by the Account class
    int Amount
    int Balance
`

### 2. Test Cases
`
Input  | State            || State'
Amount | Date   | Balance || Balance'
+100     1.1.19         0        100
+200     1.1.19       100        300
-50      2.1.19       300        250
-300     3.1.19       250        -50
`

This development of an account will be expressed in a growing 
statement (output) after each transaction:

`
v1
1.1.19,+100,100

v2
1.1.19,+100,100
1.1.19,+200,300

v3
1.1.19,+100,100
1.1.19,+200,300
2.1.19,-50,250

v4
1.1.19,+100,100
1.1.19,+200,300
2.1.19,-50,250
3.1.19,-300,-50
`

This time I came up with an acceptance test case of my own. It’s exercising not just one function, though, but all functions I derived from the requirements. The acceptance test thus is more like a whole use case.

Also note that this problem leads to several classes. In the Diamond kata classes were of no concern. But here they are needed to aggregate functions and data.

But the modularization is straightforward. It’s quite obvious, I’d say, because it is directly tied to the user’s needs. That’s why I would not say the classes are a product of design. I’m still in the analysis phase.

Maybe noteworthy is that I decided to not deliver a formatted textual account statement. Why should an account (object) care about report layout? It delivers a statement as a data structure some other part of a program can turn into a neatly layouted report.

Finally I encode my understanding:

There’s only one thing strange about this, I guess: why that kind of constructors on the Account class?

During analysis I identified a dependency of my system under test (SUT, or system under development): It depends on the current date since the statement contains a date in each transaction, but requesting the transactions (Deposit, Withdraw) does not pass in a date.

How could an automated test running on an arbitrary date have an expectation regarding transaction dates? Without making „date acquisition“ configurable that would be hard. Hence the public ctor for production, and the internal for testing. The public one sees to that the current date is used; but the acceptance test uses the internal one to pass in a substitute function to deliver a date from a fixed set for each transaction.

That makes the test case a kind of whitebox test because it encodes an assumption about how many dates are required. But in this case that’s not severe, I’d say. Four transactions, four dates: that’s pretty obvious.

2. Design

Starting from the analysis I do some design. That’s not much, though. The problem is very simple. It’s just that I stop for a moment to gather my thoughts…

## 2. Design
The `Account` class pretty much is an event stream with an 
aggregator attached.

* The commands add events to the stream. No checking is needed, all 
amounts are ok. But the date is added to the tx.
* The statement is an aggregation of the events in the stream where 
the balance is constantly updated.

The main functionality is statement generation. And within that it's 
updating the balance. That suggests a function (or even class of its own).

The event stream is a simple append-only list for (internal) transcactions.

// Open question: What should happen if a negative amount is passed to 
// `Deposit()` or `Withdraw()`?

After that I feel comfortable to start the implementation.

3. Implementation

Recording transactions

This is an article about some form of test-first development. So what I’m doing here when I start the implementation of the Account class might seem horrible to you: I write logic without a test. I start with production code right away.😱

But after my design recording transactions (functions Deposit and Withdraw) seems so simple that I don’t see much of a danger therein.

There really is not much to test anyway. And if I wanted to test the effect of each function I would need to look under the hood of Account; it would only work with more whiteboxing.

So I reason that in the end the correctness of transaction recording will show up immediately during statement production: If statement production is working, but delivers the wrong statements, then something must be wrong with recording transactions. In that case I would closer at the transaction methods.

One word about the Transaction class inside of Account: It looks similar to the same named class inside of Statement. Why two classes for transactions? Because their „nature“ (or purpose) is different.

Statement.Transaction is visible from the outside. It’s a class used for interaction with the system under development (a DTO). It’s subject to the user’s whim at any moment. I expect it to change due to changing requirements quite often.

Account.Transaction on the other hand is an event object. It’s for recording what’s happening to the state of an Account object. (Never mind that it’s not phrased in the past tense.) This class is purely internal, an implementation detail. It’s not under direct stress from user requirements. I expect changing requirements not to lead to changes there, rather more events will be needed.

Two classes with the same name is simply a matter of decoupling. That’s a good architectural style. It’s clean code in my view.

Or let me say it the other way round more bluntly: Clean code does not mean the least amount of code possible to implement some runtime behavior! Just because you see more code than you think is technically needed, does not mean it’s smelling. The question always is: Why? Why more core than fore the bare functional necessity? And the answer has to show that future readers are kept in mind.

Yes, future readers over future requirements. It’s not that I don’t value future requirements on the right, but I find concern for future readers more important.

Printing the statement

Printing the statement is what the whole kata is about. It’s the crucial part and I want to get it right. Also I want to be able to work on it straightforwardly and independently.

If I wrote a test for just the PrintStatement function, though, I would need to open the Account class in order to gain control over its state; PrintStatement is relying on that.

To avoid this hassle I decide to switch to TDD as if you meant it (TDDaiymi) from Keith Braithwaite. That means I use tests as my sole development environment; I won’t touch the production code until I’ve finished the functionality.

Also I’ll be moving forward with incremental tests since I’m not really sure how to solve this problem.

Iteration 1

Here’s my first iteration: What should the statement look like if there are no transactions yet? It should be empty.

I know this code looks pretty stupid. But it „simulates“ the situation in production: there are no transaction events (new Account.Transaction[0]). And the statement’s number of transactions mirrors that.

As simple as lines 13 and 14 might look, they are crucial and I expect them to stay the same in next test cases. They are like a seed to grow the solution from. There is a small insight encoded in them.

Iteration 2

The next incremental test is about just one transaction event. I set that up with fixed data in line 23:

Line 24 is the same as 13 in the first test. But it’s followed by a manual mapping of the transaction event to the statement transaction.

Line 28 is the only noteworthy line here: It could be reduced to accountTransactions[0].Amount, but by including 0 + I make clear right away that I know the transaction’s Balance is an accumulating value.

Iteration 3

When doing TDDaiymi I actually often create new test cases by copying previous test cases and only change the expectation first. That way it’s immediately red and I’m forced to solve the problem: adjust the test input data, then adapt the logic. This is what I’m doing for iteration 3, too.

Now it’s two transaction events to „print“. The expectations (58ff) and input data (40ff) are set up accordingly. Line 45 and 56 still match 13 and 14 of the first iteration as expected.

And in between I copy the mapping from the previous test and adapt the second copy by changing the indexes.

Plus I need to think about how to carry over the balance from the previous statement transaction (line 54).

Refactoring 1

My impression is I’ve solved the statement printing problem. I know how it’s gonna work. Now I just need to generalize it. Currently the number of transaction events is hardcoded. This is along the lines of the Transformation Priority Premise, I guess: (constant->scalar) and (statement->recursion).

I refactor the hardcoded solution to a variable solution:

The basic mapping stays the same (lines 50 to 54), but I move the balance update up because I want to use a variable for it (line 49).

The loop around the mapping is trivial: for each transaction event a statement transaction is created. The same as before, just automatically done.

Refactoring 2

With the refactored/generalized logic still getting the test to green I extract it to the production code. I’m confident it will work there, too:

The only adjustment I need to make is changing the source of the transaction events to the Account class’ global state _transactions.

With PrintStatement filled in I check the acceptance test. It should be green now - if the implementation of the transaction functions was correct.

And indeed it is!🎉

Problem solved.😎🕺

Refactoring

What’s left is to restrict the accessibility of functions and classes to private where necessary. The surface of the production code should be minimal.

That’s only affecting the Account.Transaction class which I set to internal while going through the TDDaiymi iterations.

Now that it’s hidden, however, the TDDaiymi test becomes flagged. The incremental tests cannot be compiled anymore. Their true nature is revealed: they were scaffolding tests all along. That means they now have to be deleted.

The acceptance test remains as the only test. That makes me free to refactor the solution below the surface at any time without breaking tests targeting details.

Summary

This problem required a somewhat different treatment compared to the Diamond kata: not writing tests for functions, doing TDDaiymi… That might feel new or uncomfortable to you. But I stand by my opinion: it’s legitimate, it’s even easier than sticking to one of the other schools of TDD.

In the end it’s all about the result. How straightforwardly can you move towards functional and clean code? If ADC and TBC can help, then you should employ them.

But Hamburg style TDD actually is not in opposition of Chicago style etc. Rather it’s embracing them all - and adding a twist. This twist is the recommendation to do explicit analysis and explicit design and to avoid functional dependencies. And that in turn leads to tests with no (or less) need for substitutes, i.e. less complexity.

In a previous article I tried to explain why I’m not satisfied with the existing schools of TDD: They are not really tapping the developers’ capability to think. At least for my taste. Or to say it more bluntly: They are dumbing down developers.

Sure, their motivation behind that is honorable. And they all assure us of still, no, hence getting to the best possible code result. Nevertheless I think this is doing productivity a disservice.

Mileage always varies with different approaches, but for me the mileage so far has been too low with the established TDD styles. That’s why I came up with yet another one. I call it eclectic because it’s drawing from all sorts of approaches. And I might even not call it a programming style but a problem solving style.

In my previous article I explained why I think TBC (Thinking Before Coding) and ADC (Analyse, Design, Code) are so important. But what does that mean when applied to concrete problems?

Here’s a first problem I tackled to demonstrate this. I chose the Diamond kata because the originator of the Munich style TDD, David Völkel, was mentioned in a recent tweet teaching his style using this kata.

Let’s start…

Problem description

First a problem description as I found it on the web:

Given a letter, print a diamond starting with ‘A’ with the supplied letter at the widest point.

For example: print-diamond ‘C’ prints

..A
.B.B
C...C
.B.B
..A

(The dots '.' are just placeholders for spaces ' ' to make the result more clear.)

1. Analysis

The first thing I do when faced with a programming problem is… I’m trying to understand it. Sure that’s also advocated by other TDD styles. But exactly does that mean? What’s the result of analysis?

Analysis is the activity which in my view is supposed to produce understanding. But how to document my understanding?

In the end there is no unambiguous understanding except when I’m able to solve the problem (or very similar problems in the same problem class). That means any software I produce needs to be able to do the same. Otherwise I might have understood, but wasn’t able to encode my understanding.

Translated into code that means analysis results in two things:

• examples of successful problem solving (aka test cases)
• functions that actually show the behavior as described in the examples.

I usually document my understanding in a file next to the code. In this case I used a .md file:

You see, first there is some text explaining what I gleaned from the problem description. An important aspect of that are terms of the domain language.

But then there is a function and test cases. They are the real expressions of my understanding.

The sample problem is so easy, however, I did not come up with my own test case. But if it’s more complicated I will go beyond whatever has been presented by the client.

My analysis is complete once I really get my insights encoded as acceptance tests and the signatures of behavior delivering functions:

I don’t need to know how to create the results. Just the surface of my „system under development“ needs to be clearly specified.

That’s easy in this case of course. But what if I had a hard time to come up with an interface? Isn’t TDD supposed to help with that?

Well, my view is: As long as you don’t know which functions should provide the requested services, you should not touch your production code. You’re not even in a situation to write tests.

Lack of clarity of the interface is a clear sign of „chaos“ (in your head or the client’s head). And when in chaos the first thing to do is: act!

In the case of programming that means whipping up a REPL or some other scratchpad and start „drawing“, start experimenting. Play around with interfaces all you want. Write a whole prototype, even.

But don’t touch your production code! Not even backed by a test. Otherwise you’ll later on be sorry because you have to go through much refactoring. And that’s always putting strain on your codebase.

The remedy to cluelessness is not refactoring! As long as you don’t have a clue how a system under development’s surface should look like, you’re clueless. You can’t even come up with clear cut test cases.

It’s time for a different mode. Not the test-first mode, but an experimentation mode outside production code.

Luckily that’s not the case for the Diamond kata, though. That means my analysis is complete.

Bottom line: For me TDD always means ATDD (Acceptance Test-Driven Development). Don’t start work on production code before there is an acceptance test, i.e. a comprehensive test describing the required behavior.

An acceptance test to me is a guiding light or a north start. Once the acceptance tests are going green I know my job is done. I don’t mind them staying red for a longer while. I simply don’t execute them all the time ;-)

2. Design

With the acceptance tests implemented I continue by TBC. I ask myself:

1. Can I partition the overall problem into smaller, complementary problems which I then solve independently?
2. Are there simpler problems nested inside the overall difficult one? Can I find a list of incremental tests?

The second step is what TDD originally was about, I think. In my view, though, this only works well for very simple problems. It’s a not to be neglected question, but in my approach is not the first one to ask.

My first step is to look for more or less obvious sub-problems which I can solve more or less independently - hoping that the solutions to the sub-problems later can be integrated into a solution for the overall problem. Each sub-problem again will be represented by a function responsible for some partial behavior.

I’m using the good old „stepwise refinement“ approach, you could say. I’m recursively descending a problem tree.

And why not? Just because it’s an old approach doesn’t mean it’s not fit for the modern world.

But I’m using it with a twist! And that’s quite important for the clean code goal. My function hierarchies are free of functional dependencies. I’m not distributing logic vertically all over the hierarchy, but lump it together in the leaf functions, called operations according to the IOSP (Integration Operation Segregation Principle). That’s making a huge difference for understandability and testability!

Here’s what I came up with as a design for the Diamond kata:

It’s more precisely documenting my understanding of the problem and delivering a model for the implementation.

The model consists of yet more functions, but in addition to that also relations between those functions.

• There is a hierarchical relation: The original user facing function, the root function of the function tree depends on the other functions.
• There are before-after or sequence relations: The partial functions will need to be called in a certain order.
• There is an implicit aggregation relation: All functions will belong to the same module (class).

Noteworthy of this kind of design is the absence of loops! To declarative and on a high level of abstraction a model needs to be free of imperative loops. Looping will occur in the end, but in the model it’s hidden.

This design process maybe takes me 10 minutes. The most effort goes into actually writing the results down for the purpose of this article.

Why should I not invest this short time up-front for design? It’s easy, and it delivers starting points for further tests. I don’t need to drive the implementation through the root function. That, to me, would feel artificial, and not simpler. And I would have to refactor more.

My design will produce clean code, I’m confident. Because the implementation will follow the IOSP.

Growing logic by applying tests primarily to the root function (and later refactor) is like growing a Bartlett inside a bottle. I call that pear programming.

Source: Wikipedia

It can be done. It’s a piece of art, maybe. But I find that hard. The harder the more logic this way should be developed. Because that way it’s impossible to target pieces of logic with tests. All logic is always under test - unless you swap it out with substitutes.

Substitutes, though, to me are additional complexity I want to avoid! I’m not saying they should not be used. But to base a programming approach on them is not my cup of tea.

A KISS for design

One argument against my approach, I hear, is that I’m not doing the simplest thing possible. Starting with a trivial test (even a degenerate test case) and then answering that with maybe only a singe line of production code would be much, much simpler. And it would immediately deliver a (small) value. And it would guarantee that no production code gets written without being covered by a test.

By now you can imagine: I beg to differ.

In fact I think my kind of design is the simplest thing you can do. I’m following the KISS principle to the letter.

Why? Because I don’t even implement a single line of code (at first). What’s simpler than writing code? Not writing code! That’s faster, that does not produce waste which later needs to be refactored.

Designing by stepwise refinement, by dissecting large problems into smaller ones is so simple because it „assumes“ that certain „services“ will be available. It does not care how they are going to be implemented. That’s details to wreck your brain about some other time.

The above list of functions is a wish list. I’m wishing for help: „How nice it would be to have a function that does X…“ or „What a relieve it would be to not worry about problem Y anymore because a function is taking care of that…“

If I cannot simplify a big problem by at least coming up with two partial problems which are smaller I guess I don’t really have a clue about what’s going on in the first place. Either I can solve a problem by writing the logic – or I can solve it by dissecting it into smaller, complementary problems.

With regard to the Diamond kata wishing for help could run like this:

• „Oh, there is a single input letter, but the diamond consists of multiple letters up until the input letter. I wish there was a function taking care of getting me this list. The rest then can be accomplished by another function.
• „Hm… given a list of letters I need to generate the layers of the diamond. Half of them are unique. It would be nice to have a function doing that. Another one could then take care of building a full diamond from them.“
• „Now that I have a list of letters the hard part is to generate a single layer with the right spacing. I wish there was a function for that. Generating layers for all letters then is simple based on that.“
• „The most difficult thing about a layer is to get the number of leading spaces and separating spaces right. There should be a function calculating that for each layer. Arranging the letter in a layer based on that info then would be easy.“

I find this most simple. And if it’s not then I need to double down on thinking the problem through or maybe go back to analysis. Not being able to come up with a „functional design“ to me is the first sign of cluelessness. I would not recommend to touch production code in such a state of mind.

3. Implementation

After design all’s prepared. At least that’s true in this simple case. I know all the functions that will be needed. I’ve a good feeling about this. If the problem was larger I would not have refined the whole function tree down to the last operation. Remember: I’m all for iterative and incremental progress. TBC with ADC is not about a resurrection of the waterfall.

Backed by the acceptance tests I now implement the functions I „uncovered“ during design in any order. I could start with the seemingly simplest or simply with the first one. It pretty much does not matter.

Determine the layers

The partial problem of determining the number of layers with their respective letters (layer names) I attack using… incremental tests. Inside my approach I’m using pretty much Chicago style TDD. You see why I’m calling it eclectic?

I come up with two tests growing in difficulty and implement the production code by going red-green-red-green.

There is nothing to refactor after the first test and not even after the second test. The function is so focused, so small.

You might find that the code to get the second red test to green does not seem simple. If so I say: To hell with simplicity! At that point I had a clear idea of how to solve the problem once and for all. Why not just write it down?

I could have used another test to drive out some pattern and refactor… but with this kind of small problem that seemed too much effort.

Or if you find the implementation lacking with regard to null boundary checks let me say: To hell with defensive programming! It’s not the responsibility of this function to check if the seed is in a certain range. If so, it just fails. There is not even a requirement to behave in a certain way in such a case. Why should I implement a solution to a non-existing requirement?

Defensive programming, I have to say, often is a form of procrastination. It’s applied to postpone solving the hard problems. It’s applied to ward off „friendly fire“ from code other team members might write. It thus is a substitute for the right thing to do: Doing real thinking about the real problem and drawing explicit trust boundaries during joint design sessions with other team members.

Calculate layer whitespaces

My approach again changes with the second function I implement: I go for a „one shot kill“: first a red test on an acceptance test level (for a partial problem), then all the necessary production code.

I’m not trying to crawl my way to a full solution with incremental tests because the solution is sitting right in front of me in the design. I’ve done „my math“ in the design document already; it was part of understanding the problem. Why shouldn’t I use that now?

And again: the operation is so small. The loop is following a pattern, the calculations are trivial. If the one test would fail it would be easy to detect the cause.

Of course the production code is benefiting from language features like yield return. No need to allocate a data structure to compile the results in. Also no need to define a data structure to carry both values for each layer. C# tuples as „ad hoc records“ are perfect for that.

Please note how only the number of layers is passed to the function. No need to let it know about the layer letters. That’s decoupling in the small. It’s made easier by designing the functions before implementation. Refactoring to this kind of decoupling later on would be harder.

Generate the unique diamond layers

The third partial problem again is different from the previous ones. I now realize it’s too difficult to solve right away or with incremental tests. So I revert to stepwise refinement once again.

The overall problem of generating the unique layers consists of the partial problem generating of generating just a single layer - and a remaining problem of doing that for all layer letters.

It’s a typical „N:1 problem“. Or you could call it a mapping problem: the same thing is done for each item in a collection. However here it’s two collections of the same length. The layer letters have to be „merged“ with the layer whitespace calculations.

What I do in this case I use a bottom up approach: first I implement the nested function for generating a single layer. I do that again with two incremental tests, red-green-red-green.

The first version of the production code might seem not really according to KISS. Why include the if? For the first test this condition was not necessary.

Well… I guess my attention slipped a bit. I indulged in some look ahead. I knew a second test was coming which would need the conditional statement.

(While I was writing it I actually stopped for a second and mused about it… but I did not draw the right conclusion: not necessary right now, throw away.)

Please note the strange letter passed into the function: Why a * which is not a valid layer letter? This is my way of making obvious that this function does not care about „correct“ diamond characters. It’s focused on the layout of whatever it gets.

After I got the generation of a single layer working I move a one level up the function hierarchy. Doing one layer is integrated by a function for generating all unique layers:

This one again is so easy, I just use a single test to drive its production code. I dare to do that because C# is offering powerful abstractions like Linq; there are no more loops to get right.

Build diamond

Finally I get to the function building the diamond from the layers. This again is so simple I just need one test:

As you can see the function consists of two parts. The levels of abstraction of its logic are not even: line 50 is slightly more abstract than line 51f. I need a bit more mental effort to understand what 51+52 are doing than what 50 does.

But in the end it’s such a small function I don’t think more structure is needed. Or maybe this is a case where comments would help?

Crossing the finish line

That’s it. All functions from the design have been implemented. They are doing their partial jobs. That means all „musicians“ are ready, the instruments are tuned. It’s time for them to come together as a band and play a concert.

I do this by calling the partial functions from the root function:

Calling functions is the root function’s only responsibility. I call that integration (or composition) as opposed to operation. Operation is what the other functions are doing. They contain logic, they are the real workhorses of the solution.

(With the exception of GenerateUniqueLayers which I also view as an integration due to its shortness and usage of Linq, even though it’s not just calling another function but wrapping that.)

Coding the integration is easy by definition. It’s so easy in fact, that intermediate integrations in an IOSP-based function hierarchy hardly need testing at all. It’s the same as if you extracted a method during refactoring: you don’t put that under test immediately.

With the root function, the function which the user/customer is interested in, filled out I check the acceptance test cases from the beginning… And lo and behold they are both green!

I’m done with solving the original problem.

Refactoring

So far no refactoring seemed necessary. Due to TBC the code already is very clean, I’d say: all functions are small, the integration gives a good overview of how the problem is solved, the SRP reigns.

Now that I’m finished, though, I step back and try to imagine how a future reader of the code (possibly myself) would experience it.

The first thing I notice is that Print still is kind of fraught with details. I decide to extract another function:

Now Print tells the story what a diamond production looks like in three easy „sentences“: First calculate the size of the diamond by determining the layers it should consist of. Then actually generate those layers, but only the unique ones. Finally build the diamond from the layers.

While reading this story no details of the processing steps are necessary to know. At first that’s what some developers cannot really accept; they tend to read the code depth-first. However, my approach favors breadth-first reasoning.

And GenerateUniqueLayers is yet another integration which is focused on layer generation. It’s hiding the details of that so Print can be shorter and more conforming to the SLA principle.

Although IOSP-based code is easy to understand due to many small methods and clearly visible processes, code sometimes cannot tell the full story. Why are things how they are, what do certain terms mean?

Even with this small example I felt that was the case. So I also added an introductory comment:

To me comments are not a code small per se. It’s what the comments are used for that is important. Background information, documentation of decisions, some kind of glossary… all that and more can be valuable in code.

Deleting tests

Finally, now that I’m satisfied with my solution, a fundamental act of refactoring. It’s almost unheard of, I’d say, but I’m doing it on a regular basis as part of my approach: I delete tests.

Yes, that’s true. I delete tests which would make future refactorings harder.

To see which tests are of no longterm use I simply set the accessibility of all methods to private which haven’t explicitly been ordered by the customer. Methods not used in acceptance tests are obviously not used and should be hidden as structural details.

All methods of the single class of my solution except for Print thus go private. And all tests exercising these methods go red and are deleted. That’s seven test functions.

The only remaining, stable, long term tests are the acceptance tests. Or more generally tests of methods which need to remain public on other classes I might have designed (or which were created during refactoring). Tests of methods on such classes which also haven’t been requested by the customer and might vanish at any time I call module tests.

And the tests which just got deleted to me are scaffolding tests. Like a scaffold on a building they were useful while building up the logic. But once the logic is complete they are torn down like a scaffold on a building. Otherwise they would impede future changes of the overall structure.

But isn’t it a waste of time to write those tests in the first place if they get thrown away? I don’t think so. They were of great help to develop logic function by function. They were like finely honed probes measuring some quality of my code at precise points. Also they can guide later decisions with regard to modularity: If I very much hesitate to delete a scaffolding test that might be a signal to extract a module on which the function under test is public.

I would not have been able to drive my logic test-first at such detail and in such isolation only with tests going through the root function. „Pear programming“ to me is too inflexible, too cumbersome. I like fine grained control over my logic and tests. I like to build my ship outside the bottle before I shove it in and erect the masts.

Source: wikiHow: How to Build a Ship in a Bottle

What I hear from developers trying one of the other TDD styles often is they feel trapped by all their tests. Refactoring becomes impossible without turning many tests red which then requires them to correct them.

I’m suffering much less from such effects. Because I keep less tests around.

The most important and long living tests are the acceptance tests. They exercise the logic in a solid way.

Module tests complement acceptance tests; they knit the safety net more finely. But if they turn red due to refactoring I’m very willing to throw them away instead of repairing them.

Summary

Hamburg style TDD is about thinking before coding, the absence of functional dependencies (substitutes are comparatively rarely used), and also about the „art of letting go“. Don’t attach yourself too much to your tests.

It’s an outside-in approach to problem solving and programming.

PS: You might be wondering if all this leads to overengineering. So many functions… isn’t that much overhead?

Well… this is the alternative: The same logic sitting in just a single function.

Is that, what you like to see when asked to fix a bug? Multiply the number of lines by 2, 5, 10, 50 because that’s how long functions in „real code bases“ usually are; even methods with 5000 lines of code and more are not unheard of.

Functions not following the IOSP tend to grow indefinitely. There are no boundaries to growth. And the general recommendation „keep your functions small“ is pretty fuzzy. What does „small“ exactly mean? And where to stop, what else to do?

The IOSP is a great guideline towards codebases with all small functions.

But the above function still is small. Why have more than one function? Reason no. 1: Because this is an exercise. Reason no. 2: Even small functions can contain logic that is hard to get right. Wouldn’t you want to be able to check that easily?

But the above function is not what a classic TDD approach – aka „pear programming“ – would have led to. Fewer functions would have been extracted from the growing logic in the single function under test.

That’s true. But firstly refactoring is hard and easy to avoid. Secondly the result probably would have been a root function not conforming to the SLA: there would be a mixture of logic and function calls in it. That would not be easy to understand.

Finally I find code refactored from functions with functional dependencies and driven by TDD often not easy to read because it’s hard to extract responsibilities cleanly once they were entwined. Sure, not to refactor is no solution. But not having to refactor due to a clean design before coding leads to better results in my experience.

PPS: It’s never over! Today’s clean code is tomorrows dirty code.

Cleanliness of code is subjective and relative to your understanding/knowledge. If you gain new insights clean code you wrote yesterday will turn into somewhat dirty code.

A case in point the BuildDiamond function. I expressed some concern regarding it and even suggested comments to improve it. But just know I had another idea:

This to me is cleaner. It’s the same functionality, hence I call it a refactoring. But instead of extracting structures I redesign the approach to solving this partial problem and implemented it using more of the power of Linq. Now the function shows better SLA; no comments are needed.

I changed the logic even without the scaffolding tests being present anymore. I was confident the acceptance tests would catch any regression.

There are a number of „TDD styles“ (or even „schools of TDD“):

• Chicago style
• London style
• Munich style

And I cannot identify myself with any of them. Not 100% at least.

Recently I attended a talk by Marco Emrich who showed the above styles next to each other - and I kept shaking my head. There was some usefulness to all of them, but none really convinced me.

Then I saw a tweet by David Völkel in which he mentioned doing the Diamond kata „Munich style“. That triggered me to do it, too - and also Marco’s example from his talk, the Bank kata.

Styleguide

But what am I doing differently? Am I doing some kind of TDD at all? What’s TDD in the first place?

My understanding of TDD

TDD is mainly characterized by a simple process with three steps:

1. Red
2. Green
3. Refactor

That means it’s a test-first approach to programming: first write a not passing test (red), then write production code to make the test pass (green).

What takes it beyond test-first, though, is the refactoring step. By that TDD acknowledges that production code should not only pass tests, i.e. show some runtime behavior, but also be of a certain form (which is not relevant to its behavior).

Also TDD clearly states its process should be run through multiple times. TDD explicitly is an iterative approach to programming.

And then TDD urges you to let test cases increase in their difficulty from iteration to iteration. With each iteration a bit more value is added to the production code. TDD thus also an explicitly incremental approach to programming.

There is little said, however, about how each step should be performed. But getting a test to green should only involve the simplest possible addition to the production code (application of KISS principle). And refactoring should eliminate duplication.

Since Kent Beck is the „inventor“ of TDD it’s no small wonder that also his „for elements of simple design“ are of relevance:

• Passes the tests
• Reveals intention
• No duplication
• Fewest elements

That’s pretty much it, I guess. That’s TDD. Easily stated - but difficult to implement. The problems start, I think, when applying all this blindly. Rules seem to ask for obedience. And so developers are trying to obey - with very mixed results and quite some frustration.

No small wonder, different „schools of TDD“ emerged.

The matter is and the problems are too complex for a single set of rules and a single approach. On top of that there is probably an unknown amount of loss in communicating TDD: Kent Beck surely is the master of TDD - but does he (or even can he) convey everything he does/think/know in a book or several blog posts? I don’t think so.

When communicating one’s own „being“ much cannot be said explicitly. Much is falling through the cracks when preparing a descriptive document. Being can only fully be experienced by watching someone in a not prepared situation.

What happens when a lossy communication is taken for something lossless? Confusion ensues. Applying the lossy content will not lead to the same results as for the originator. This leads to frustration, conflicts, lots of discussion, or worse.

This has happened for Agility in general and also for TDD as part of Agility, I think.

Only experience counts

From the inevitability of lossy communication (and before that reflection about one’s actions) follows that adherence to rules cannot be the goal.

Rules are nothing! The only thing that counts is success. If you consistently experience success without following certain rules, whatever you do is superior to the rules.

Rules thus are only suggestions for how to achieve results. Nothing more, nothing less. They are invitations - and can be declined.

Follow rules at your own peril.

Don’t follow rules at your own peril.

To improve your results, your task is not to follow rules, but to evaluate your actions - and then adjust your approach if you find the results lacking some quality. You cannot offload responsibility for results to certain rules. The responsibility always is with you.

Kent Beck, Robert C. Martin, J.B. Rainsberger, David Völkel, or Ralf Westphal are only reporting (personal) experiences and their humble reflections on why they think there might be causal connections between doing something and getting certain results.

If you feel inspired by that and try to reproduce their results, stay alert. Lots of things can go wrong. And not all that was going on when they made their experiences has been/could be reported.

Trying harder to follow whatever account you read to overcome some information loss thus is natural. Also it’s natural to adapt whatever you’ve heard to your situation. You’re entitled to your own experiences and reflections. Maybe they just deviate from what you’ve read, maybe they are in outright opposition.

Any result, any approach is ok. Just remember: reflect on it.

My reflections

That’s what I’ve done: I reflected on why I wasn’t satisfied with the results I got from applying TDD.

To make a long story short, what I found was: TDD was playing dumb.

TDD is a problem solving tool. The problem being: conversion of requirements into code. And to be more precise: into logic plus structure. Logic to create the desired behavior at runtime, structure to keep programmer productivity high over an indefinite period of time. TDD is about functional and clean code.

That’s great! I’m all for this result.

But I beg to differ with regard to the approach.

Where I agree:

• I agree with the basic test-first approach of TDD.
• I agree with the importance of refactoring.
• I agree with revealing intentions.
• I agree with avoiding duplication.
• I agree with avoiding overengineering.
• I agree with the importance of passing all tests.

But there are a couple of points I don’t agree with:

• Refactoring is great. But even better is to not need to refactor. If I can come up with (pretty) clean code right from the start, why should I refactor.
• What to refactor to? TDD is barely making any statement about that, which is one of the reasons why many supposedly TDD based solutions I’ve seen are… not clean.
• Overengineering sure is an evil to avoid. But something that might look like overengineering to the code author today might be a helpful structure to a code reader tomorrow. Where to draw the line? My feeling is, TDD users are carried away too often by the mentions of KISS and „fewest elements“. „Elegance“ is still in high esteem, even though it’s a twin of obscurity.

And finally: What’s bugging me again and again when looking at TDD examples is the neglect of easily achievable insight. TDD proponents are dumbing themselves (and thus the process) down in a drive to… hm… to what? Maybe to avoid overengineering? Or to go faster while writing code?

Yes, I guess it’s the will to be faster and to avoid BDUF. BDUF is costing time now and time later when it needs to get adapted to new information. BDUF is bad. We know that, right?

Sure, BDUF is bad. By definition. It’s evil because of the B. Big design is deferring feedback.

DUF, though, is not bad in my experience. Designing a solution before coding is even inevitable. At least I need to think before coding. I need to make a plan before I create structures and arrange logic. Sometimes the thinking takes 10 seconds, sometimes 10 minutes or 30 minutes.

TBC (Thinking Before Coding) to me is essential. It’s a discipline of its own. It needs to be trained, it needs to be taught.

But TBC has vanished from curricula and is not visible in popular TDD examples.

I’m not saying TDD proponents are not thinking before coding. What I’m trying to get across is that such thinking is not made explicit. It has no form. It’s not expressed in code or in any other way.

The incremental tests of TDD are no expression of such TBC in my view. Because test cases are only about understanding requirements, not designing a solution. Tests are no models.

Models, however, are badly needed, if coding is supposed to progress smoothly.

The perennial cycle of software development

I want to add another iterative process to TDD’s red-green-refactor (RGR). It’s simple, it’s natural, it’s even inevitable:

• Analyze
• Design
• Code

The ADC iterations are sometimes congruent with the RGR iterations, but sometimes not. RGR can happen inside of C.

In any case I find it important to emphasize these three step process because I think it’s what software development is about, and not only software development if you replace „Code“ with some other implementation discipline like „Paint“ or „Cook“.

ADC is to be cycled through many times on different levels of detail. It’s to be used iteratively and even incrementally if possible.

And, yes, the D sits right before the C. So it’s design „upfront“, it’s thinking before coding. Like it’s listening and asking before designing.

In my „school of TDD“ „students“ are asked to first analyze requirements. That means they need to build a solid understanding of the problem. And they need to express this understanding in an unambiguous form open to scrutiny.

Only once understanding is clear they move on to create a model for a solution to the problem. A model is the result of the design step. But of course a model is not „the real thing“, it’s not the solution yet. A model is a more or less abstract description of an approach to solve a problem. It’s declarative, whereas the solution, the logic is imperative.

And finally they implement their model using the means of a programming language. Implementation is guided by the model and thus produces less waste. To me implementation mostly is boring and a comparatively mechanical task. Designing the model on the other hand is exciting and highly creative.

My feeling is, design (and also analysis) are underrated steps in software development. And coding is an overrated step.

Making the ADC loop explicit is thus what I find important. It’s more important than doing TDD the Chicago style or London style. Hence I’d call my approach to TDD eclectic. It’s drawing from all styles if that’s what’s needed to further the cause of creating correct code plus clean code.

However, there’s one main distinction which leads to a different stance regarding mocks and other substitutes: I believe that functional dependencies are to be avoided as much as possible. They make code hard to read and hard to test. What my design and then coding are striving for is adherence to the IOSP (Integration Operation Segregation Principle) which I derived a couple of years ago from Alan Kay’s definition of object-orientation.

But enough with all the theory. What does „Hamburg style TDD“ look like when applied? Check out the following articles for demonstrations:

• Diamond kata
• Bank kata

CQS (Command Query Separation) is a well known principle for disentangling method responsibilities in OO software.

I had known it for quite some time, but only recently actually have taken it to heart. And now I’m really loving it. I cannot imagine doing without it. It’s a great guidance when designing single classes or whole service processes.

And then there is CQRS which builds on CQS. I like that, too. It’s been a great inspiration.

But then I felt the need to move beyond it: CQS does not cover the „message reality“ I’m encountering. And CQRS does deliver the flexibility I expected from giving up „the single model“.

Code structure guided by CQS

To distinguish between Commands and Queries is a great guidance for structuring code. It’s a form of outside-in design, I’d say: You’re looking at the interactions of users (or more generally: the environment) with a system by sending/receiving messages and from that derive a certain structure.

Example: A player makes a move in a Tic Tac Toe game application.

Technically that means a user sends a message to the application with data about the move and receives back a message telling her the new game state.

Or more specifically this is a request for a certain behavior expressed in a response plus a change to some internal state.

The frontend first is used as an editor for the request message. A player certainly does not want to type in a JSON document but rather would like to just click on a cell on some visual game board.

And then the frontend is used as a projector for the response message. A player certainly does not want to interpret a JSON document but rather would like to see the game state rendered as a visual game board.

The domain or game logic itself is encapsulated in the backend with which the frontend is conversing only through messages. Frontend and backend don’t should share state, in my view.

So far so normal. A request is transformed into a state change plus a response. All the necessary logic is a big lump.

However, when applying the CQS to this, the request-response message flow can be dissected into a command followed by a query:

• First the command orders the backend to execute the move; the internal state of the backend is changed. This order of course is only carried out if the move is valid and the state’s consistency is not compromised.
• Then the query asks the backend for a description of its internal state.

What has been a single lump of logic now is two smaller lumps of logic. How cool is that? And all this without much creativity. The user’s requirement guided the design. Software development just needs to listen.

The tangible outcomes of a CQS-guided analysis are:

• A command message (data structure)
• A query result message (data structure)
• A query message (data structure; maybe only for internal use)
• A command status message (data structure; maybe only for internal use)
• A command handler (function)
• A query handler (function)
• A request handler (function; optional for hiding the command and query handler from the frontend for less traffic between frontend and backend)

I like this almost mechanically generated basic structure for my source code. It makes me focus more on the conversation with the user/customer because it’s from there I gain valuable first insights about the software design.

Message structure freed up by Event-Orientation

This is, what CQS does already. It’s a great help, but still leaves something to be desired.

What I found quite difficult for a long time was „message design“. How should messages look like, what structure should they have? How should this structure look like compared to the internal domain model?

CQS does not have an answer to that. CQRS on the other hand suggested to take it easier: there could be two models, one for commands and another one for queries.

But still I felt compelled to find the one model for handling commands, and the other one model for satisfying queries.

It took me a while to let go of that restriction.

Today, with Event-Orientation (EO) I don’t feel any restriction anymore. And I don’t feel I need to get „it“ right anymore „once and for all“.

The internal state of an application is not kept in a single (or two or three) data models anymore. I allow myself to program „model free“ or „schemaless“.

The model is dead! Long live the model multitude!

Each and every message is handled individually and is supported by the best model I can think of for that single purpose. With EO I feel free to let message structures be preliminary. They can be honed for consumption by the frontend; the backend then is a true service by catering to the needs of its client. Or message structures can be more palatable for the backend; the frontend then is more of a „slave“ to the provider of the core application behavior, the backend.

I remember how discussions about message structure took up quite some time during modelling sessions. Not anymore. Because there is no question anymore about how much a message model might couple frontend and backend.

There simply is no domain model anymore in the backend. There cannot be any coupling. Whatever a message carries is a projection or something that needs projection. It’s not some form of copy or part of a domain model.

Message structures are freed up by EO to look how they want. The internal state of an EO-based backend is something completely different: a stream of events.

To change the state through a command it has to be translated into a collection of events.

And to query the state the events in the stream have to be aggregated and projected into a result.

The proposition of EO is that such translations and aggregations/projections are all separate. By default they don’t share anything. No coupling, no dependency between them - except for the one event stream.

That makes message processing in both directions cheap. And it allows for independent development. EO slices an application not only into services but into message processing pipelines each catering to just a single message.

Deciding today that the TicTacToe game state query result should look like this, and tomorrow changing the decision to let it look like that is comparatively easy. It has no impact on some comprehensive domain model relevant to many messages.

The contract between message pipelines are just event data types. They are the core representation of the domain. Look at the events and you know what the domain is about. Events are telling a story about what is happening, what is deemed important, what the causal sequences are.

And this can be interpreted in a million ways, or at least as many ways as there are incoming message types to handle.

Notifications as ambient messages

CQS primarily distinguishes two kinds of messages: commands and queries.

That’s incoming messages. How about outgoing ones? I’d like to make explicit also two respective outgoing messages: command status and query result. Command status messages might be quite simple and generic (success vs failure), but query results surely are of very different form and need careful design.

However, in my experience there is a fifth message type. It’s particular because it’s not a request. Commands and queries stand for bidirectional message flow: a client sends a request (command or query) and expects a response (command status or query result).

Sometimes, though, messages are not produced with a certain expectation for a behavior of another (part of) a system. Sometimes messages are just „utterances“ of a system broadcast „to whom it may concern“.

I call such messages notifications.

Usually the name for them is „event“ with a prefix or suffix (like „domain event“). But that clashes with the data stored in an event stream inside of a system. I don’t like such homonymes.

„Notification“ is a term everyone is familiar with: we are notified about emails arriving in our inboxes or new messages in a Slack channel or of an overdue backup etc.

A lot of applications are broadcasting notifications to inform us about something that has happened/changed. And we are free to subscribe to such notifications. Some we are interested in, some not.

If we receive a notification we might react, eg. open the mail client to check our inbox. But the broadcasting application did not request such a reaction.

Notifications are one way messages. Software broadcasts them through some channel/medium as outgoing notifications. And other software might subscribe to a channel/medium to receive notifications from other software as incoming messages.

I call notifications ambient messages because they „float around in the environment“ and are not directed. They have a source, but no destination.

From that follows there is no guarantee that a notification will be handled at all. Notifications thus cannot carry requests. Their purpose solely is to inform about something that happened. They make a statement about the originating system - for others to possibly care for.

Notifications might be more relevant in distributed systems. Nevertheless I think they are a very general concept and thus should be included in the CQS principle. Hence I propose to expand it to:

CQNS: Command Query Notification Separation principle

The form of notifications is considerably different (being one-way messages). And their processing is different, too, I think.

1. Notifications do not query state, because there would be no receiver for a query result.
2. Notifications do not change state; that’s what commands are for.
3. The single responsibility of incoming notifications is to cause commands to be executed inside a receiver. However the command status messages generated by the triggered commands are not delivered to the originator of the notification.

So much for incoming notifications.

But where do outgoing notifications come from?

• Outgoing notifications are generated during command processing. Only commands change state, and notifications are signalling state change.

Notifications help to further structure code from the outside-in:

• Handling incoming notifications requires logic to translate them into commands.
• Command processing consists not only of
  1. model generation,
  2. command validation,
  3. event generation,
  4. but also of generating outgoing notifications.

That, to me, makes requirements analysis yet easier and delivers more input for further software design.

In a gaming scenario there could be two services: one for playing a game like TicTacToe and one for keeping a score board.

Both services could be connected in a request/response manner, for example, for registering the score of a finished game: the TicTacToe service could send a command to the score board service to inform it of another finished game and who has won. But why couple the services so tightly? The TicTacToe service would now depend on another service, it could not do its job without the other.

Instead a notification can be used to more loosely couple both service. With a notification they would not even know of each other.

• The TicTacToe service would broadcast a notification when a game finishes, e.g. by writing it to a queue hosted by some infrastructure.
• The score board service would subscribe to „game over“ notifications arriving in a queue hosted by some infrastructure.

One service’s outgoing notification is another service’s incoming notification.

Anatomy of a backend

To me the beauty of CQNS + EO is a very straightforward and generic basic software structure. And in that it’s easy to independently focus on (comparatively) small functional units.

Message-oriented requirements analysis

Designing software is helped by applying this pattern. But also analysis is helped because it’s guided by the message hierarchy:

• Messages
  • Incoming/outgoing
    • Request (outgoing) -> Response (incoming)
      • Command -> Command Status
      • Query -> Query Result
    • Notification
      • Incoming: Notification -> Commands
      • Outgoing
  • Event (internal)

My approach to software development is outside-in: I start at the surface of a software system and ask „How do users want to interact with the system?“ Requests with their responses are the primary answer to that.

Next I ask to what the software system should react in addition. Incoming notifications are the answer to that.

Then from command requests I derive the internal events to be stored in the event stream.

Next I try to balance the events found with what query requests might deem helpful to get from the event stream.

(If you’re a fan of Event Storming you might prefer to start with events and work your way „up“ to incoming/outgoing messages. That’s fine for me, too. That’s serving the same goal. If you find it easier that way around, why not?)

Finally I’m concerned with outgoing notifications generated by command request processing.

What I’m not really interested in anymore, though, is „the one“ internal domain data structure. I’m not trying to figure out how the domain can be represented in a comprehensive data model.

For a long, long that had been my primary concern. I was fixated on „the one“ domain data model. I wanted to represented „the world“ in software.

But those days are gone now!

Coloring the design blueprint mandala

Once I’ve gotten the messages down I can work on them one by one. It’s like eating a pizza slice by slice.

Each slice being a message handling pipeline. And the pizza crust being a tranceiver which receives incoming messages from the environment and sends/broadcasts outgoing messages to the environment.

The structure of all the pipeline slices is the same; each consists of three segments (and is attached to the event store at the center):

So for each message I can design the following step by step:

1. Define the message context, i.e. all the relevant events
2. Design the message context model
3. Design how the message context model should be loaded and queried before message processing
4. Design how the message should be processed in light of the message context model
   • Command
     • Design how to generate events from the message in light of the message context model
     • Design how to generate outgoing notifications from the message
   • Query
     • Design how to generate the query result from the message context model in light of the message
   • Notification
     • Design how to generate commands from the message in light of the message context model
5. Design how the message context model should be updated

To me that feels very guided, almost like a meditative activity (if not a boring one). It’s like coloring a mandala area by area…

Summary

Refining the CQS to CQNS and being grounded in Event-Orientation really helps me progressing through software development in a very straightforward manner.

Sure, there are still challenges to master. Sure, especially processing messages still can be tough.

With CQNS + EO, however, I’m relieved of a lot of confusing stuff around that. I find it much, much easier to focus on the important things.

• I’m not wasting energy on asking myself „How to start development?“
• I’m not wasting energy on „getting the one model right“.
• I’m not wasting energy on designing structures which should not differ from software to software anyway.

Yes, I believe there is a basic anatomy to all software. Like there is a basic anatomy to all animals. And that basic anatomy is more fine grained than the usual architectural pattern suggest. And it still leaves room and freedom for all the incredibly complicated stuff you have to implement, don’t worry.

I’d even say: By giving software a basic anatomy we’re set free to focus on the really important things much more. CQNS and EO, to me, are part of that anatomical blueprint.