Thread by @noahsussman

Interaction Resiliency (iXR) is the practice of Software QA (aka #testing) as applied to "devops" or more properly Safety-II software delivery (aka continuous delivery & continuous deployment).

I put a name to "testing in devops" or "agile testing in continuous delivery" because a) those phrases are clumsy 😀 and b) the current discourse in #testing constantly collapses back on itself as big-A Agile + CDT are conflated time-and-time-again with Safety-II + Kaizen #iXR

#iXRE Interaction Resiliency Engineering

Ten years ago I decided to make a clean break with Agile and XP. I started working in Continuous Delivery with an explicit goal of supplanting the Agile methodologies, not augmenting them.

I think Agile, XP and Context-Driven #testing are all incompatible with systems thinking.

The Etsy CI pipeline was a first experiment in working in a style that is not grounded in any of the Agile methodologies.

And it worked. 100+ devs committing to production daily, works.

That means a lot if not all Agile, XP and Context-Driven #testing ceremony is unnecessary.

New code can be put into production on a rolling basis by at least a couple of hundred very-loosely-coordinated contributors. Prior to Etsy people said: that works for Linux but it won't work in the enterprise.

But Continuous Deployment worked. Even at global e-commerce scale.

If you can put code into production as soon as it's written then you don't need

* test environments

* integration environments

* a process for shepherding code from a test environment through integration and into production

🤔 Agile #testing is preoccupied with these areas.

Context-Driven #testing and Agile testing both focus on pre-release exploratory and regression testing. Non-trivial pre-release testing is unnecessary in Continuous Deployment and "regression" testing is incompatible with systems thinking approaches like Safety-II
#iXRE 🧚🏼‍♂️

One can tell that "regression" #testing is incompatible with Safety-II and Systems Thinking because blamefulness and causality are incompatible with Safety-II and Systems Thinking.

"Regression" implies blame. "The software was in a good state until someone changed something."

The problem with "The software was in a good state until someone changed something." is that systems do not have histories composed of discrete, knowable states.

Software systems don't "regress" to "previous" states. Even if you wanted to this on purpose it would be impossible.

Here is a case study on the futility of attempting to *purposely* cause a software system to "regress" to a previous known state.

blog.skyliner.io/you-cant-have-…

Viewed through the lens of systems thinking: one can't *cause* a desired "regression" to a "previous" state.

And so one can't catalog a set of "known bad previous states" nor can one monitor a running system for the "recurrence" of a "known previous bad state."

#iXRE 🧚🏼‍♂️

"Regression" testing is old science. Modern, systems-based approaches view software systems as living[1] organisms no more reversible in time than an office building or a frog

[1]see Christopher Alexander's definition of "alive" artifacts — artifacts exhibiting the QWAN. #iXRE

You don't do regression #testing on living organisms and it doesn't make sense for software systems either.

I get recommended checkups and vaccinations. I don't get checked to see whether the sprained ankle from last year came back.

So much for causality.

Since systems (such as frogs, distributed software) do not have discrete known previous states it follows that perceived "defects" do not arise from knowable past actions of people at the sharp end.

#iXRE 🧚🏼‍♂️

#testing as "detecting regressions" or "catching defects before they get to production" is the OLD model of software product quality.

Testing and assessing quality in digital systems means something else. #iXRE 🧚🏼‍♂️

OOP #testing also does not work with the new view of product quality because OO is a structural metaphor (thus "architecture" and "object hierarchies") while systems thinking demands a post-structural approach.

Are Agile and CDT applicable in a post-structual context?

Certainly they are but each only in part. The causal chains (root cause analysis, five whys) have to be discarded along with blameful constructs like "human error" (defects, regressions).

#iXRE 🧚🏼‍♂️

One reason I'm floating Interaction .R.E. as a blanket term for "testing in a devops context" is to differentiate the set of approaches (there are many 🦄🌈!) that take into account post-structuralism, blamelessness and problematic nature of "causality."

#iXRE 🧚🏼‍♂️

As someone who since 2009 has worked on CI and #o11y systems one aspect of Interaction Reliability (nee “#testing in a devops context”) has shaped my career.

That is the daily cadence of production software delivery made possible by Continuous Deployment.

#iXRE 🧚🏼‍♂️

Daily cadence is the natural pace of software delivery. A person learning to build a web service will simply put new code into the running system and immediately observe / fix the results — a beneficial feedback loop that preserves the Flow State of the person.

Flow is another differentiator of I what I want to call Interaction Resilience.

Agile and Lean #testing methodologies don't center the mental state of individual persons at the sharp end.

But deploying continuously, I can only use the parts of Lean/Agile that center Flow.

The central goal of continuous deployment is to preserve that feedback loop and flow state that every beginner developer enjoys with the systems they build as they are learning.

The goal is to continue learning as we did as beginners.

One reason for creating a different brand than Lean/Agile/CDT is that #iXRE assumes a lot of complex sometimes counterintuitive things:

1. Flow is all-important. Good systems are only possible if people at the sharp end are "in flow" most of the time. en.wikipedia.org/wiki/Flow_(psy…

2. Everyone agrees we should practice trunk-based development at all times, for all projects. Explicitly we do not use git-flow. Generally we do not use any "branching strategy." trunkbaseddevelopment.com

3. Everyone agrees to practice Continuous Delivery for all phases of the product life cycle. continuousdelivery.com

4. The organization has aligned around building a monolithic product codebase and platform.

Or if you must think of #iXRE in terms of "architecture" please consider it through the metaphorical lens of Brutalist Architecture. en.wikipedia.org/wiki/Brutalist…

5. The organization views incidents and "defects" in the context of Safety-II and therefore everyone already practices Blameless Post Mortems. codeascraft.com/2016/11/17/deb…

So. 5 underlying assumptions:

1. Time-in-flow is the basic unit of work.

2. Monolithic product and codebase.

3. Trunk-Based Development already practiced.

4. Continuous Delivery already practiced.

5. Safety-II is the default model for all incident and "defect" responses. 🐛

If you would like to read this whole thread in one place here is a screenshot of the whole #ixRE thread so far. evernote.com/l/AAMP6s9Y0_pK…

So the kind of #testing I have been doing these last 10 years has the 5 underlying assumptions (Flow, Monoliths, Trunk Dev, CD, Safety-II) and then it also rests on quite a few counter-intuitive propositions drawn from various older-but-canonical sources on software QA.

One assumption behind the #iXRE style of #testing is that everything is a finite state machine.

If a thing cannot be conceived of as a finite state machine then one readjusts one's conception of that thing so that it can be related to as a finite state machine.

"Readjusting one's concept of a thing" is quite an undertaking. It is not easy nor does it feel "natural" to abandon ontological models on the fly. However that is what Continuous Deployment facilitates since it has #o11y as a prerequisite.

Another (difficult) assumption of #iXRE is that code-level bug reports are more useful than behavioral diagnoses and that therefore QA, Customer Support representatives and end users all be given a code-level view of the parts of the system with which they interact.

At this point I would point out that #iRXE isn't particularly concerned with behavioral "defect" reports and doesn't even admit the possibility of "developer mistakes" or "user error."

If human error is not recognized as a valid model where does that leave CDT + Agile #testing?

Without the concept of "developer error" and "user error" and "design flaws" much of Agile #testing becomes inapplicable.

The object of software QA since the 1980s has been to "detect" or "prevent" perceived "defects" before "bad code" reached the user.

👆🏼That's the OLD view.