Thread by @allspaw

Contrary to popular belief (tooling marketing and some SRE/Ops/Infra writings) the “substitution myth” continues to hold and I think it requires repeating. @courtneynash summed it up best (more than 3 years ago now!) in this way...

(oreilly.com/ideas/ghosts-i…)

Another way of putting this is:

This means that every time you read promises that a tool will genuinely *relieve* people of doing some task, flip your skepticism bit HARD. The reason this marketing tends to be effective is that it fits with a common belief in what’s known in the field as “functional allocation”

Functional allocation is more commonly known as the “HABA-MABA” perspective. These lists of activities that “humans-are-better-at, machines-are-better-at” sits at the core of assumptions behind many designs and even predictions about technology’s effects in the future (AI, etc.)

(Aside: you’ll find searching around that this was also known as MABA-MABA, with the gendered ‘men-are-better-at’ - thankfully this bit has evolved.)

Anyway, the idea of course is to give each (people and machines) the parts that they’re good at, and “voilà!” - efficiency! Here’s the 1951 representation of this...

The substitution myth flies in the face of this idea and has been replicated in multiple studies in multiple domains across *decades* of research. To run with these antiquated ideas is akin to building a database while ignoring the fundamental concepts of distributed systems.

(Aside: I believe that this stance — belief that HABA-MABA is a productive design director — is commonly applied when people look to reduce so-called “toil.” That is a different topic.)

Here’s an accessible description of how belief in the substitution myth can play out:

I think we can imagine other examples in software. Take k8s — the benefits of implementing it may bring benefits or “relieve” engineers from specific tasks or concerns, but introduces new ones that were not present before: new failure paths, new mental models & dependencies, etc.

I urge folks who read this entire thread - read @courtneynash’s article above, then read the references she points to.

As to the most productive reaction to the HABA-MABA and substitution myth: it’s called Joint Cognitive Systems and centers on making automation a “team player” - much has been written about this, and I’ll share two things to consider. One is @ddwoods2’s “patch” for HABA-MABA:

And the other is a paper that outlines the fundamentals necessary in order to make software a “team player” jeffreymbradshaw.net/publications/1… <- this has all the basic concepts to address

Question is: can you make the leap from those concepts to implementing designs in *your* context? FIN