Hiccupps

Jerome Groopman, in How Doctors Think , reviews ways in which doctors can make poor choices, identifies potential causes, and suggests some practices, for both doctor and patient, that can help to prevent them. I find this interesting for a couple of reasons: first, I work in the health space, although not in a therapeutic area and, second, I like to reflect on my own thought processes. I'll take three broad themes from Groopman's analysis: the business of healthcare and how that impacts a physician's ability to practice; the doctor-patient relationship and how that impacts the experience of both sides; and the cognitive failings that impact a correct and timely diagnosis for any given patient. Naturally, these overlap. The book is written from the perspective of the notoriously commercialised American medical system and is around 20 years old, so doubtless some of the details are different outside of the US and have changed since pu...

I'm slowly learning German ... for fun, believe it or not.  To limit my time commitment I've been mostly studying with lessons on apps or in-person supplemented by YouTube, ChatGPT, DeepL, blogs, an ancient CD-based box set that my well-meaning parents bought in a charity shop, subtitled German-language films and ... Peppa Wutz.   I've pushed ahead in some areas, for example by completing Babbel lessons all the way to  B2  even though I'm nowhere near speaking at that level, and starting again at  A1  even though I'm well past it. Being exposed to the advanced content can give some useful context, and redoing the basics can cement understanding, reinforce learning, and make connections that were missed the first time around. What I wasn't doing was rote learning verb conjugations, grammatical structures, or vocab lists. And that was fine for a long time, at least until I got good enough to have simple conversations...

I'm enjoying The Vernon Richard Show  a lot recently because the vibe Vern and Richard have created is one where two knowledgeable and experienced mates talk around a topic they are both interested in with curiosity and open minds.  Also, there's less football than there used to be. This week's show is titled When Everything Sounds Like Testing… How Do You Explain What You Really Do?  and sees the pair discussing the meanings of quality assurance, quality engineering, testing and other related terms. There's no firm conclusions, and enough left unsaid that they're carrying the dialogue over into the next episode, but I was still interested to see these two models put forward: In the first, proposed by Vernon, quality engineering consists of preventing bugs (QA) and detecting bugs (testing). In the second, floated by Richard almost in spite of his better judgement, quality assurance is the holistic term. In this ver...

  Over on the Agile in the Ether  Slack instance one of the Ethernets recently asked: MoSCoW: Does anybody have a simple way of explaining when items should be Must vs. when they should be Won't? Is it really as simple as whether it's an inclusion or an exclusion of the item? MoSCoW  is a basic approach to grouping project project work into buckets graded by priority: M: must have S: should have C: could have W: won’t have (for now) I'm sure every one of us has been in conversations where the buckets are filled and then stakeholders say they're all emergency-level important, but that's not today's problem. In this case the questioner had been burned by people twisting the words in unhelpful ways: " must not do ..." (i.e. won't) or " won't  do without ..." (i.e. must) which only makes the often fraught prioritisation discussions even less pleasant.  I have found MoSCoW to be useful so I share...

The theme at  LLEWT this year was Rules and constraints to ensure better quality.   My experience report concerned a team I'd been on for several years which developed (bottom-up) a set of working practices that we called team agreements.   The agreements survived "natural" variation such as people leaving and joining and even some structural reorganisation which preserved most of the team members but changed the team's responsibilities or merged in a few people from a disbanded team. The agreements did not, however, persist through a significant round of (top-down) redundancies where the team was merged with two others.  I'm interested in thinking about the ways in which constraints on how people work affect the work and whether there are patterns that could help us to apply the right kinds of constraints at times they are likely to be useful.  I'm going to use this post to dump my thoughts. My starting po...

It was my wedding anniversary recently. The picture at the top is the front of the card I got for my wife. Yeah, I know. Somehow she still loves me. I asked my family which bean out of the couple they thought I was and everyone chose the one on the left, including me. Surprised, I showed the picture to my work colleagues and they also unanimously went for the left-hand bean. Why? Here's some of the reasons I was given: the legs it's spilling its drink, like a man would the light reflecting off the top of the head  the man always stands on the left in wedding pictures  it looks like you I don't want to go deep into this, especially that last point, so I'll just observe that despite strong surface agreement there was significant hidden misalignment in motivation. Like so many projects I've bean on. 

Maaret Pyhäjärvi  posted the quote above on LinkedIn a few weeks ago. It speaks strongly to me so I asked Maaret if she'd written more (because she's written a lot ) on this specific point. She hasn't, and the sentence keeps coming back into my head and I'd like to understand why, so I thought I'd try to write down what I take from it. I think it's easy to skim read as some kind of definition of exploratory testing but that would be a mistake in my eyes.  Testing by Exploring  summarises how I felt last time I went into the definition in any depth and, for me, Maaret's quote is concerned with the why  but says nothing of the what or how . But let's say we have a shared definition of exploratory testing, would I make this statement this baldly generally? No, I probably would not. Why? First, it's written in very personal terms (" my time", "the best testing I could") and, second, as a  contex...

I attended LLEWT 2025 at the weekend. LLEWT is a peer conference  hosted by Chris Chant, Joep Schuurkes, and  Elizabeth Zagroba in Llandegfan  on the island of Anglesey, North Wales. This year's theme was Rules and constraints to ensure better quality: Think of things like WIP limits, zero bug policies, trunk-based development, not allowing any form of interprocess communication except through service interfaces that are externalizable, or just firing all your testers so the devs have to step up. (Yes, not all of these are a good idea all of the time.) Some terms related to this theme are forcing functions, poka-yoke, and behavior-shaping constraints. Basically we're looking for any rule or constraint you put in place to get to better quality. (Some systems thinking might be required.) The format of LLEWT encourages proposals for experience reports on the theme, takes feedback on the proposals, an...

I'm been working on an application that will orchestrate data from multiple services. As the developers add clients for those services, they have been writing integration tests and, naturally, many of them use mocked data. Mostly the data consists of non-trivial JSON response bodies full of domain-specific terminology captured during interactions with the other services. Consequently, many of our tests reflect this complexity and domain-specificity by asserting on its data structures and particular terms. This is functionally fine, but problematic for readability because test intent can be hidden in a mass of incomprehensible word salad. Again, this is usually fine for the author when writing the test because the intent is front of mind but it's problematic for other readers, including the author later. I have been vocal about this drawback and today one of my colleagues asked me to summarise my prescription for it. Without thinking I said this, and I ...