In der Softwareentwicklung geschehen ständig Ereignisse, die nicht vorhersehbar sind. Sind deren Auswirkungen drastisch, entsprechen sie dem Typ von Ereignis, der seit Nassim Nicholas Taleb als Schwarzer Schwan bezeichnet wird. Mit seiner Idee der Antifragilität zeigt Taleb, wie Schwarze Schwäne als Grundlage von Verbesserung genutzt werden können. Antifragilität kann in der Softwareentwicklung besonders in zwei Bereichen helfen: Software-Architektur und Projektmanagement. Dieser Vortrag gibt Denkanstöße, wie man Schwarze Schwäne nutzen kann, um Software-Entwicklungs-Teams zur Antifragilität zu führen. Es geht dabei um Asymmetrien, kontrafaktisches Denken, richtige und falsche Fehler. Und welche Rolle Softwarearchitektur in einer antifragilen Welt spielen muss.

1. Herzlich willkommen zur Philosophie-Vorlesung.
Im Folgenden möchte ich eine Perspektive auf ein relativ neues Konzept vermitteln:
Antifragilität.
Besonders die Bedeutung von Antifragilität für die Softwareentwicklung.
Ich denke nämlich, dass wir in unserer Heimatdomäne sehr stark von diesem Konzept
profitieren können – wenn wir es richtig verstehen und nutzen.
1

2. Einen wesentlichen Aspekt zur Betrachtung von Antifragilität hat Russel Ackhoff auf den
Punkt gebracht.
Es ist besser, das Richtige falsch zu machen, als das Falsche richtig zu tun.
Wenn man das Falsche richtig macht, ist der Schaden in der Regel größer als umgekehrt.
Noch besser wäre es natürlich, das Falsche gar nicht zu tun und das Richtige richtig zu
machen.
Aber dann wäre das Zitat nicht so schön und mein Vortrag nicht so lustig.
2

3. Ok, worum geht es mir nun?
Um Unwissen und Wahrscheinlichkeiten. Besonders um den Zusammenhang zwischen
beiden.
Es geht um Asymmetrie und um Denken. Wir sind kurioserweise ziemlich schlecht im
asymmetrischen Denken.
Symmetrien fallen uns leichter. Wir empfinden ja auch Menschen mit symmetrischen
Gesichtern als schöner.
Schwarze und Weiße Schwäne, als Metaphern für Wissen und Unvorhersehbares.
Und es geht mir um Komplexität, Fehler und Optionen.
Gerade letztere haben es mir angetan, weil sie oftmals nur in ihrer Anwendung, nicht
aber in ihrer Wirkung betrachtet werden.
3

4. Fangen wir mit dem Unwissen an.
Phil Armour hat in seinem großartigen Buch „The Laws of Software Process“ fünf Arten
von Unwissen beschrieben.
Diese nennt er die Five Orders of Ignorance.
Das Buch möchte ich Euch übrigens wärmstens empfehlen, es ist ein Meisterwerk über
die Softwareentwicklung und ein wahrer Augenöffner in Bezug auf viele Dinge, die wir in
dieser Disziplin besser machen können.
4

5. Als Informatiker fängt Phil Armour natürlich mit der 0 an zu zählen.
Deshalb ist die erste Stufe des Unwissen auch die 0th Order of Ignorance.
Er nennt sie Lack of Ignorance und sie repräsentiert konkretes bekanntes Wissen.
Ein Beispiel dafür ist, dass ich mein Geburtsdatum kenne.
Meistens fällt es mir auch gleich ein, wenn mich jemand danach fragt.
5

6. Die zweite Stufe des Unwissens bezeichnet Phil Armour als Lack of Knowledge.
Auf dieser Stufe weiß man etwas nicht, aber man kennt die Frage.
Man weiß, was man nicht weiß und man weiß, wo man die Antwort findet.
Ein gutes Beispiel dafür ist mein Hochzeitstag.
Ich weiß, dass ich verheiratet bin, aber ich kann ihn mir das Datum nicht merken.
Glücklicherweise weiß ich, dass meine Frau das Datum kennt.
Ich kann sie also danach fragen.
6

