Hiccupps

This post is part of a series showing my working through the 2025 Advent of System Seeing exercises set by Ruth Malan. For background see the introduction .  This set of exercises is concerned with the location of a technical system within a social system. Spoiler: it only adds complexity. Day 17 Task : (1) Considering the situation you’re exploring: identify systems and their interrelationships. How far out do we zoom? What heuristics do you use? (2) Pick a (socio)technical system to focus on. Write a brief description of its primary purpose. I found the questions in the exercise the most interesting part of it this time. How far out do we zoom? This is the perennial problem in my world; I am always trying to find ways to judge whether I have gone far enough in the dimensions I have identified as relevant and hoping that I identified more or less the correct set of dimensions. Getting the opinion of others really helps, as the early exer...

This post is part of a series showing my working through the 2025 Advent of System Seeing exercises set by Ruth Malan. For background see the introduction .  This section of the Advent series is largely concerned with material I can't share in much detail,  a practical exercise exploring a real-life scenario at work. I've done the exercises and given at least a little commentary on the value of them here. Day 10 Task : 1. Draw an organization that you have been part of  at least 3 different ways (2) Jot down reflections  (3) Go "meta” and think about the views you drew.   As the task suggests, it's well known that org charts are, at best, an approximation of the way that work gets done in an organisation. The kind of diagram to draw depends on the perspective you want to obtain.  Many of my colleagues don't like Miro, but I love it because I can shuffle bits of model around until a view that helps me make sense of whatever I'm lo...

This post is part of a series showing my working through the 2025 Advent of System Seeing exercises set by Ruth Malan. For background see the introduction .  In this set of exercises, the idea of feedback is introduced. Feedback is at the heart of systems thinking because we humans seem to be primed to view the world as a simple linear cause-leads-to-effect machine in which only the causes and effects that matter are those that (a) we desire or (b) are glaringly obvious. Day 6 Task : Watch a video on causal loops and take sketchnotes.   I know and like this kind of diagram ( Be a Quality Detector ) but  I have struggled to build them for any system that I've looked at. In particular, I find the formal labelling of positive and negative loops to be more of a dark art than a science. The good news is that informality has proved sufficient for me up to now but perhaps I'll learn to be more formal on day 7. Day 7 Task : Practice using causal loop diagrams to understand inte...

This post is part of a series showing my working through the 2025 Advent of System Seeing exercises set by Ruth Malan. For background see the introduction .  The initial exercises introduce some core concepts and a couple of approaches to modelling, and encourage us to think about our work and the system we're looking at. Day 1 Task : (1) Draw a Bubble Diagram of a bicycle (2) Sketch a bicycle from memory (3) Pick a key capability [and use] sketches and words to explore and convey how it works (4) Reflect on what you learned.  I'm comfortable doing what I'd call "factoring" which tries to find different angles or features or affordances of a thing that could be useful seams to follow when testing. I've used plenty of tools, such as the Six Thinking Hats or SFDIPOT to help with that, and represented the outcomes with a mindmap often. Although my in-the-moment reflection says that I didn't find the bubble diagram helpful, I can see now...

My friend Patrick Prill posted some of his System Seeing practices at the start of the year. He is a systems thinker and nobody's fool so I guessed that if he valued Ruth Malan's Advent(ure) in System Seeing series of daily exercises it would be worth taking a look. I did. I agreed. I bookmarked it and then ... And then months later I came back to it. Although the activities are cast as an Advent series, in the spirit of Advent of Code , there's nothing seasonal about them and I can now say, having completed them, the things they talk about, the skills they encourage us to exercise, and the questions they ask are timeless, at least while there's still humans on this planet. This is how Ruth Malan introduces them: Each day of Advent ... there is an activity that is focused on the concepts and practices of system perceiving and understanding. This activity has instructions (which often include a visual canvas or model that can ...

You know when you suddenly realise you have an internal model of a chunk of the world that's been guiding your thinking and behaviour but you never realised?  I love that. The most recent instance for me was a couple of weeks ago when asked what problems I have with test data at work. That's when it became obvious that I have three broad categories of test data, and want something different from each of them. Of course I do! Duh. And why didn't I realise this before? Not sure. Perhaps I've never framed that kind of high-level abstract question, Maybe more often I'm interested in test data for the actual problem in front of me? Whatever, here's my initial draft of what I think I think... Data for specific logic. I use this in traditional regression tests that need a static expected result: unit tests, for instance. I see a lot of examples that have clearly grabbed runtime application data that's the right shape and bunged ...

How do you test a product with distributed logic and non-deterministic components? Well, it depends on the product and when the question is asked. This post is one answer, for now. A service I work on exposes an API for internal and external clients and calls multiple other services. It orchestrates a reasonably complex journey for a user, with their inputs and the responses of the services determining each step.  Our customers can configure the service to provide a variant of the standard journey for their users. This gives them choices on the available steps, the order of the steps, and, importantly, some of the logic for taking particular steps. This configuration lives in a different repository to the service, not owned by us, and it can be changed and deployed independently from the service. As you can imagine, we test our service in multiple ways at different granularities using the usual tooling, including unit tests fo...

In Looking Good, Testers!  I made the case that testing is about looking and that delegating the looking to someone or something  else involves a risk calculation: do you both understand the task the same way, is the third party likely to carry out the task in the way you requested, how easily can you check any results they give back, could they complement you in some way, how will you keep your knowledge and skills up to date if you don't do this task any more, how much does this task matter, how much do you care about any of that, ...? I didn't say anything there about selecting what to look at or for  ... and I'm not going to talk about it here either because it's essentially the whole of testing. I will note one thing, though: to find things other people don't find,  look where other people don't look .  What I do want to cover here is looking at things that, arguably, you don't need to.  My team was recently asked to add a new layer to a service we ow...

  Testing is inherently about looking because, put simply:  If you don't look, you're not likely to find. The interesting challenge is to look in the right way at the right place at the right time. This is what motivates any kind of intentional testing: how can we put ourselves in a strong position to look for, see, and — crucially —  recognise  the things that matter to the people that matter, when they matter?   --00-- Tools can help with this mission: using tools we can look more deeply, more broadly, for more complex patterns, for harder-to-spot traces, faster, more often, more efficiently, and so on.  There's a trade-off, naturally. As the tool takes us further from the material being worked on we must either trust it more or check its results more thoroughly ... to the extent that we care about the results. At a crude level, think of it as a spectrum. At one end we might have a knife. It's a tool I can use ...