Schrödinger Programmierer, Entwickler und Katzen

Die Realität eines Netzwerktechnikers (mit Nudeln und ... Salz?)

Kürzlich habe ich bei der Diskussion verschiedener Vorfälle mit Ingenieuren ein interessantes Muster festgestellt.

In diesen Diskussionen stellt sich immer die Frage nach der „Grundursache“. Treue Leser werden wahrscheinlich wissen, dass ich ein paar Gedanken dazu habe . In vielen Organisationen basiert die Ereignisanalyse vollständig auf diesem Konzept. Sie verwenden verschiedene Techniken zum Ermitteln von Ursache-Wirkungs-Beziehungen, z. B. Five Why . Diese Methoden legen die sogenannte "Linearität der Ereignisse" als unbestreitbares Dogma nahe.

Wenn Sie diese Idee in Frage stellen und darauf hinweisen, dass Linearität in komplexen Systemen beruhigend täuscht, entsteht eine faszinierende Diskussion. Die Debattierer bestehen leidenschaftlich darauf, dass nur die Kenntnis der „Grundursache“ es uns ermöglicht, zu verstehen, was passiert.

Mir ist ein interessantes Muster aufgefallen: Entwickler und Entwickler reagieren unterschiedlich auf diese Idee. Nach meiner Erfahrung argumentieren Entwickler häufiger, dass die Ursache eine Rolle spielt und dass Ursache-Wirkungs-Beziehungen immer in Ereignissen hergestellt werden können. Andererseits stimmen die Entwickler häufiger darin überein, dass eine komplexe Welt nicht immer der Linearität unterliegt.

Ich habe mich immer gefragt, warum das so ist? Was bringt Programmierer dazu, die Idee der „Grundursache - Mythos“ zu kritisieren? Wie ein Immunsystem, das einen Fremdkörper erkennt. Warum reagieren sie so, während Entwickler diese Idee eher in Betracht ziehen?

Ich bin nicht ganz sicher, aber diesbezüglich gibt es eine Überlegung. Es ist mit verschiedenen Kontexten verbunden, in denen diese Fachkräfte ihre tägliche Arbeit verrichten.

Entwickler arbeiten oft mit deterministischen Werkzeugen. Natürlich sind Compiler, Linker und Betriebssysteme alles komplexe Systeme, aber wir sind es gewohnt, ein deterministisches Ergebnis zu liefern, und wir präsentieren sie als deterministisch: Wenn wir die gleichen Eingabedaten bereitstellen, erwarten wir normalerweise die gleichen Ergebnisse von diesen Systemen . Und wenn es ein Problem gibt („Bug“), lösen die Entwickler es, indem sie die Eingabedaten analysieren (entweder vom Benutzer oder von einer Reihe von Tools im Entwicklungsprozess). Sie suchen nach einem "Fehler" und ändern dann die Eingabe. Dies behebt den Fehler.


Die Hauptannahme der Softwareentwicklung: Die gleichen Eingabedaten liefern zuverlässig und deterministisch die gleichen Ergebnisse

Tatsächlich wird ein nicht deterministisches Ergebnis an sich als Fehler angesehen: Wenn eine unerwartete oder fehlerhafte Schlussfolgerung nicht reproduziert wird, versuchen die Entwickler, die Studie auf andere Teile des Stacks (Betriebssystem, Netzwerk usw.) auszudehnen, die sich ebenfalls mehr oder weniger deterministisch verhalten Ergebnis mit der gleichen Eingabe ... und wenn dies nicht der Fall ist , wird es immer noch als Fehler angesehen. Es ist nur so, dass dies jetzt ein Fehler des Betriebssystems oder des Netzwerks ist.

In jedem Fall ist Determinismus eine grundlegende, fast selbstverständlich vorausgesetzte Annahme für die meisten Arbeiten, die Programmierer ausführen.

Aber für jeden Devopa, der den Tag damit verbracht hat, Eisen in Gestellen zu sammeln oder sich mit der Cloud-API zu befassen, ist die Idee einer vollständig deterministischen Welt (solange die Möglichkeit besteht, alle Eingabedaten anzuzeigen!) Bestenfalls ein flüchtiges Konzept. Auch wenn die BOHF-Witze über Sonnenflecken beiseite geworfen wurden , sahen erfahrene Ingenieure die seltsamsten Dinge auf dieser Welt. Sie wissen, dass selbst ein menschlicher Schrei einen Server verlangsamen kann , ganz zu schweigen von Millionen anderer Umweltfaktoren.

Erfahrene Ingenieure können daher leichter bezweifeln, dass alle Vorfälle eine einzige Ursache haben, und Techniken wie "Fünf Gründe" führen korrekt (und wiederholbar!) Zu dieser Ursache. Tatsächlich widerspricht dies ihrer eigenen Erfahrung, wenn Puzzleteile in der Praxis nicht so klar zusammenpassen. Daher nehmen sie diese Idee leichter wahr.

Natürlich sage ich nicht, dass Entwickler naiv, dumm oder unfähig sind zu verstehen, wie Linearität täuschen kann. Erfahrene Programmierer sahen wahrscheinlich auch viel Nicht-Determinismus in ihrem Leben.

Aber es scheint mir, dass die übliche Reaktion der Entwickler in diesen Auseinandersetzungen oft damit zusammenhängt, dass das Konzept des Determinismus als Ganzes ihnen im Arbeitsalltag gute Dienste leistet. Sie treffen nicht so oft auf Nicht-Determinismus, wie Ingenieure Schrödinger-Katzen auf ihrer Infrastruktur fangen müssen.

Vielleicht erklärt dies die beobachteten Reaktionen der Entwickler nicht vollständig, aber dies ist eine starke Erinnerung daran, dass unsere Reaktionen eine komplexe Mischung aus vielen Faktoren sind.

Es ist wichtig, diese Komplexität im Hinterkopf zu behalten, ob wir einen einzelnen Vorfall untersuchen oder gemeinsam an einer Software Delivery-Pipeline arbeiten oder versuchen, eine größere Welt zu verstehen.