Hiccupps

  Hands up if you think the world needs another format for retrospectives.  Yeah, right.  Yet here I am. Last October it was clear that we were becoming jaded. After a phase of novelty themes (at the festival, NSYNC, 8-bit video games, ...) and a long stretch of Stop Start Continue , engagement in our retros was sliding. So when it was my turn to facilitate I wanted to find a different format and I had some specific requirements in mind: a simple and intuitive structure, invitations to express feelings, and opportunities to be publicly grateful.  I didn't find an existing template that fit the bill so I made one up, just four columns in a basic table with these headers: Kudos to ... 'cos of ... I like it when ... I feel meh about ... I don't like it when ...   I expected it to be a one-off palate cleanser but it's proven popular and we've been using it for six months straight.  There's no originality in those categories, by the way: I see a strong fami...

My friend Patrick Prill continues to dissect the growth, use, and risks of AI in our industry at the rate of an article or two a day, each one teasing out a particular thread from the very tangled issue ball. ( Here's yesterday's.) I recommend reading them for a thoughtful and detailed analysis and reflection on today's software and social ecosystems and the ways that AI is reshaping them.  They certainly make me think and, as with last week's Hedging Your Bets on AI , I find it helpful to capture those thoughts as analogies, so here's another. A very long time ago I wrote a music fanzine: A5, photocopied, 50p or a quid, sold by a scruffy long-hair in a German army jacket out of a battered record bag in the back rooms of pubs between bands. I remember well when domestic studio and CD-R technology became affordable because the volume of submissions for review increased dramatically ... and the overall quality likewise decreased. The technolog...

My friend and colleague Patrick Prill has been writing articles about AI in our industry at a prodigious rate over the last couple of weeks. (Here's  the second of yesterday's pieces.) I recommend reading them for a thoughtful and detailed analysis and reflection on today's software and social ecosystems and the ways that AI is reshaping them. I can't compete with the breadth, depth, or frequency of his output so, although this post is on the same topic, I offer only a short analogy.  Step back in time 60, 70 or 80 years and wander through England's pleasant pastures. You will see lanes and fields bordered with hedgerows maintained by skilled workers, living and breathing boundaries, functional for keeping stock in and intruders out but also a component of the local ecological web. Hand-laid hedges are habitats. Birds nest in them, rodents and small mammals use them like a road network to travel safely around the landscape, larger animals use them as windbreaks or f...

In 2024 I wrote a post, An AI Red Light , about a creative project I did with my daughter using both AI and "traditional" tooling. This was my conclusion: I think we were pragmatic in our choice of tools. Where our vision required control (video) we used a tool that gave us that control. Where we were happy to cede some control in exchange for output at a quality we could not produce ourselves (vocals) we used a different tool.  I didn't set out to do some kind of AI experiment. Instead I set out to have some fun with my daughter and found tools that enabled us to produce something, some art, that we're proud of and I'm happy is our work. For sure, we were sometimes more creators and sometimes more curators, but at no point were we ever mere spectators.  Two years down the road I have access to, and use, LLMs in my work. With them, I have been able to make things that I would not have done without them such as the user interface on my model-based dialog walker .  ...

There was a time when testing was all about the mnemonics . Well, we had no AI back then so thinking about our human craft and how to share what we had learned using our human intelligence with other engaged humans for later recall in their human heads seemed important. But this post isn't about dumping on AI. It isn't about mnemonics either even if WTTWTH does look like something that'd fit well into that ancient world.  No, this post is just a snappier version of what I said to my team this week when I was walking through some testing I'd done the day before. It was concerned with a change to a particular turn in the dialog system we're building where multiple variables are in play, some populated by an external call to an LLM service.  I wanted to make the point that the bulk of the testing work was done in the research I did and the spreadsheet I made, not in the interaction with our product. That spreadsheet was the result of me looking in our service's cod...

The Wikipedia page on infinite loops in programming describes them as "a sequence of instructions that, as written, will continue endlessly, unless an external intervention occurs." One common example might be a while loop whose exit condition is never met, and needs to be aborted by a human pressing Control-C . With that concept in mind, we can make an easy analogy to software development where the same kinds of events happen over and over and over until our product becomes irrelevant, or uneconomic, or our organisation closes down, and the loop is exited.  Inside the loop, the world in which our product exists will change, the market in that world will change, the requirements on our product in the market will change, the product itself changes as our teams add features, or fix bugs, or update libraries, or run on new platforms, and so on.  So, for their lifetimes, our products inhabit an infinite loop of change and, if the...

I was guest speaker for a software testing class at EC Utbildning  a couple of weeks ago. I talked about one of my hobby horses — using automation to amplify my ability to explore — and I'll give the same talk at the Ministry of Testing Cambridge next Tuesday. Perhaps you can make it? Chatting with the Swedish students on the call before my presentation I asked what they liked about testing and, as no-one seemed to want to go first, I gave my own answer: I enjoy testing because it mixes technical, social, and intellectual challenges. And that's true but it isn't always enjoyable in the moment . Last week at work, in a small group session, I offered to share my screen while we tried to exercise and then, when it wasn't working, debug some new monitoring functionality. Honeycomb is a valuable tool, and I've used it plenty of times, but not at an expert level. The instrumentation we'd been developing is based on existing...

In Your job is to deliver code you have proven to work  Simon Willison writes: As software engineers we ... need to deliver code that works — and we need to include proof that it works as well.  He is coming at this from the perspective of LLM-assisted coding, but most of what he says applies in general. I think this is a reasonable consise summary of his requirements for developers: Manual happy paths: get the system into an initial state, exercise the code, check that it has the desired effect on the state. Manual edge cases: no advice given, just a note that skill here is a sign of a senior engineer.  Automated tests: should demonstrate the change like Manual happy paths  but also fail if the change is reverted.  He notes that, even though LLM tooling can write automated tests, it's humans who are accountable for the code and it's on us to "include evidence that it works as it should." Coincidentally, just the week before I read his post I told one of my...

In yesterday's Angry Weasel newsletter, Leadership is a Constant Experiment , Alan Page was explaining how, as a leader, he gets better results by trying things intentionally, in public, in a safe way: But in real work, confidence isn’t the superpower. Curiosity is.  I feel this too, although confidence, or the appearance of it, can get you a good way up the greasy pole, if that's your chosen destination.  In a post on LinkedIn today, John Cutler made an analogy between a software development teams and a restaurant kitchen where busyness is not a useful metric, and success means that great food is delivered as ordered in a timely fashion. He sadly concludes that: ...  in software, effort is easy to generate, activity is easy to justify, and impact is surprisingly easy to avoid. This is a tragedy that plays out over and over. My primary goal in software is to help us to metaphorically put the right food on the right plates on the right table at the right time more oft...