Remastering Age Of Empires, or how to actually run and complete a software modernisation project

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?

Monday Links 26

🚀 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.

The Magnitude 9.1 Meltdown at Fukushima by Nickolas Means

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.

Monday Links 25

🤖 I’m interested in the state of AI, how I might use it, and the possible repercussions on my work and the rest of the world. The best single place I’ve found for that is Jack Clark’s Import AI newsletter. It’s been the source of several Monday Links. An alum of El Reg, Jack Clark is the co-founder of Anthropic and was Policy Director at OpenAI before that. I mention all of this to demonstrate that Clark isn’t just a techbro moving from blockchain to AI, he’s a genuine expert and a bloody good writer.

📗 I recently finished Four Thousand Weeks by Oliver Burkeman. The subtitle of my copy is “Time and how to use it”. The American subtitle appears to be “Time management for mortals”. I think both of these do the book and author a disservice. The fundamental thesis is of Four Thousand Weeks is that time isn’t something we can manage or use. Our time on life is short and as long as we look for ways to make “the best use of our time” or to save time, we will probably always feel behind, or guilty, or disappointed in some way big or small. Burkeman makes the case that our quests to be more productive or fit more in generally make things worse because they just highlight how many things we could have done but didn’t.

Burkeman encourages use embrace finitude, to find meaning in the everyday, to stop trying to make a dent in the universe and look to making a positive impact on the people around us. Volunteer locally rather than found a startup. Enjoy the local hills rather than being determined to only be satisfied by conquering Everest. Realise that just like we are part of the universe, time is a part of us. Needless to say, I found the book quite refreshing.

Monday Links 24, but on a Tuesday


As part of embracing being open to work, I’m trying out Badger, a new tool for asynch, timeboxed, focused conversations. The group I’m in is centered around the networking aspect of Badger - it’s a collection of folks with a similar goal asking questions and sharing advice.

My favourite part of Badger is how you set up your profile: rather than retreading your LinkedIn headline there are several prompts you can choose to answer, some professional, some personal, some random. It’s a much more engaging way of talking about yourself.

I haven’t tried the audio feature yet. I think I’m a text guy. My Badger profile is open if you want to get in touch.

Cal Newport: What Kind Of Mind Does ChatGPT Have?

The response to ChatGPT, and to the other chatbots that have followed in its wake, has often suggested that they are powerful, sophisticated, imaginative, and possibly even dangerous. But is that really true? If we treat these new artificial-intelligence tools as mysterious black boxes, it’s impossible to say. Only by taking the time to investigate how this technology actually works—from its high-level concepts down to its basic digital wiring—can we understand what we’re dealing with. We send messages into the electronic void, and receive surprising replies. But what, exactly, is writing back?