Service your code
In the past week a friend of mine tweeted that debugging took so damn long, because he had to compile a lot of code, load the game and wait until the level was loaded before he could test one specific feature. From experience this can easily take more then 10 minutes of your time, while to solution is only a boolean check that needs to be inverted. One of the solutions I proposed was to put it in a DLL and dynamicly load (and re-load) that code until you have solved the problem and as I was typing it out I realized that this could be applied more often.
If you create a core application against which does only a few core elements (like basic rendering and providing input) and you put the rest in DLL which can dynamically be loaded and unloaded you will in theory never have to touch the core application again. The rest are all buildingblocks which are continuesly improved. If you do this, you can easily rollout (or rollback) features. Even cooler is that with another product you only have to write a few new buildingblocks (assuming you continuesly improve your old buildingblocks), create new content and your done.
If after a few years you want to re-release your game but you want to use the improved render, all you need to do is replace it. No more memory leaks the old version had 
But for that we need to continuesly serivce our code, something I believe is rarely done.
June 3rd, 2011 - 15:45
That’s pretty much the philosophy we had in mind when building our engine for specialization/graduation projects. We have a core that doesn’t even do rendering, just provides basic things like logging, math library stuff, a tick loop and all the other basic stuff you need to do systems development. Everything else is either loaded dynamically from a DLL (and should be hotswappable, theoretically) or, if you so desire you can compile it into the binary with relative ease (just a few preprocessor switches, some restrictions apply though).
June 3rd, 2011 - 16:42
Damn, I hate it when pressing escape to often causes the input to cancel, now I write it all again…
The philosophy as you stated seems to be similiar in to what I had in mind but after reading your last blog entry (http://blog.wussie.nl/2010/11/status-update, really 2010?) I was wondering: Have you also been able to play this philosophy when writing game code?
Game code often seems more tightly coupled, which means that the philisopy gets a whole lot harder and in addition we often store logic in data files (layout & animation of the GUI is an example). I also know that AI War used a database to perform their logic.
Anyway after reading your blog it’s clear to me I need to do a little bit more thinking about this philosophy.
By the way, is it possible that I can have a copy of your research thesis/paper? It seems like a good start and I’m intressted in how much our philosophy match.