Hiccupps

You've almost certainly heard of the Prisoner's Dilemma : two members of a crimimal gang are captured and interrogated separately. The police tell them both they are looking at a year in prison but offer a deal if they squeal: less time for incriminating their colleague. There are three scenarios: No-one talks: the default one year each One talks: the talker goes free , the other gets three years Both talk: both get two years  The dilemma is whether to remain shtum and trust the other will do the same  or  to spill the beans with the risk of an extended stay in prison but the potential reward of walking away scot free.  Given that they are sure the other would be prepared to rat them out, the rational individual's strategy, according to game theory, is to talk even though there is a better group outcome in not talking. --00--   The Prisoner's Dilemma is merely a well-known example but there are many other games with different setups and constraints. I came acros...

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

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

In What We Know We Don't Know , Hillel Wayne crisply summarises a handful of research findings about software development, describes how the research is carried out and reviewed and how he explores it, and contrasts those evidence-based results with the pronouncements of charismatic thought leaders. He also notes how and why this kind of research is hard in the software world. I won't pull much from the talk because I want to encourage you to watch it. Go on, it's reasonably short, it's comprehensible for me at 1.25x, and you can skip the section on Domain-Driven Design (the talk was at DDD Europe) if that's not your bag. Let me just give the same example that he opens with: research shows that most code reviews focus more on the first file presented to reviewers rather than the most important file in the eye of the developer. What we should learn: flag the starting and other critical files to receive more productive reviews. You never even thought about that possi...

Why wouldn't you just give up? The system under test has poor testability which means that the testing you'd like to do will take longer and the resolution of your findings will be lower than you'd like. So do you give up, battle through, wait for someone to add what you need ... or change the product yourself ? There are potential risks to that last option, of course, because (duh!) you're changing the product. But there are potential wins, too, because you're getting the data you want earlier and can give richer feedback to your stakeholders. I took that route this week.  The service I'm looking at is essentially a pipeline of steps, each of which calls out to a third-party service and post-processes the result, set up like this: result1 = step1.run(input) result2 = step2.run(result1) result3 = step3.run(result2) I wanted the response time for a large number of requests against its API, which I can get easily from the client ...

  I was pairing with my friend Vernon at work last week, on a tool I've been developing. He was smiling broadly as I talked him through what I'd done because we've been here before. The tool facilitates a task that's time-consuming, inefficient, error-prone, tiresome, and important to get right. Vern knows that those kinds of factors trigger me to change or build something, and that's why he was struggling not to laugh out loud. He held himself together and asked a bunch of sensible questions about the need, the desired outcome, and the approach I'd taken. Then he mentioned a talk by Daniel Terhorst-North, called The Best Programmer I Know, and said that much of it paralleled what he sees me doing. It was my turn to laugh then, because I am not a good programmer, and I thought he knew that already. What I do accept, though, is that I am focussed on the value that programs can give, and getting some of that value as early as possible. He sent me a link to the ta...

The big story in IT right now is Crowdstrike 's unfortunate update that prompted millions of Windows machines to BSOD and caused chaos in critical infrastructure around the world. Actually, that's not just big, it's BIG or B. I. G. or maybe B! I! G! and it's provoked loads of speculation about the hows and whys and what-should-haves and what-didn'ts. But even on a week without that scale of fail, even on a week where nothing untoward happened on any computer anywhere, the observation I'm sharing here probably wouldn't merit much coverage.  This is it: Do you see? Just under the orange bar, the word OLIVE. Why? Don't get me wrong, I like olives. I just don't expect to see them on the BBC Sounds player while I'm setting myself up to listen to England win the cricket at the weekend. Of course, if you look a bit closer and wait a second or two, you'll see that there's a slight vertical alignment difference between the O and LIVE and the th...

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Developers can’t find bugs in their own code." I'm not usually so blunt unless we know each other well but, to my mind, if you mean what it looks...

  The science first ... Stigmergy is a term for individuals collaborating or coordinating through the effect of their actions on the environment. It comes from the study of animal populations which demonstrate sophisticated emergent behaviours without any obvious control structure or even direct communication. If that sounds too abstract, think about wasp, ant, or termite colonies and the level of organisation suggested by their complex nest-building, foraging, feeding, and breeding patterns. You've probably heard about scent signals. Stigmergy observes that an individual will mark the path to a food source and that this influences the behaviour of other members of the community. They in turn also mark the path, reinforcing the signal and bringing still others to it.  If there are alternative routes to the food then the one which conveys most benefit, perhaps by requiring less energy to reach, will tend to get reinforced more. It can be instru...

A while ago my team was asked for estimates on a customer project that had become both urgent and important. Unfortunately, but not unusually, there was a reasonable amount of uncertainty around the customer need and two possible approaches were being proposed.  It fell to me to organise the team's response. First off, should we refuse to estimate? Woody Zuill talks compellingly about #NoEstimates approaches. In Control, or the Fear of Losing It I summarised his perspective as: We think that we estimate because it gives us control. In reality, we estimate because we fear losing control. The irony, of course, is that we aren't in control : estimates are inaccurate, decisions are still based on them, commitments are also based on them, projects overrun, commitments are broken, costs spiral, ... Ron Jeffries has a typically nuanced take on the idea in The #NoEstimates Movement : How to apply #NoEstimates isn’t entirely clear. ...

