Hiccupps

I bought a belt recently. Unexpectedly, it came with a tool for making holes and the notice above. My initial reaction was to chuckle and think "yeah, we could probably all learn something from that." But, honestly, that's just lazy. That's the cheap laugh. That's this misguided thinking:  DO NOT OPEN THE EDITOR BEFORE YOU FINALISE THE REQUIREMENT And I am so over that.  When asked what advice I would give to the early-career me I've often answered: get comfortable with uncertainty.  In the spirit of today's post, I might rephrase that as DO NOT HALT THE WORK BEFORE YOU ENCOUNTER THE BLOCKAGE Of course, this is what iterative development is predicated on. By the time we've coded what we can, and shown it to our customers for feedback, we might find that we understand the problem space well enough to not need answers, or that we were asking the wrong questions. What I like these days is to understand t...

  It's all relative. There's enough wrong in the world that having an imperfect job in tough economic times is still a privilege that many would cherish.  And yet, in its own isolated context, the daily grind can genuinely feel like being physically ground down, minced, fragmented.  Which is why it's important to find a glimmer of joy where you can. And I found one this week, in the accidental coining of the word cliction, a portmanteau of click and friction,  while exploring the user experience of a new front end. It doesn't solve any global, or even local, problems, but it raised a few smiles and lifted a few eyebrows, and improved my mood. I hope sharing it can do the same for you. Image: Gemini , " A close-up view of a human finger (drawn simply) gently touching or hovering over a single, large computer mouse button"

It's 14 years since I first posted on Hiccupps and one since I wrote about about  using trees for my mental health . Both practices are ongoing. Trees first: every Saturday I find a space with trees and spend a few minutes of silence with them. I breathe slowly and deeply and I look up through the branches to the sky, visualising a tangled journey into the blue, imagining it is my path to a better place.  The picture at the top is from the park around Schloss Lübbenau because last weekend I was in Germany but it can be any tree, anywhere. I have done it with a single tree on a quiet street corner. Blogging next: I am often asked why I blog. Sadly, I don't have a straightforward answer. On one level I just like to write. Before I wrote this blog I wrote a music fanzine for ten years. I genuinely can't remember when I didn't write something . It feels intrinsic, part of me.  My anniversary posts  talk about different extrinsic motivations at different times: I had exp...

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.