Hiccupps

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 functioning 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, stock animals use them as wind...

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...

Last night I was at the Cambridge Tester meetup for a workshop on leadership. It was a two-parter with Drew Pontikis facilitating conversation about workplace scenarios followed by an AMA with a group of experienced managers. I can't come to work this week, my cat died. Drew opened by asking us what our first thoughts would be as managers on seeing that sentence. Naturally, sadness and sympathy,  followed by a week ? for a cat ? and I only got a day for my gran! Then practicalities such as maybe there's company policy that covers that , and then the acknowledgement that it's contextual: perhaps this was a long-time emotional support animal . Having established that management decisions are a mixture of emotion, logic, and contingency Drew noted that most of us don't get training in management or leadership then split us into small groups and confronted us with three situations to talk through: Setting personal development goals for others. Dropping a clange...

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...