In the talk, he picks out his top ten principles for collaboration in building great software. I think these are worth highlighting and repeating and applying to the software development ‘industry’ in some way. Bear in mind that Id Software created the biggest games of the 90s including Doom, Quake and Castle Wolfenstein and run as a small team in the 90s with a handful of developers, no source control for the most part and everyone working in the same room.
I’ve borrowed his slides from youtube, so I hope he doesn’t mind me sharing his wisdom! Check out the original for context and more explanation of the slides.
I’m representing these in the order that they are given in the talk.
So let’s start!
A no-brainer for modern software dev teams. Use CI/CD to ensure that you have code that is always shippable. Use automated testing to verify quality and shippability.
Defensive coding may or may not help your situation but having sensible defaults ensures operability at least – not suitable for all circumstances. John mentions making default usage VERY obvious, though.
Great advice for any individual or team. How simple can you make your code? What do you hope to achieve by making it more complex or mystical? Think about how someone else will look at your code.
Does this still apply? You bet. Even in the world of a million DevOps tools there is always space for something new. Check out the open-source world for examples – google is your friend. When you find yourself doing something manually over and over again – that is your cue to automate it. If you can’t automate it simply, perhaps you need to build a tool to do that?
Good advice for that developers to ensure that there is adequate testing in place before they commit their code.
Fix bugs now. Ensure that your CI can run regularly and quickly to validate your changes in an integration test.
This you might say is a no-brainer but John has a nice story about almost buying a Cray supercomputer which puts it into context!
Slight contradiction in the presentation because while John says that this is important, he also says that elements are always used between games/projects when they can’t be written any better. So keep an open mind about re-use. Code like it’s the first time but keep a weather eye on the future.
This relates to how a user experiences certain elements of gameplay. Functionality which should go together in terms of experience should be encapsulated or at least graphed so that consequences happen logically. This is great food for thought in terms of your architecture. How will your architecture impact the user experience?
Great advice for any team. Ensure that anyone can pick up the code you’re creating. Ensure that you’re aligned with the best practice.
I think these 10 principles can still be applied across any software project. Notice that there is an emphasis on maintainability and cleanliness of code, quality and openness. If you apply these principles then your code will be lean, well-maintained and have low technical debt. This ensures that you’re actively avoiding anything becoming legacy before its time.
When it comes to writing clean, modular, performant code, there really has to be fewer better than John Romero and John Carmack and the rest of the team. Best to heed their ideas and think about this some more. I certainly will.