7. Auf der dritten Stufe – der 2nd Order of Igrnorance wird es langsam interessant.
Hier begegnen wir den sogenannten unknown unknows.
Donald Rumsfeld war Experte dafür und wir haben in der Softwareentwicklung auch
ständig damit zu tun.
Dinge, von denen wir nicht wissen, dass wir sie nicht wissen.
Naturgemäß ist es schwer, dafür ein gutes Beispiel zu finden.
Anders ausgedrückt: Wenn wir wüssten, was wir nicht wissen, wüssten wir es schon.
7

8. Die vierte Stufe, die 3rd Order of Ignorance, hat es in sich.
Hier wissen wir nicht nur nicht, was wir nicht wissen – das wäre ja die 2nd OoI.
Es fehlt uns auch noch an der geeigneten Methodik, um herauszufinden, ob es
überhaupt etwas gibt, von dem wir nicht wissen, dass wir es nicht wissen.
8

9. Die fünfte Stufe des Unwissens habt ihr alle gerade verlassen.
Hier geht es um die Meta-Ebene des Unwissens, nämlich um die Tatsache, dass man
nicht weiß, dass es unterschiedliche Arten von Wissen und Nichtwissen gibt.
Diese 4th Order of Ignorance ist für die Software-Entwicklung sehr bedeutend...
9

10. ...denn auch wenn wir sie in Bezug auf die Five Orders of Ignorance gerade verlassen
haben, bewegen wir uns in unseren Projekten beständig auf ihr.
Wann immer wir einen Projektplan machen, Software-Architekturen entwerfen oder
ähnliche vorausschauende Dinge in Software-Projekten machen, sind wir auf der 4th
Order of Ignorance.
Wir ignorieren bei diesen Tätigkeiten einen wesentlichen Fakt.
10

11. Der Fakt, den wir ignorieren ist, dass die Entwicklung individueller Software immer
Arbeiten auf der 2nd OoI oder der 3rd OoI ist.
Egal, wieviel wir planen, es gibt Dinge, von denen wir nichts wissen und Dinge, für die
wir keinen Weg kennen, um herauszufinden, ob wir sie nicht wissen.
Das Blöde dabei ist: Wenn wir Projekte planen und Architekturen entwerfen, dann
berücksichtigen wir nur all die Sachen auf der 0th OoI und der 1st OoI.
Wir wissen, dass es unknown unknowns gibt und planen Puffer ein oder basteln
generische Ansätze.
Aber die Puffer und die generischen Ansätze basieren alle auf der 0th OoI und der 1st
OoI.
Sie haben also mit dem, was wir tatsächlich nicht wissen, nichts zu tun.
Denn eines ist klar: Es gibt keine Korrelation zwischen 0th OoI und 1st OoI auf der einen
und 2nd OoI und 3rd OoI auf der anderen Seite.
Gäbe es diese Korrelation, gäbe es keine 2nd OoI und keine 3rd OoI.
11

12. Was hat das jetzt alles mit Software-Entwicklung und mit Antifragilität zu tun?
Ganz einfach: Wir Menschen bewegen uns ständig und am allerliebsten auf der 0th OoI.
Wir leiten Wissen aus unseren Erfahrungen ab, ohne sicherzustellen, dass das ein valider
Weg ist.
Als Beispiel mag die früher verbreitete Idee sein, alle Schwäne seien weiß.
Das glaubten Europäer sehr, sehr lange.
Es schien gesichertes Wissen zu sein.
12

13. Bis dieser Cook nach Australien kam.
Hier gibt es Trauerschwäne, die sind schwarz.
Ziemlich blöd für das gesicherte Wissen über die weißen Schwäne.
13

14. Der wesentliche Punkt dabei ist: Schwarze Schwäne sind nicht vorhersehbar.
Sie sind nicht planbar, können jederzeit auftreten und haben im Allgemeinen drastische
Auswirkungen.
Nebenbei: Es gibt sowohl positive als auch negative schwarze Schwäne.
Wir nehmen aber in der Regel nur die negativen wahr, weil wir die positiven (also, dass
ein Projekt super läuft) unseren Fähigkeiten zuschreiben.
Letzteres ist ein zutiefst menschliches Verhalten, auf dem unser Selbstbewusstsein
basiert.
Wäre das anders, wären wir alle verängstigte scheue Persönchen, die sich nicht in die
Welt hinaus trauen.
14

