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?