Approaches in software development — or anything else — that don’t take ordinary human failings as their starting point are prone to dramatic failure. "The Impossible Human" is, well, noticeably uncommon. Let’s dig in on that.
More geek joy comfort food from me today, but please think & work outside the monitor by enabling and encouraging change in our wider world.
Black Lives Matter.
Some years back, I made content for a CMS that had a whole lot of overlapping parts, each with its own special language. I found it very difficult to express myself quickly & cleanly, and, it being me, I complained about it a lot.
And very often, the responses I received were in the form of "It’s easy, just remember X." It still being me, I became sullen and resentful, and was largely unproductive for long stretches.
"It’s easy, just remember these 371 simple rules" is a formula for disaster, because it’s an approach based on "The Impossible Human". Ordinary humans don’t remember 371 simple rules about anything they haven’t already mastered.
Now, of course, extraordinarily unlikely humans do exist.
Some of the easiest ones for us to share and witness are the great sports heros. MJ, let’s say, or Serena. These are, to an arbitrary error epsilon, patently impossible humans.
But we never build a basketball system on the assumption that our team will have twelve MJ’s. And we don’t build a Davis Cup team with six Serena’s, either. Because there aren’t twelve MJ’s or six Serena’s. There’s one of each.
Humans have astonishing capabilities, both "built-in" and "learnable". But they also have astonishing frailties, built-in and learnable. And any approach to utilizing the former must absolutely also account for the latter.
To be sure, there is no such thing as an "average human". The space of possible humans is too high-dimensional for averages or bell-curves to have useful meaning. Any such average would point to an empty space into which not a single human on earth actually fits.
(That’s not psuedo-science. Look into Gilbert Daniels’s work on measuring just 10 physical characteristics of pilots. Even that was too many dimensions to make "average" meaningful. When he reduced it to just 3 measurements, he got < 5% of his enormous sample to be average.)
Can we say anything about our imaginary average human?
I think, if we abstract our way out high enough, we can. We have to do so with a light touch, and we have to accept the vagueness that comes from an analysis that’s so meta-, but I think we can say a thing or two.
My ideas about harvesting the value of change, elaborated out in terms of advice for the software trade, are all attempts to get at these meta-level observations about human strengths and weaknesses. What we are, on imaginary "average", good at, and what we are poor at.
A side note: why worry in particular about human strengths & weaknesses. Software development methods combine humans, procedures, and machines. In one sentence: in these tripartite systems –human, procedure, and machine — the human term dominates the results.
For instance, humans have rigid limits on their mental reach, even when they utilize the ingenious mechanisms, naming, chunking, stacking, scanning, their brains supply. Noticing this, I frequently advocate techniques that assume it.
When I say take many more much smaller complete steps, part of my rationale is in noticing this attribute of our "imaginary average human".
Smaller steps require less mental bandwidth, fewer things to remember, fewer live entities to juggle while working.
The techniques of microtest TDD, of continuous integration, of trunk-based development, these are the positive advice that comes from this observation.
My general resistance to repo-branching, to sprint-length stories, to long methods and large classes, to implementation inheritance, this is negative advice coming in part from that same observation.
Of course, and very much not a coincidence, smaller steps, and that self-same technical advice, goes quite well with another "imaginary average human" attribute: our taste for short-term gratification and our need for rhythm.
The world is full of Aesopian fables about the benefits of delayed gratification.
But we’re not actually good at that, especially when the enterprise we’re engaged in is regarded as merely instrumental to our mission, for most of us taking care of ourselves and our loved ones.
Add rhythm into that mix, alternating multi-frequency cycles of tension and release, and again, smaller steps, the same advice.
There are people who run, every day, as part of their routine — or, anyway, I’ve read about such weirdos — and tho some of them will speak of the great higher goal they achieve, the vast majority of runners, in a quiet moment, will tell you they do it because it feels good.
Endorphins matter to us. And the same endorphins are released by rhythmic multi-frequency tension and rerlease as by running every day. Both can acheive long-term faraway goals. But both operate by delivering gratification — partial, incomplete — to their practicing humans.
Another example of an imaginary average human trait, the one that actually got me started: humans make mistakes. Lots of them. Lots and lots. No. More. Humans make a lot of mistakes.
And though we very often assign human mistakes to failures of will (or morality), that’s actually mostly not the case.
Humans weren’t built for navigating the modern world.
They are the result of navigating yesterday’s world, and the day before, and the day before, stretching back a very long ways.
We like to think of ourselves as creatures of reason, but the important word in that phrase is "creature", not "reason". We make thousands of choices every day before the first zoom meeting even starts. It is ludicrous to think that mistakes are a rare exception.
Anyway. There are others. Our gift/need for social interaction. Our ability to sense things we can’t say or even know. How lousy we are at objective probability. How hard it is to break mental inertia. How susceptible we are to experience over argument.
It comes down, for me, to this: what I seek is an approach to software development — the whole trade — centered on the humans in the system. And I think we need to start by incorporating not just their strengths, but their weaknesses, as well.
Support GeePaw
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. You can also subscribe to get weekly posts sent straight to your inbox. And to get more involved in the conversation, jump into the Camerata and start talking to other like-minded Change-Harvesters today.