Any software system begins as a shared narrative about a problem and the people who come together around solving that problem.
If you don’t accept the above proposition completely then nothing I have to say about software is going to work for you.
Chthulhucene Devops: staying with the trouble as a service
This is and always has been the core proposition of my “way of Devops.” Which I am now finally able to articulate and which I differentiate from other devops as Chtulhucene Devops, so as to acknowledge that it is not “mine” in any sense except as far as I know I am its sole practicing engineer. Designers and executives and other leaders may practice it — but developers mostly have a hard time with the tolerance for chaos required for what Donna Haraway has so insightfully now labeled: “staying with the trouble.”
Software is narrative
The problem with intelligent communication is the illusion that it has taken place.
– GB Shaw
Suspend your disbelief and just run with this for one minute if you will: commercial software is a narrative about a problem and the community of people who come together around said problem. Note that I haven’t said anything about money or value streams yet. That’s the beauty of this approach: you start at the highest-possible view of the project: the gods-eye view. This is what the narrative approach can deliver to you, the confused but eager software hacker-er.
You see, a big problem in software – the main problem – is that you wake up one morning and find that you’ve spent 3 months building the wrong thing. It seemed like the right thing 3 months ago, communications got dropped, mistakes were made, it’s wrong now. This can happen so easily with software.
The problem of what was it even supposed to do in the first place
In order to not build the wrong thing we must know with clarity what we are meant to be building. It sounds like a tautology and if we were talking about any medium but the digital medium it would be a tautology. But as all software engineers immediately come to learn, there is a Lovecraftian, Non-Newtonian gulf between “what we build” and “what we were meant to be building.”
“Know what is meant to be happening not just what is happening” is anything but a tautology in software. It is a yawning conceptual gulf that can swallow projects whole.
How do you know what is meant to be happening?
As people we have something called an inner narrative that we compare to the external happenings in the world and that’s how we do sense-making. The thing is that the “external happenings” of the world aren’t external at all. Events in the world around us impinge on and irrevocably merge with our “inner” narratives.
The world is made of stories
Stories are how we do sense-making. Stories are literally the tool that allowed us to come down from the trees. We couldn’t master fire until we could fashion a story about how to master fire.
But with fire there was a physical thing to point to: the thing that is on fire. Get that thing. Such were our stories. For almost our entire time on earth as a species, stories were basically: there is thing, do something with thing.
But now we can’t use that narrative any more even. Because with the digital domain there is no “raw material” that we start with to create products. That this is the case causes a lot of mis-spent Web budgets, because it is counterintuitive so people tend to budget in spite of it not in alignment with the reality that Web products all begin as stories and some are less fictional than others.
There is no thing
A monk asked Joshu, a Chinese Zen master: `Has a dog Buddha-nature or not?’
Joshu answered: `Mu.’
In software there is no “thing” that you can point at. In order to point at a “thing” in software you have to construct the thing, starting with the environment in which the thing is going to exist.
You always have to design both “the product” your customers want and “the environment” in which your product will run in production. Thus any software product begins with two obvious categories of “work to be done.” People ignore this because it seems counterintuitive.
Now you have two problems
A programmer has a problem and says I know I’ll use Perl.
Now they have 2 problems.
This is a class of Boundary Problem – you always have to design the environment your software product “lives” in, no matter how hard you try to isolate your project from the vagaries of its environment.
This observation generalizes and goes back at least to Wittgenstein who said of Boundary Conditions in general:
Can’t we imagine a rule determining the application of a rule, and a doubt which [it] removes — and so on?
Further reading
Complete list of Software As Narrative posts so far.
For further reading on this and related chtulhucene devops topics, please visit the further reading page.