NZ Tech Rally 2023 was a tremendous success, with top-notch speakers and genuinely useful and entertaining content.

A particular pleasure for me was Adam Howard’s talk titled Fostering a quality quality culture. Adam and I were team mates and I was lucky to see Adam and his team transform Xero’s approach to quality engineering. This talk, and the model Adam describes boils several years of experimentation and hard work in to a succinct, repeatable framework for improving practices by enabling communities of practice inside an organisation.

Adam’s blurb:

Quality is a slippery notion, and not something that can simply be manufactured and measured. In that sense, it’s a lot like culture.

And just as culture is emergent from a peoples’ values and behaviours, quality emerges from teams’ principles and practices.

In this talk, Adam describes a model for shaping those principles and practices in engineering teams that can nurture a culture of quality engineering.

Reliability, constant work, and a good cup of coffee

If you make coffee one cup at time, like a trained barista does, you can focus on crafting each cup, but you’ll have a hard time scaling to make 100 cups. When a busy period comes, you’re going to have long lines of people waiting for their coffee. Coffee urns, up to a limit, don’t care how many people show up or when they do. They keep many cups of coffee warm no matter what. Whether there are just three late-night diners, or a rush of busy commuters in the morning, there’ll be enough coffee. If we were modeling coffee urns in boring computing terminology, we could say that they have no scaling factor. They perform a constant amount of work no matter how many people want a coffee. They’re O(1), not O(N), if you’re into big-O notation, and who isn’t.

Pat Kua: Happiness

Many leaders feel that it’s their responsibility to make their team happy. While having happy team members is an admirable goal, it’s also not the sole focus of leaders. A leader has failed if people are happy, but the team has yet to make progress towards their goal. Happiness can also be elusive. You might offer challenging work, a supportive and friendly environment, compensate well, and someone may still be unhappy. Happiness is a choice; you can’t “make” someone happy.

On-call at any size is a great primer for orgs thinking about upping their resilience and reliability game. Will Larson’s Incident response, programs, and you(r startup) is an essential companion piece.

Simon Willison pointed to this comment on the orange website last week and it struck a chord with me:

So far I also survived:

• xml is the future
• let’s use nosql for all the things
• you must use the same language at the back and front
• yes, you site must have an AMP version (ah, you forgot this one, didn’t you? It was sooo imporant, and then pouf, it was gone like tear in the rain)
• you can’t code anything without async
• yes, your home page must be an SPA
• you can’t live without a message queue
• everything must become a micro service
• of course you need a container for that
• of course you need a orchestrator to organize those containers
• of course you need the cloud, it would be crazy to deal with those containers and orchestrators yourself
• dude, why do you have a server? Use a serveless backend!
• dude, why do you have a backend? Just call saas from the edge!

Every year, some generation of engineers have to learn the concepts of “there is no silver bullet”, “use the right tech for the right problem”, “your are not google”, “rewriting a codebase every 2 years is not a good business decision”, “things cost money”.

In April I posted about finishing up at Xero after almost ten years. At the time I expected to be on the pro-leisure circuit for at least three months, but I came across an intriguing role at The Co-operative Bank, and I’ve been the Head of Development, Testing & Security for the last four weeks.

Honestly, it has been a bit of a whirlwind. There is much to learn about the bank, the people, banking in general, and challenges of building software keeps customers and their data safe but also easily allows them to access and manage the banks services. I’m having a gret time.

Johan Abildskov presented Automation is Hard! at GOTO Copenhagen in 2022 and it popped up in my feed while I was on the pro-leisure circuit.

If you’re on board with the practices discussed in the likes of The DevOps Handbook and Accelerate then it might be a little bit preaching to the choir, but if you’re still figuring out how to improve the stability of your software and the speed at which you deploy it, this is a bloody good talk.

The blurb:

Automation is a key part of any efficiency project and of being a successful software organization. But the way we as an industry approaches automation hinders our success and puts a stop in our track.

In this talk, I will cover some of the ways we set ourselves up for failure, as teams, orgs and engineers. Of course, you will also leave with a few sound practices to address the issues presented.