This one’s about a simple SCAN crossmap that may be useful for making sense of what underpins engineering, and how it works the way that it does.
Anyway, here’s the crossmap:
The role of engineering is to take things that may well be rare in the natural world, and create conditions under which those things can occur consistently, reliably, efficiently and more, to achieve some desirable outcome.
(To give a practical example, consider just how rare it is to see a gas-explosion in the natural-world: an unfortunate overly-flatulent cow caught out in a lightning-storm, perhaps, but that’s about it. Now consider how that exact same process has been made to occur, maybe hundreds of times per second, inside the engine of the car you drive to work each day – and you’d complain, and loudly, if it didn’t work in the way you’d expect! That’s the near-miracle that engineers have created over the past few centuries in our seemingly-‘normal’ world.)
The core of engineering is the same as Bill Mollison’s description of the core-principle of permaculture:
…protracted and thoughtful observation rather than protracted and thoughtless action.
In SCAN terms, we’d place much of that “protracted and thoughtful observation” in the Ambiguous domain, because it takes place away from the action, yet also inherently somewhat uncertain – at the start of that “protracted observation”, anyway.
Yet the aim of engineering is that its outcomes should apply in real-world action, in as predictable and certain a manner as possible – and, for preference, action that is ever more predictable, reliable and certain. Which, in terms of the SCAN frame, is in its diametric opposite – the Simple domain, or what I’ve labelled ‘(task)‘ in the crossmap above.
One theme that comes again and again in context-space mapping with SCAN is that ‘diagonal’ moves won’t work, or at least won’t work well: they always lead to ‘sins of dubious discipline‘, which in turn lead to bad outcomes. For engineering, trying to go straight from exploration to routine implementation – in SCAN terms, the direct diagonal-path from Ambiguous to Simple – is what leads to clunky, half-assed kludges, or half-baked ideas that don’t have enough anchors in reality.
To make it work well, we need to take an indirect route: either ‘across’, then ‘down’, via what I’ve labelled as ‘Science’ in the diagram above; or ‘down’, then ‘across’, via ‘Art’. Or, more usually, a combination of both.
We go through ‘Art’ for new ideas and to try out what works, or doesn’t, in the real world. For example, Beveridge’s The Art of Scientific Investigation has distinct chapters on the roles of ‘Chance’, and ‘Intuition’, and the specific disciplines needed to make them work well – both of those themes being characteristic of the Not-known domain. In SCAN terms, the respective transitions are between Ambiguous and Not-known, via the ‘edge of innovation’:
And then between Not-known and Simple, via the ‘edge of panic’:
Note that we can’t use ‘Art’ to test or evaluate, because that isn’t how the Not-known domain works. (For more detail on this, see the Artist role in the post ‘Sensemaking – modes and disciplines‘.)
We go through ‘Science’ to test against theory, to provide suggestions from theory, and to move ideas and experiments towards repeatable processes. This is often described by the misleading term ‘applied science’ – misleading because science itself is not the real driver here. In SCAN terms, the respective transitions are between Ambiguous and Complicated, via the ‘edge of uncertainty’:
And then between Complicated and Simple, via the ‘edge of action’:
Note that we can’t use ‘Science’ to provide any new ideas, or action, because that isn’t how that domain works. (Again, see the Scientist role in the post ‘Sensemaking – modes and disciplines’ for more detail on this.)
The catch is that we do need both ‘Art’ and Science’ for this – it’s not ‘one-or-the-other’ here. And we need the right mix of both, in order to create technologies that can work well with real-world sameness-and-difference, at any requisite scale. There’s a real Goldilocks challenge here, for every engineer:
- if we allow ourselves to get stuck in ‘Art’, we’ll over-focus on difference, and end up with non-scalable ‘craft’ that can’t be made repeatable or replicable for anyone else
- if we allow ourselves to get stuck in ‘Science’, we’ll get caught up in analysis-paralysis loops, and never cross the ‘edge of action’ to make anything real
Just enough art and ambiguity, just enough science and certainty: that’s when engineering works well in the real-world!
Comments, anyone? Hope it’s useful, anyway.