This week’s links got me thinking about how much of what we do as quality engineers isn’t about creating a specific outcome, but about influencing the factors that lead to it.
But why don’t systems just do what we want?
How much easier would it be if we could specify the outcome, create a process, add a practice or three and wait for our desired results to materialise?
Unfortunately, systems don’t work this way. What happens depends on feedback, constraints, incentives, context and how people and machines respond along the way.
This week’s links explore that through testing, AI agents, engineering practices, influencing teams and organisational change.
Latest posts from the QE Newsletter
Two posts this week.
Speaking up is only half the story looks at what happens after someone takes an interpersonal risk and speaks up. We can’t make people speak up, but we can influence how we respond when they do and create conditions that make people more likely to do it again.
I also revisited an older post on testability, bringing in some of the ideas I’ve been exploring over the last few years around feedback loops, uncertainty and how quality emerges from the conditions around the work.
Psychological safety shows up again here too. So many of our feedback loops depend on people being willing to make what they know visible. Without that, even well-designed technical feedback loops can only tell us part of the story.
Testing at the speed of stupid
Testing is not a manufacturing race against coding. Its purpose is not to generate test-shaped material at a matching velocity. Its purpose is to discover risks that matter before reality does it for us.
If testing is just about discovering risks, then, to me, that can start to sound a bit like bug catching. I like to think of discovering bugs and risks as a side effect of revealing information about your system.
Testing from that frame is about reducing uncertainty. You can’t get to 100% certainty, but you can find good ways to lower the uncertainty that matters.
That means building layers of feedback throughout our systems rather than just testing at the end. With AI-generated software, I think that also means building in evaluation so we can understand more about the outputs being created and how reliable they are.
And because we’ll never remove all of that uncertainty, we also need graceful failure, observability of the live system and other approaches that minimise the harm our systems can cause. Via Testing at the Speed of Stupid by Keith Klain
What sits behind AI productivity?
most teams never cared much about quality and had no solid understanding of what good looks like pre-ai tooling capability. If that’s where you’re coming from, and most teams are coming from that position, then of course you just create mess at scale.
I’ve been wondering how people familiar with quality engineering, XP and other good engineering practices would work with LLMs. Paul appears to be using a lot of these techniques and getting some pretty impressive results.
What stood out to me is that he doesn’t really sound like a software engineer or a quality engineer. He sounds more like a product engineer using software engineering practices to build products. Maybe this is a glimpse at where software development is heading.
One example I really liked was building a CLI specifically so the AI could interact with and test the system. Building one purely for testing might feel like too much overhead on a lot of projects, but with an AI agent it gives it a way to exercise every feature without having to constantly navigate the UI. Screenshot tests can then give another layer of feedback about whether the UI itself is behaving as expected.
He’s also using practices like mutation testing, which teams often skip because of the additional time and effort involved. If AI makes some of that effort cheaper, perhaps practices we previously thought were too expensive become much more viable.
What I find interesting is that the productivity gain doesn’t seem to come from simply asking an AI to write more code. There seems to be a whole engineering system around it giving the AI ways to test what it creates and get useful feedback.
Maybe the teams that get the most from AI won’t be the ones that generate the most code, but the ones that already understand how to build good feedback loops around the work. Via On average, teams are gaining only 16% in productivity by adopting AI that doesn’t surprise me | Paul Hammond
Teleonomy
... to tell a story you have to have a goal and a purpose. Computers do not have a sense of purpose and can’t be given one.
There is a word for what computers are: teleonomic.
Teleonomy is used by biologists to describe processes and structures that look goal driven but don’t have an innate sense of purpose behind them.
LLMs in particular can look like they have a goal. You can even give them one, but that doesn’t mean they understand the purpose behind it. They are producing outputs that fit the goal we’ve given them.
So what kinds of goals are we giving LLMs? And are we intentionally giving them constraints around how they should achieve them?
Via A friend who is a fiction writer remarked that LLMs make great editors | Noah Sussman
Hugging Face hack by OpenAI
OpenAI removed safety filters for an in-progress model, locked it up in a sandbox and told it to solve the ExploitGym problems. Given the absence of guardrails there was nothing to prevent the model from attempting to break out of that sandbox, break into Hugging Face, and read the answers from there instead.
Simon Willison did a breakdown of how a new OpenAI model unintentionally hacked Hugging Face. It reminded me of what Simon previously referred to as relentless proactive agents.
Give an agent a goal without enough constraints and it may keep finding ways to pursue it.
It’s unlikely we’ll get access to completely unconstrained models any time soon, but this does highlight something important. Getting the result you asked for isn’t necessarily enough. We also need to understand how the system got there.
As these agents become more capable, that feels increasingly important. They might achieve the outcome we wanted, but not in a way we would ever have chosen ourselves.
This feels like a modern version of the monkey’s paw. Instead of being careful what you wish for, perhaps we need to be careful what goal we set, and what constraints we put around it. Via OpenAI’s accidental cyberattack against Hugging Face is science fiction that happened
Show don’t tell
People don’t see your motivation. They see criticism. They rarely understand why you bothered, and they almost never appreciate it. Worse, most people don’t learn from advice at all. They learn from consequences. They have to touch the stove themselves. Words bounce off; pain sticks.
From a QE perspective, I think we should keep this in mind when working with teams. We’re not there to win arguments. We’re there to help create more of the outcomes that lead to quality than not.
So we should pick our battles wisely. If a team doesn’t want to move in a particular direction, trying to force them as a QE is going to be a real struggle.
Instead, I think we sometimes need to meet teams where they are, move with them and look for opportunities to nudge things in a better direction. Then let the outcomes do some of the talking.
As Cong says in his post, build the thing and let the results change their minds. As QEs, that could mean finding the teams that do want to move in the same direction as you, helping them make it work, and then showing how they’ve benefited from the approach.
Via Why I Stopped Arguing With People | A Geek’s Page
Why change fails
Mark Eddleston has been writing his new book out in the open, chapter at a time, and it’s well worth your time.
One tension I’ve had with my QE newsletter is not giving enough step-by-step practices and frameworks for people to follow. But what Mark helped me understand is that probably isn’t going to work for a lot of people.
Sure, you can apply the approaches, but will your team and organisation then be practising quality engineering? Maybe, but most probably not.
Why? Well, it comes down to complexity. You need to understand your context and apply the ideas to the problems you actually have.
Linear frameworks and processes can give the impression that if you just do this and then that, you’ll be doing the thing. But that hardly ever works in complex systems.
Mark’s book explains why, and it’s also why I tend to keep things quite high level in the newsletter, sharing ideas and ways of thinking about quality engineering rather than prescribing exactly what people should do.
We need to take those ideas and work out how they apply in our own contexts.
Quality is emergent, so the best we can do is try to create the conditions for quality to emerge more often than not.
Via Mark Eddleston’s Why Change Fails
If you enjoyed this, you can subscribe to the Quality Engineering Newsletter for more reflections on quality engineering, testing, systems thinking and how we create the conditions for better software.
It’s free to subscribe, and you’ll get new posts and Linky editions straight to your inbox.
Past Linkys
Linky #35: The definitions influence the system
One thing I’ve noticed over the past few weeks is how often conversations about quality eventually come back to definitions.
Linky #34: The system around the output
This week’s links are mostly about the system around the output.
Linky #33: The stewardship problem
This week’s links made me think less about whether AI can help us create more software, and more about what happens after that software exists.