15. Zurück zu den Schwarzen Schwänen.
Schwarze Schwäne sind immer Ergebnisse der 2nd OoI.
Das liegt daran, dass sie unvorhersehbar sind.
Auf der 0OoI und er 1OoI gibt es ja gesichertes Wissen und gesichertes Unwissen, hier
ist also alles vorhersehbar.
Schwarze Schwäne entstehen aus den unknown unknowns, aus dem unbekannten
Unwissen.
Deshalb haben wir auch keine Chance, sie vorherzuberechnen.
Ein Schweizer Mathematiker hat letztens mal einen Vortrag gehalten und ein Modell
vorgestellt, mit dem er Schwarze Schwäne berechnen kann.
Rückwirkend hat sein Modell alle als Schwarzer Schwan eingestuften ökonomischen
Ereignisse der letzten 20 Jahre richtig erkannt.
Aber: Nur weil ein Modell das in der Vergangenheit korrekt gemacht hat, muss es das
nicht auch für die Zukunft tun.
Unglücklicherweise macht nämlich die Nichtberechenbarkeit einen Schwarzen Schwan
aus.
Also: Egal, was manche „Experten“ behaupten – Schwarze Schwäne sind definiert als
nicht vorhersehbare Ereignisse.
15

16. Man kann es auch anders formulieren:
In Softwareprojekten treten zwangsläufig unvorhersehbare Ereignisse auf.
Das wiederum ist vorhersehbar.
Was nicht vorhersehbar ist, ist das Ereignis selbst, der Zeitpunkt seines Auftretens und
seine Auswirkungen.
Also alles, womit wir zu kämpfen haben.
16

17. Kommen wir zu Antifragilität.
Dazu müssen wir uns zunächst mit Fragilität beschäftigen.
17

18. Fragiles ist vergänglich, man muss Aufwand investieren, um es zu erhalten.
Alles, was wir Menschen erschaffen, ist fragil.
Technologie, Kultur, soziale Beziehungen...
Wir müssen Energie aufwenden, um diese Dinge am Vergehen zu hindern.
Verzichten wir auf diese Energie, wirkt die Fragilität sofort.
18

19. Unabhängig von der Energie, die wir in seine Erhaltung investieren, ist es so, dass
Fragiles durch Schwarze Schwäne sofort vernichtet wird.
Bestes Beispiel sind Ereignisse wie Tschernobly oder Fukushima.
Es gibt noch jede Menge mehr, aber diese sind aufgrund ihrer Dramatik leicht als
Schwarze Schwäne zu erkennen.
19

20. Gibt es etwas, das Schwarzen Schwänen widerstehen kann, sie überstehen kann?
Was können wir dem Fragilen also entgegen setzen?
20

21. Zunächst fällt uns da etwas robustes ein.
Etwas robustes zeichnet sich dadurch aus, dass wir nicht beständig Energie investieren
müssen, um es zu erhalten.
Die Pyramiden sind aus dieser Perspektive ziemlich robust.
21

22. Oder so ein Baum.
Der einzelne Baum ist gegenüber Wind und Wetter robust.
Er übersteht Stürme, Dürreperioden und blätterfressende Elefanten.
Aber was ist mit Feuer?
22

23. Das Problem mit der Robustheit ist:
Sie hat Grenzen.
Ein System kann nicht beliebig robust sein, ein „geeigneter“ Schwarzer Schwan kann
auch etwas robustes vernichten.
Die Pyramiden werden irgendwann verschwinden, genauso der Baum.
23

24. Robustheit bringt uns also in der Frage nach einem Gegensatz zum Fragilen nur
eingeschränkt weiter.
24

25. Betrachten wir stattdessen Resilienz.
Resiliente Systeme sind aktuell ein angesagtes Thema in der IT.
Ob als reslientes Projektmanagement oder Resilienz durch die Cloud – sie ist in aller
Munde.
25

