Software As Narrative 9/n

Given that Software Systems Begin Life As Narratives what does that tell us in pragmatic terms about how build and manage software systems?

Narratives Are Contested

We know of narratives that they are abstract and as such are contested. Each person has their own point of view and we reflect this in such longstanding aphorisms as "there's at least two sides to every story." However to any business narrative there are n many sides.

Consider also that narratives are not mutually exclusive in point of fact narratives are multiplicative by nature -- not only each person but each person at each point in time has their own side to every story!

Embracing Ontological Relativism

At the heart of Devops is the admission that no single actor can ever obtain a "canonical view" of an incident that took place during operations within an intractably complex sociotechnical system such as a software organization, hospital, airport or oil refinery (for instance).

The Blamelessness meme in devops descends from alignment with the paradigm of Ontological Relativism: the admission that each actor in an incident (including investigators and adjudicators who come to the incident after the fact) has a personal narrative which is valid yet also incomplete. Thus no canonical narrative is possible.

John Allspaw highlights devops' commitment to Ontological Relativism when he says "there is no root cause." with regard to incident investigation.

"There Is No Root Cause" -- John Allspaw

In fact this observation is worth pursuing a bit further.

If there really is no root cause, why is it that we spend so much time seeking root causes? This is because it is a relatively new and still-controversial position that root cause is a canard.

But root cause is a canard. There is no "primary" root cause there is only the place where one stops looking for deeper, previous root causes. In other words: if you keep looking long enough all root cause investigations eventually arrive at the moment just before the Big Bang and get stuck there).

Causality Is A Questionable Phenomenology

Another problem with root cause investigations is that they basically seek to identify events located sequentially in time and adjacent the problem space. The idea behind "root causing" is that if enough sequential and adjacent events are located in space-time, a line can then be traced backwards through the events: a chain of causality.

While it is perfectly possible to draw such causality chains, their utility in explaining events is questionable. Why not draw associations between second-degree events that took place significantly prior? This is not a hypothetical, to take such an alternate, farther-reaching strategy might uncover systemic causes of localized-appearing incidents.

Chtulhucene Tentacular Devops

The anthropologist Donna Haraway has articulated several aspects of the "new view" of system safety, sometimes called Safety-II but in Web operations more often just called Devops.

Haraway characterizes modern technical response to incidents as "staying with the trouble" that is Haraway advocates switching from a historically standard stance of limiting risk to a modern proactive ontologically relative flowing "dance" that embraces events as they occur, including incidents.

This staying-with-the-trouble pragmatically reflects the observations of risk analysts across disciplines since the 90s: prediction is a loser's game and thus so is limiting risk. Embracing and learning from risk like a real organism is a better more promising way of staying-with-the-trouble as-a-service.