Skip to main content


Showing posts from August, 2021

Fail Here or Fail There

The First Law of Systems-Survival, according to John Gall, is this: A SYSTEM THAT IGNORES FEEDBACK HAS ALREADY BEGUN THE PROCESS OF TERMINAL INSTABILITY Laws are all-caps in Systemantics . Not just laws, but also theorems, axioms, and corollaries. There are many of them so here's another (location 2393-2394): JUST CALLING IT “FEEDBACK” DOESN’T MEAN THAT IT HAS ACTUALLY FED BACK There was a point when I realised, as the capitalised aphorisms rolled by, that I was sinking into the warm and sweetly-scented comforting foamy bathwater of confirmatory bias. Seen, seen, seen! Tick, tick, tick! I took the opportunity to let myself know that I'd been caught in the act, and that I needed to get out of the tub and start to challenge the content.  Intervening at that moment was congruent: I was in a context where I would accept it and prepared to change because of it. Of course, I enjoyed the deep irony of nodding along with Gall when he talked about

See Plus Plus

Susan Finley's webinar for the Association for Software Testing , Making the Invisible Visible , has just been made available on YouTube.   It starts in the middle of an ongoing war room situation with a large group crammed around a small table, surrounded by empty coffee cups and the crumbs of long-consumed sandwiches. They are breathing stale air, they have perspiration on their brows, there is a production incident in full flow and they have no confidence that they understand the causes, the potential fixes, or even each other. The conversation repeats and circles and spirals back on itself until someone jumps up, sketches out a set of boxes and arrows on the whiteboard, and anchors the conversation on a model of the system. Suddenly there is shared context and understanding. That picture, Susan says, truly is worth a thousand words. The rest of the talk is focused on strategies and practices for reporting on the state of software, and this is very f

The Ideal Test Plan

A colleague pinged me the other day, asking about an "ideal test plan" and wondering whether I could suggest something. Not without a bit more information, I said. OK, they said. Who needs the plan, for what purpose? I asked. Their response: it's for internal use, to improve documentation, and provide a standard structure. We work in a medical context and have strict compliance requirements, so I wondered aloud whether the plan is needed for audit, or to show to customers? It's not, they replied, it's just for the team. Smiling now, I stopped asking questions and delivered the good news that I had what they were looking for. Yes? they asked, in anticipation. Naturally I paused for dramatic effect and to enhance the appearance of deep wisdom, before saying: the ideal plan is one that works for you. Which is great and all that, but not heavy on practical advice. --00-- I am currently running a project at the Association for Software Testing and there is a plan for