26. Resilienz bedeutet im Wortsinn: Widerstandsfähigkeit.
Resiliente Systeme haben robusten Systemen gegenüber einen Vorteil:
Sie versuchen nicht, durch pure Kraft zu widerstehen.
Sie lassen sich von einem Schwarzen Schwan stören und schwingen wieder zurück in
ihren stabilen Zustand.
Wie ein Pendel.
26

27. Da wir vorhin den Baum als Beispiel hatten, nehmen wir nun den Wald.
Der einzelne Baum ist robust, der Wald ist resilient.
Tritt der Schwarze Schwan namens Feuer auf, der den einzelnen Baum vernichtet hat,
wird der Wald zunächst auch vernichtet – das Pendel schwingt aus.
Aber nach einer Weile steht wieder ein Wald da – das Pendel schwingt zurück.
Der Wald ist also resilient.
27

28. Resiliente Systeme können Schwarze Schwäne überleben.
Aber wenn der gleiche Schwarze Schwan wieder auftritt, wird ein resilientes System
immer wieder auf die gleiche Weise gestört.
Insofern ist Resilienz für einige Anwendungsgebiete durchaus hilfreich – aber nicht
unbedingt ausreichend, wie wir gleich sehen werden.
28

29. Betrachten wir die Lebenskurven von komplexen Systemen in Bezug auf einen
Schwarzen Schwan.
Fragiles vergeht von allein, man muss es aktiv erhalten.
Der Schwarze Schwan beschleunigt sein Vergehen nur.
Robustes muss nicht aktiv erhalten werden, aber ein Schwarzer Schwan vernichtet es.
Resilientes wird durch einen Schwarzen Schwan gestört, kann sich aber wieder in seinen
ursprünglichen Zustand zurück entwickeln.
Die Erkenntis hierbei ist: Alle drei Eigenschaften bewegen das System in den negativen
Bereich.
Die Systeme werden gestört oder zerstört.
Die Frage lautet also: Gibt es etwas, das vom Schwarzen Schwan profitieren kann, sich
bei seinem Auftreten also ins Positive entwickelt?
29

30. Damit wären wir beim tatsächlichen Gegenteil des Fragilen.
30

31. Taleb nennt es Antifragilität.
31

32. Und Antifragilität ist genau die Eigenschaft eines Systems, die dazu führt, dass es vom
Auftreten eines Schwarzen Schwanes profitiert.
32

33. Ein antifragiles System entwickelt sich beim Auftreten eines Schwarzen Schwanes zum
Besseren.
Es wird positiv beeinflusst und steht am Ende stärker da als vor dem Schwarzen Schwan.
Wie funktioniert das?
Wie kann es für die Softwareentwicklung genutzt werden?
33

34. Um diese Fragen zu beantworten, müssen wir uns mit Asymmetrie beschäftigen.
Die richtige Form von Asymmetrie ist eine gute Vorrausetzung für Antifragilität.
34

35. Das sind die Buddenbrooks.
Hat jemand den Film gesehen?
Das Buch gelesen?
Die Buddenbrooks sind ein hervorragendes Beispiel für Asymmetrie, die zu Fragilität
führt.
Die Dame ganz links im Bild ist Tony Buddenbrook, die Tochter des Hauses.
35

36. Tony Buddenbrook ist ein Paradebeispiel für asymmetrisches Denken, so wie wir es auch
ständig erleben.
Sie initiiert die Pöppenrader Ernte, ein Geschäft, das einen großen Gewinn verspricht.
36

37. Bei der Pöppenrader Ernte handelt es sich um jede Menge Getreide – die Buddenbrooks
haben sehr viel mit Getreide gehandelt – das „bis zum letzten Halm“ noch vor der Ernte
gekauft wird.
Der Vorschlag stammt von Tony Buddenbrook und klingt erst mal plausibel:
Wir kaufen die gesamte Ernte, dann kann sie uns kein anderer mehr wegschnappen und
wenn sie geerntet wurde, verkaufen wir sie mit Gewinn.
Aber dann kommt ein Schwarzer Schwan in Form eines Unwetters und vernichtet die
gesamte Ernte.
Und damit auch das bereits investierte Geld.
Wie gesagt, ein Paradebeispiel für Fragilität.
37