Last night I attended How to TDD a REST API, a webinar by Gil Zilberfeld . In it, Gil described an experiment he's running to try to use test-driven development for a service built with Spring Boot in Java. As part of this, he is building unit and API tests at the same time. The code is available in GitHub and you can follow the kindergarten moves he talked us through by reading the src and main directories in parallel in numerical order. What insights did he get from his experience? Well, as you might expect, with all the additional weight of a framework and internal and external dependencies, there is a lot of friction.  But he still thinks there is still value in using TDD, or perhaps its spirit. His recommendations include: small steps a hexagonal architecture for aggressive abstraction very thin adapters (code that interfaces your code to the external world) code and data that is framework agnostic as far as possible small steps refactoring eagerly for readability refactori...

Tonight I watched Fundamental Principles of Organisational Design with Doug Talbot , hosted by Cambridge Agile Exchange .  Doug has built a model of organisational design which he uses to assess status, identify targets for change, prioritise changes, and design interventions intended to achieve them. The model is based heavily on experimentation, deep reading, and hard-won experience in the broad area of software development practices, projects, and companies. The model identifies nine areas of importance using a matrix of three columns concerned with creation (teams and structures, building the right thing, building the thing right) and three rows concerned with company behaviours (leadership and principles, policies and tools, day-to-day practices). In some sense this is a meta model onto which others can be mapped. For instance, Scrum is located in the lower middle-right (building/practices) while sales incentive programs are middle left  (teams/policies). Doug notes tha...

Last week, unexpectedly, I became a Licensed Scrum Master. I knew I was attending a course run by Scrum Inc  with a group of my colleagues, but I had no idea that there was a short online multiple choice exam and a certification for me at the end. It's easy to be sceptical and sniffy about the industry around Scrum, but I try to go into training events in a positive frame of mind , looking to participate, open to having my views changed. I'm not sure that there was a seismic perspective shift for me on this occasion, but I still thought it'd be interesting to run a personal retrospective. Some background first: I've never worked on a Scrum team, although I manage testers on them. I'm very interested in ways that software can be developed and tested, and one of my favourite books in that space is  Extreme Programming Adventures in C# by Ron Jeffries, a great practical example of iteration, reflection, and honesty. A disclaimer too: without much visibility of...

  We play tricks on ourselves, Woody Zuill says. We think that we estimate because it gives us control. In reality, we estimate because we fear losing control. The irony, of course, is that we aren't in control : estimates are inaccurate, decisions are still based on them, commitments are also based on them, projects overrun, commitments are broken, costs spiral, ... Spending more time estimating typically doesn't make us better at estimating but it does take time away from doing.  Zuill's experience is that it's possible to build software without any estimates by taking an important piece of functionality, building only the absolutely critical pieces of it, and then putting it in front of someone. The doing, and the review of what's been done, will help to determine what should be done next. Sounds simple? Yes, but it's not easy . It's crucial to find allies and customers who are ready to accept it. Here's my tidied-up sketch...

George Dinwiddie recently delivered a webinar, Distilling the Essence , on the topic of crafting good examples of acceptance criteria. From the blurb: When creating our scenarios, we want to fully describe the desired functionality, but not over-describe it ... Which details should we leave visible, and which should we hide? ... [We will see how we can] distil our scenarios down to their essence and remove distracting incidental details. I loved it and, naturally, wondered whether I could distil the essence of it . Here goes: Not just examples, but essential examples. An essential example promotes shared understanding, testability, clarity of intent. Remove incidental details; they obscure the important. Highlight essential details; they have the most communicative value. Essential details don't change with user interface, workflow, implementation technology. To help: name scenarios, abstract specifics, note explicit rules, conditions, and boundaries. Bottom-up is O...

I took my daughters to the  We're Here. Hi! Let's Play  pop-up exhibition about women in computer gaming that's running as part of  Where Did All The Women Go?  One display board caught my eye: Research shows that women play games just as much as men do. This fact is often dismissed using the argument that women don't play 'proper' games. A stereotype has emerged that women mostly play 'casual' titles, like puzzlers and tile-matching games, that shouldn't count in this research — but who gets to decide what gaming is? All forms of media have this problem: film buffs disparage blockbusters and literary critics dismiss genre fiction. The difference with gaming is that both sides are becoming gendered. Men are seen as the serious gamers and women as 'causals' with lower skill and investment in the medium. These attitudes risk excluding female players and preventing new ideas from flourishing in the industry. That s...

Last weekend, one of the testers from my team was speaking at Developer! Developer! Developer! East Anglia , a .NET community event. Naturally, because I'm a caring and supportive manager — and also as it was in Cambridge, and free — I went down to have a look. Despite not being a developer, it wasn't hard to find something of interest in all five sessions, although it's a shame the two talks on testing were scheduled against each other. Here's thumbnails from my notes. Building a better Web API architecture using CQRS (Joseph Woodward): Command Query Responsibility Segregation is a design pattern that promotes the separation of responsibility for reading data (query) from writing data (command). A useful intro to some concepts and terminology for me, it went deeper into the code than I generally need, and in a language and libraries that I'm unfamiliar with. I found  Martin Fowler's higher-level description from 2011  more consumable. I do like listenin...

After I blathered on and on about how much I'd enjoyed Ron Jeffries' Extreme Programming Adventures in C#  the Dev Manager  offered to lend me his copy of  Extreme Programming Explained  by Kent Beck. Some background from  Wikipedia : Extreme programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project. Beck became the C3 project leader in March 1996 and began to refine the development methodology used in the project and wrote a book on the methodology (in October 1999, Extreme Programming Explained was published). So I took the book (it's the first edition) and I enjoyed it too, but differently. I might say that if Adventures is a road trip, Explained is a road atlas . One of the things I liked about Explained (that it shares with Adventures) is the suggestion that only you can really decide whether XP can work in your context, and how. Also that Beck is prepared to offer you suggestions ...