I spent 3 days at the QCon London conference, where I presented a talk about making change stick as part of Sophie Weston’s “How do teams really work” track. I’ve written a bit before about how useful I find putting a new talk together – it really helps me think through a topic and find patterns and lessons from my experiences (see “a lightning talk on lightning talks”). I might write some blog posts summarising my own talk in future – but for now, I’d like to write some notes about other people’s talks.

I saw far too many interesting talks to mention them all here – I’m going to concentrate on just a few that gave me ideas on things to read / watch / learn more about later.

The home computer that roared: How the BBC Micro shaped our world

Jeremy Ruston opened the conference with a look back at what made the BBC Micro such a special computer. He shared clips from a TV interview he appeared on aged 17: “South East At Six”, from 1983, where he’d built his own computer and published several books about the BBC Micro (one of them made the Sunday Times bestseller list – amazing how popular this machine was).

Jeremy explained how you could dive in and understood every part of the BBC Micro — how all the assembly works, what happens at every memory location. That feels impossible to do now with something like an iPhone.

He’s tried to build something similarly “understandable” with TiddlyWiki – I used that daily for several years to keep work notes, and haven’t thought about it in a long time! His enthusiasm when describing how different groups have customised and shared it made me want to take another look.

And the topic of thoroughly understanding a computer reminded me of something I’ve had on my “maybe one day” learning list for ages: From Nand to Tetris has lessons and course materials to build a modern computer, starting with a simple NAND logic gate and ending with you playing Tetris. It’s all online, for free – all I need is time and some motivation…

Patterns for efficient serverless development

I’ve hardly worked with serverless applications at all, I’m keen to do more. Yan Cui’s talk had lots of advice for things people commonly struggle with as they get further into this kind of work. I’ve seen posts and videos from Yan’s website, https://theburningmonk.com/, shared all over the place when people are struggling so I was very pleased to get an hour’s worth of good advice from him.

Testing is an area lots of people struggle with: how do you get a fast feedback loop, and confidence that what you see when testing is what’ll happen in prod? “Your application consists of more than just your code: your job is to ensure all of it works.” Yan explored various options and the tradeoffs with them, I’ll be reading more about this in his Testing strategy and TDD mindset posts.

He also shared some good advice that applies to all kinds of technology: “Just because features are there, you don’t have to use them”:

• Use Lambdas to transform data, not to transport data: Where other services can talk to each other directly, connecting them with a Lambda just adds moving parts you need to maintain and pay for.
• Lots of things like Lambda Layers are there to solve specific problems. If you don’t have that problem, don’t use them. For 90% of use cases, they just add complexity and make things more difficult, without bringing benefit.
• “These are medicines, not supplements”: definitely a phrase I’ll be quoting in future.

Yan’s got a wide range of online courses: the free “Learn you some Lambda best practice for great good!” looks like a nice first step.

Small actions, big impact: Catalyzing change in groups

Eb Ikonne started with a story of ways he’s messed up when trying to introduce change in organisations – a good start, I always feel talks are genuine if they’re talking about setbacks as well as successes.

Earlier in his career, Eb assumed you needed to be in a senior enough position to tell people what to do, so you can make change happen … but not only is that unnecessary, it’s often unhelpful. He talked about Mary Parker Follett (1868-1933), who introduced ideas including “power-over” vs “power-with”. Mary Parker Follett’s been on my “to learn more about” list for a while, this is a good prompt to read more.

• I first heard her mentioned (briefly) in Measure What Matters: at the same time Henry Ford and the much-maligned Frederick Winslow Taylor were introducing authoritarian, controlling models of management, Mary published ideas about collaborative networks and power sharing that were mostly unnoticed at the time, but have proved much more useful.
• I’ve heard more details about Mary’s work from Cat Swetel (in her Extended subtweet on power and elsewhere).
• It’s definitely time I read some of Mary’s writing… this post from Daniel Jhin Yoo has a good summary of Dynamic Administration, a collection of essays, looks like just what I’m after.
• And if you’re on Mastodon, you can search “follett from:@ruthmalan@mastodon.social” to find a great list of quotes and links from Ruth Malan, who’s been highlighting Mary’s work regularly for years.