38. Anders verhält es sich mit diesem Herrn.
Kennt den jemand?
Das ist Thales von Milet, Philosoph und Mathematiker.
Aristoteles hat eine Anekdote über ihn aufgeschrieben, in der er eine Asymmetrie
herstellt, die zu Antifraglität führt.
38

39. Die ganze Gegend um Milet lebte zu Thales‘ Zeiten von Oliven.
Vor allem Olivenöl hatte viele Leute reich gemacht und diese Herren zogen nun über
Thales her.
Wer‘s drauf hat, macht in Olivenöl und wird reich.
Wer‘s nicht drauf hat, wird Philosoph.
Das konnte Thales nicht auf sich sitzen lassen und wollte es denen mal so richtig zeigen.
39

40. Thales kann die Five Orders of Ignorance.
Sicher nicht das Buch von Phil Armour, aber das Konzept war ihm auf jeden Fall bewusst.
Thales respektierte die Five Orders of Ignorance und konnte daher eine Asymmetrie
aufbauen, die ihn bezüglich seines Unwissens antifragil machte.
40

41. Thales lief los und machte mit den Besitzern der Olivenölpressen Verträge, die ihm zum
Zeitpunkt der Olivenernte ein Vorzugsrecht gaben, die Pressen anzumieten.
Dieses Recht auf bevorzugte Nutzung kostete ihn nicht viel.
Das Schlimmste, was passieren konnte, war, dass die Olivenernste schlecht ausfiel und er
ein bisschen Geld für diese Verträge in den Sand gesetzt hätte.
Die Olivenernte verlief aber sehr gut und Thales berief sich auf sein Recht der
bevorzugten Nutzung – er mietete alle Olivenölpressen an.
Und vermietete sie an die Olivenbauern weiter, die ihm auf diesem Weg zu einem
stattlichen Vermögen verhalfen.
41

42. Was Thales machte ist der erste dokumentierte Optionshandel der Geschichte.
Leider werden Optionen oft sehr eingeschränkt als „Recht, aber nicht die Pflicht, etwas
zu kaufen“ erklärt.
Das ist aber nur ihre Anwendung im wirtschaftlichen Kontext.
Tatsächlich sind Optionen eine Möglichkeit, Asymmetrien zu erzeugen, die unsere
Verluste beschränken.
Das ist ihre Wirkung.
Und diese Wirkung ist das Wichtige am Konzept der Optionen.
42

43. Zusammengefasst:
Tony Buddenbrook verhielt sich asymmetrisch bezüglich der Sicherung eines Gewinns.
Sie glaubte, den Gewinn zu sichern, ignorierte aber die Möglichkeit von Unwissen auf
der 2nd und 3rd OoI und verlor durch einen Schwarzen Schwan alles.
Tony Buddenbrook hatte die Chance, wenig zu gewinnen und das Risiko, alles zu
verlieren.
43

44. Thales erzeugte eine Asymmetrie, die seine Verluste absolut beschränkte.
Er akzeptierte, dass es Dinge passieren können, über die er nichts weiß – Schwarze
Schwäne.
Dagegen sicherte er sich durch die Nutzung von Optionen ab.
Er hatte die Chance, alles zu gewinnen und das Risiko, wenig zu verlieren.
44

45. Wie übertragen wir das nun endlich auf die Softwareentwicklung?
45

46. Mit Hilfe von Fehlern.
46

47. Das Blöde dabei ist, dass wir in der IT primär darauf bedacht sind, Fehler zu vermeiden.
Fehlerfreiheit im Entwicklungsprozess und in der Software wird als hohes Gut betrachtet
47

48. Wir beschäftigen uns viel zu pauschal mit Fehlern.
Wenn Ackhoff recht hat, dann gibt es falsche Fehler (do the wrong thing right) und
richtige Fehler (do the right thing wrong)
Die richtigen Fehler sind ein Pfad, der uns zu Optionen führt.
48

