My work break is going gangbusters. I’m firmly embedded in the pro-leisure circuit, the aim of which is to be like Jerry Seinfeld and do nothing. Seinfeld is right though, doing nothing isn’t as easy as it looks. I’ve filled my time with plenty of stuff: family activities, running and gym, gardening, meeting folks, and even doing stuff with computers. There hasn’t actually been a lot of actual nothing. Seinfeld puts it like this:

The idea of doing anything which could easily lead to doing something that would cut into your nothing and that would force me to have to drop everything.

I’ve been repeating that quote to a few folks recently and I was reminded of it again while listening to the latest Deep Questions podcast from Cal Newport.

In the deep dive section Cal talks about workplace overload and the causes of it. He cites the overheads of modern work - handoffs, coordination, context switching, etc as the major cause of overload and burnout. It’s not the writing of the strategy document, it’s the meetings and emails and IMs to discuss it that wear you down. Like Seinfeld with doing nothing, people find it hard to do their actual jobs because the idea of taking about doing the work could easily lead to having a meeting to discuss doing the work that would cut into actually doing the work and that would force you to just do more stuff.

Yeah, ok, I need to workshop that.

As you might imagine, I don’t miss coordination convos, nor do I miss planning meetings for the upcoming quarterly planning and I especially do not miss those Slack messages that just start with “Hello…”

Here’s the Seinfeld bit:

And here’s Cal Newport on overload:

Brendan Leonard: How Books Make Money

Ted Goia talks to an AI Music Historian

Adrian Cockroft: So many bad takes - What is there to learn from the Prime Video microservices to monolith story?

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?