You might have seen this video of robots running around after a football, getting up after falling, and kicking goals. I found it fascinating for a few reasons:

1. The AI was trained in simulation with the skills being developed in isolation. The skills were combined in a self-play setting. Like Neo in the Matrix they learned skills and combined them in real life.
2. The robots used external “vision” sources - i.e. they couldn’t actually see
3. Strategic gameplay was one of the emergent behaviours - e.g. anticipating where the ball will be

It also made me wonder if a sign of an artificial general intelligence is a strong opinion as to whether one should call it soccer or football.

(via Import AI)

Damon Krukowski’s essay Against Innovation is a sobering story for folks who make software. As a musician Krukowski relies on his software to keep working and to stay relatively constant. Every time it changes or breaks he has to learn something new. A few months ago, after going down a rabbit hole of dependencies following a supposedly standard upgrade, he had enough and took his studio offline. Krukowski values stability over everything else and the software can’t break if it doesn’t update, right? And of course, he was by no means the first to do this.

It seemed a clever solution to my small-scale, personal studio problem. But I was taken aback when some of the professionals who offered this advice said it is what they do, too. Even with their very extensive skillsets. Could it be that some of the most sophisticated audio technicians I know - mastering engineers in particular, those tasked in our industry with maintaining and constantly improving audio standards - choose to ignore innovation for the sake of stability?

Point at any software company older than 10 years and you’ll find a modernisation project. It’ll probably course of work covering a sprawling codebase chock full of features and a deployment process with plenty of bespoke steps, with an aim to bring both kicking and screaming into the current best practice. And for some reason the organisation will have put aside it’s usual engineering and product development processes and adopted a different way of working.

These projects can go two ways: either the project scope stays constrained and the software is updated or the scope balloons out into a “programme” covering an ever increasing pile of software, poorly researched architectural assumptions, and vague ideas about “cultural change” with the original idea disappearing in a sea of virtual post-its and Miro diagrams.

Generally the first case will pan out if there’s been some kind of real, positive change in engineering culture: for whatever reason the organisation wants to prioritise making their software better and improve their processes and pretty much everyone is bought in to the idea. The work gets done, and hopefully things are learned in the process such that something like “modernisation” is no longer a project but is business as usual.

In the second case, the buy-in isn’t there and the organisation tries to make things better as well as carrying on as usual. The disconnect is “solved” by adding people and steering and timetables and progress reports until the whole thing is almost self-sustaining.

What has any of this got to do with today’s video?

It’s a Noclip documentary about how Microsoft revived the Age Of Empires video game franchise by remastering the first three games for modern computers, then created a console version of each, and topped it off by creating a brand new Age Of Empires game. If you look at it from the right angle it’s a modernisation project that appears to have gone the right way.

In this case Microsoft’s general way of working still applied, but there was still that buy-in from every level. Sure, you can’t really compare video game remastering with projects to move an old UI to React or to try and implement continious delivery on an 15+ year .Net codebase but I think the documentary shows what needs to be true for a modernisation effort to succeed:

1. There are customers who want the modernised version of the software
2. The scope of the modernisation is clear and constrained
3. The team really understands what the software does and how it works
4. The work required to modernise the software is well understood and can be broken down into chunks
5. The project can be abandoned at any point if it looks like the eventual value isn’t worth it
6. There is still room to experiment and try new ideas
7. The work to modernise the software informs the further work, not just modernisation

Of course, those are the things that need to be true for any successful software engineering effort. Isn’t it funny how organisations forget that as soon as you chuck around the word modernisation?

🚀 NZ Tech Rally is a new developer community founded by Wellington-based developers, including fellow Xero Prae Songprasit. Their first event is in-person conference centrered around software engineering being held in early July. The theme is What does great software engineering culture look like, and how have kiwis done it?.

I’ve had a small glimpse into the work involved to get the conference off the ground and my hat is off to the team. It’s going to be great. I’ve purchased my early bird ticket and I’m looking forward to talks by Adam Howard, Jenny Sangh, and Katrina Clokie.

🏛️ Work-life balance looks different at the White House

You can find a reason to stay at work all night, every night here. There is always going to be something to do. You are never going to clear out your inbox. You are never going to return every phone call. You are never going to read every paper that you could. Ultimately if you do that, you’ll be worse at your job.

This short article reminded me about the key lessons of Four Thousand Hours and Getting Things Done: there is too much to do, so knowing what you can not do, and actually not doing it, is really important.

🛤️ What is the difference between Turbo and Stimulus, and what exactly is Hotwire? Every year or so I try to get a taste of the latest Ruby on Rails stack. This year I’ve come across a lot of new front-end focused stuff in Rails. This blog post succinctly describes the philosophy and mechanics behind the new tooling.

It’s about time I shared another great Nickolas Means talk. This one is from RubyConf 2022 and covers what happened at the Fukushima Daiichi nuclear power facility after the 9.2 earthquake and subsequent tsunamis that struck Japan in 2011.

As usual Nickolas Means tells a dramatic story with fascinating characters and just the right amount of technical detail. Then he dives into what we can learn as software engineers and managers. This particular talk is especially useful for leaders, with very clear illustrations of what to do and what not to do when faced with the worst case scenario.