Another good reference from Eb’s talk: Elements of a great invitation, from Peter Block.

I actually own a Peter Block book (Flawless Consulting) but have never read it! There’s also lots more online from him about building community and group change.

A game of patterns

Tiani Jones talked through the difficulties teams and orgs get into when they try to understand and improve things:

• Organisations are socio-technical systems … nice intro to that in this article from Tom Geraghty (with another reference to Mary Parker Follett’s work).
• We can’t expect to know the “right” changes to make, or predict the outcomes of our changes. We need to create the conditions for learning.
• Intervene carefully: every intervention you make is quite likely to cause new problems.
• For some work, standardising things makes sense. But then…. lots of organisations try to use those standard processes for everything. You need to be aware of bounded applicability (essentially, almost nothing is useful everywhere – but lots of things are useful in specific cases).

There’s a nice overview of the talk on the InfoQ site.

Tiani mentioned several topics I’d like to learn more about:

• Complexity in general: I’ve done a fair bit of reading about Cynefin but there’s always much, much more to learn.
• The Complexity Lounge meetup has past recordings and upcoming remote sessions from a range of speakers.
• Examples in the talk from how Tiani’s used an “Agile Base Patterns in the Agile Canon” paper made me want to know more – the paper’s free to download.

Applying AI to the SDLC

Tracy (”Trac”) Bannon gave a brilliant overview of the current state of AI “help” for the software development lifecycle. She started with a plea: “Please: don’t get caught up in the hype.” Promises of the next big thing that means we might not even need programmers any more have a long history – I’ve written previously about “The Last One”, a tool from 1981 that got a lot of media attention. Heard of it?

Trac says she doesn’t often agree with Gartner, but in their latest Hype Cycle they’ve got generative AI exactly where she’d put it – at peak hype, and 2-5 years away from its suitable uses being properly understood and implemented. That doesn’t mean you should ignore it – there’s lots of potential in it, and big change is coming – but lots of the big promises are not quite production-ready yet.

She’s done lots of real-word research, talking to people and trying things out, and recommends: If you’re using AI anywhere in software development: treat it like a young apprentice.

• Not an apprentice straight out of college, a very very young apprentice. Full of energy and potential, but always close to doing something disastrous.
• For manual testing, or explaining existing code, AI tools are surprisingly helpful. “Talking” things through can quickly help you think of cases you hadn’t thought of.
• People use AI for generating automated tests, but few trust it. Can hallucinate up all kinds of tests that don’t help with anything.
• Code generation: creates well-structured and well-formatted code. Sometimes the code even works.
• IDE helpers that suggest code frequently offer multiple options. In studies: Considering and picking between these leads to decision fatigue, slowing you down and leading to worse code.
• The code generated by AI is less secure. You can spot obvious issues yourself if you try it, and she referenced a Standford study that found these issues occur widely.

Some major challenges to making AI useful in the software development lifecycle:

• Is your SDLC already in good shape? Sprinkling AI on top can magnify existing issues. Fix your process first. To help people get a good process in place, Trac and others put together minimumCD.org – this looks wonderfully helpful.
• AI is nondeterministic; it lies to you. Can you trust it? Trac’s talked to Dr Nicole Forsgren about adding Trust as another dimension to the SPACE framework for measuring team productivity (only issue: that would spoil the nice acronym). If you had an AI team member whose work you had to constantly check closely, how would you feel about productivity?
• “Thought leadership” internally: you need to give people dedicated time to understand this, what’s happening in the industry and what it means for your organisation. That’s a big job.

Trac shared notes, all her slides, and an extensive bibliography – there’s stacks of interesting content there.

And that’s all

Well, that’s all I’m putting in one blog post. Apologies to the many other speakers whose sessions I enjoyed!