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

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

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

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

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

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

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

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

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

...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

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

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

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

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

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

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

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

17

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

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

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

20

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

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

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

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

24

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

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

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

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

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

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

30

Taleb nennt es Antifragilität.

31

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

32

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

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

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

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

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

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

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

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

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

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

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

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

Wie übertragen wir das nun endlich auf die Softwareentwicklung?

45

Mit Hilfe von Fehlern.

46

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

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

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

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

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

51

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

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

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

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

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

56

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

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

58

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

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