With game programming there's a definite apogee of "code that needs to be done right," reached as the majority of the game features are integrated and gameplay

With game programming there's a definite apogee of "code that needs to be done right," reached as the majority of the game features are integrated and gameplay is proven. Before you hit that point, you're mostly getting things wrong, so you build it to 80% correct and when it breaks you refactor to 90%, 95%, etc., until you've hit the needed quality bar. (With experience you can get it "righter" on the first pass, of course.) Once you cross the apex you can start doing a mix of "cowboy coding" and pure low-level maintenance(bugfixes, optimization) to tighten things up for the user, because you have confidence in it being stuff that builds on a stable core. The hacks end up being the lowest-cost solution because the proper thing would effectively be a "99.xx%" refactor, getting more correct than you need and disturbing tons of decent, working code to fix the one problem. The game ships and then you rip it all apart for the next one anyway, so you never need that last bit. The trick with the code written for the 48 hour game jam games is to set the apogee point much earlier than normal, and live with lower quality implementation where possible(since you have control over game design, it's typically easy to find areas to sacrifice quality). It is very much in the Forth philosophy - do more by doing less. However, I get the feeling that improved - and especially more domain-specific - languages are the next step, because they allow the early stages of the project to be more correct from the start with less trial-and-error. You would reach more 9's in fewer iterations. This is borne out by the TCP/IP DSL paper ( http://www.oru.se/PageFiles/15389/Yan%20Wang%20Lic%20FinalVersion.pdf http://www.oru.se/PageFiles/15389/Yan%20Wang%20Lic%20FinalVe... )