49. Softwareentwicklung ist ein komplexer Prozess in einem komplexen System der zu
einem komplexen Produkt führt.
Jeder Versuch, Fehler zu vermeiden, erhöht diese Komplexität und zieht potentiell neue
Fehler nach sich.
Der strikte Versuch der Vermeidung von Fehlern (wir erinnern uns: wir befinden uns auf
der 2nd und der 3rd OoI, bei den unknown unknowns) ist also ein falscher Fehler.
49

50. Akzeptieren wir dagegen, dass es jede Menge Dinge gibt, über die wir nichts wissen,
reduzieren wird damit die Komplexität.
Wir machen dann zwar ab und zu etwas falsch, aber das ist das Richtige.
Auf diese Weise bekommen wir Feedback und können uns anpassen.
Das ist ein sehr günstiger Weg, mit der 3rd OoI umzugehen.
50

51. Man kann es auch so ausdrücken:
Fail fast, fail early, fail often.
51

52. Damit das klappt, müssen wir aber anders denken, als wir es gewohnt sind.
Wir müssen uns mit Nicht-Handlungen und Nicht-Ereignissen beschäftigen.
Wir müssen kontrafaktisch denken.
52

53. Retrospektiven sind dazu ein herrliches Werkzeug.
Statt die 0-8-15-Retrospektive mit dem Schema „Was lief gut, was lief schlecht“
beschäftigen wir uns mit der Frage:
Welche Fehler haben uns weitergebracht?
Was haben wir gelernt, das wir vorher nicht wussten und was müssen wir als nächstes
ausprobieren?
So finden wir Optionen – und können Maßnahmen ergreifen, diese möglichst lange zu
erhalten.
53

54. Optionen sind billig und helfen uns dabei, unsere Verluste absolut zu begrenzen.
Wir können auf diesem Weg Schwarze Schwäne weder verhindern noch voraussehen.
Aber wir können auf diesem Weg erreichen, dass wir im Falle eines Schwarzen Schwanes
keinen Schiffbruch erleiden und genügend Reserven haben, um uns in die positive
Richtung zu entwickeln.
Wir können auf diesem Weg antifragil werden.
54

55. In den letzten 15 Jahren habe ich viele Softwarearchitekten und Projektleiter gesehen,
die wie Tony Buddenbrook agieren.
Sie versuchen, vorausschauend zu arbeiten und erzeugen damit Fragilität.
Aus dieser Beobachtung und den Gedanken, die ich um Vortrag erklärt habe, habe ich
vier Thesen abgeleitet.
55

56. Die erste These ist eigentlich nur konsequent.
Softwarearchitekten und Projektleiter sollten denken wie Thales, nicht wie Tony
Buddenbrook.
56

57. Software selbst ist ein technisches System, von Menschenhand erschaffen.
Sie kann also nie antifragil sein, allerhöchstens robustes oder resilientes Verhalten
aufweisen.
In Bezug auf Schwarze Schwäne aus Anforderungen wird sie aber immer fragil sein.
57

58. Agile Teams haben, sofern sie ernsthafte Retrospektiven betreiben, die Chance, antifragil
zu handeln.
Das entspricht auch den Werten und Prinzipien des agilen Manifests.
58

59. Zu guter Letzt glaube ich, dass Softwarearchitekten, sofern es sie als definierte Rolle in
Zukunft weiterhin gibt, sich in den nächsten Jahren weiterentwickeln werden.
Softwarearchitekten werden Schlüsselpersonen zum Umgang mit den Five Orders of
Ignorance sein.
Sie werden weniger Technik-Entscheider sein, sondern vielmehr Optionshändler.
Sie werden agilen Teams dabei helfen, Optionen zu erhalten und antifragil zu handeln.
59

60. Damit wäre ich durch.
Ich hoffe, ich konnte das Konzept von Antifragilität und seine Bedeutung für unsere
Arbeit verständlich erklären.
Und ich hoffe, ihr könnt aus meinen Ideen etwas in eure tägliche Arbeit mitnehmen.
60