05 April 2011

Are Game Developers 15 Years Behind The Rest of Us?

Game developers have a reputation, deserved or not, of being a nasty unwashed rabble with no process, no discipline and no skills outside of graphics performance and playing video games. They shoot from the hip, stay up all night and cut corners to hit the ship date, just like all developers, but they commit these sins to a much greater degree than the average developer, or so it goes.

It seems much more common that games developers, as opposed to non-game developers will not have automated unit testing and measure code coverage, adopt agile processes, use proper source code management systems, have proper backups (!), do code reviews, track bugs and do continuous integration.

Obviously, there are going to be game developers who do follow these engineering practices, but a reputation is a form of stereotype.

So I'm wondering how much truth there is in this or if it's a total myth.

Are game developers really less skilled in the big picture of software development? Are they really 15 years behind the rest of the industry on common best practices? Do their knuckles really drag on the ground? And if so, why?

I'm no expert in game development but I've always been very interested in it. My observation of a number of game projects and my contact with several game developers suggests there are a number of factors that could contribute to the possibility that game developers do not follow many of these practices.

Games Projects Are Not Like Other Software?

It seems true that game projects are usually dominated by a media production workflow. Like CG movies, modern AAA megabudget console titles have teams of artists who churn out gigabytes of high quality graphics and other media. The game project's process and its project management is totally dominated by the needs of this media production. Game project managers are quite often called "producers", the companies that make games often call themselves "studios" and, like movies and music, there are "publishers" who handle distribution and marketing. Funding models for many game studios likewise seem to follow the movie industry.

Interestingly, indie developers react strongly against this model of game development and argue that better games are the true goal, not bigger budgets.

By contrast, a multi-million dollar non-game software project will have a team where visual design work, including "UX" (user experience) design, often takes up less than 10% of total resources. By contrast, software developers and possibly business analysts (the equivalent of a game designer) will represent the majority. Obviously there is huge variation here, but the contrast is clear.

The basic idea behind this factor is that the division of labour on the project tips the scales towards a different set of best practices. Ones that are, arguably, better for making the cost-benefit tradeoffs and  managing the risks of those projects.

Game Developers Don't Know Better?

I've been told that game developers mostly started in their bedroom and their skills have not expanded very far due to lack of exposure. Nobody convinced them to use unit testing, so they don't do it. Game development tends to be a passion. I know lots of skilled developers outside of game development who started coding all night in their bedroom. But just like they no longer use BASIC or name their variables with expletives, they no longer code games. I'm describing myself too here, I started programming like this.

Another aspect to this is that a lot of self-professed game developers participating in online discussions about this stuff literally are kids in the bedroom!

This factor is not very convincing but it seems that the game development sector is separated from other software development and the rule of passion is enforced in game development companies in both directions. Game developers feel strongly that they would never want to work on other projects and game development companies have a strong policy of only hiring people who have a passion for games. If this were true for Insurance companies, they'd never find candidates. People don't get passionate about insurance. Part of the truth of this factor may be that the segregation of game developers is so strongly self-policing.

With some exceptions, there are still not many game development courses run by universities, whereas the materials in the general software engineering and computer science courses are often specifically tuned to non-game industry problems. Think of the number of examples in programming tutorials about e-commerce or payroll!

This lack of tertiary education might not be such a big deal, except the game developers I've spoken to think that it is. They believe that game development is a speciality that needs special courses. Managing the media pipeline mentioned above is often cited as a part of this. As are the fast-moving hardware technology advances such as GPU architectures and the iPhone-style app-store project publishing aspects of the game industry. Business IT courses are only gradually starting to touch on this.

Games Don't Ship Upgrades?

Traditionally, games are shipped in their final state.

Back in the olden days people bought physical media in a physical retail outlet. I'm only partially joking here, clearly that method is quickly disappearing and luminaries like John Carmack have predicted next-generation consoles to cater predominantly to online distribution. Games that require dozens of gigs of media have seemingly had no alternative but to rely on ever increasing optical media densities to ship their bits.

While most games these days seem to have upgrades that are made available online, these are universally free, contain bug fixes only and are staffed minimally. Games do not generally go through the same lifecycle as, say, Microsoft Office where a new version of the same software is released on a regular basis and customers usually pay to upgrade.

The effect of this is many of the practices in non-game software development that pay off only in the long term don't seem to be worth the trouble in the short term.

While this factor may have been true in the past it is becoming increasingly less convincing across the board. With the rapid growth of gaming segments such as MMOGs, casual games and mobile games on always-online devices like iOS and Android phones and tablets, I expect a greater proportion of games to get their revenue from long-running projects that include multiple upgrades or in-game purchases that fund continued development of the software.

When the software is under continual development, as is most pronounced in SaaS, the payoff for the investment in quality engineering practices becomes more obvious. Games that are developed without such practices, as with non-game projects, will often become bogged in technical debt or suffer disasters that severely impact the businesses behind them.

By contrast, those game development studios that adopt automated unit testing regimes and invest in infrastructure like modern version control systems (e.g. Git, Mercurial) and Continuous Integration (CI) not to mention bug tracking and potentially things like code review, have a potential competitive advantage that can lower the cost of development over time.

Games Can't Be Unit Tested?

I've heard several game developers, state that game development is different in a technical sense such that unit testing (and other related engineering practices) are not suited to game systems. While, when pressed, these people will concede that certain parts of game development are like any other software in their suitedness to unit testing etc. they argue that there is a fundamental mismatch.

To be frank I find this argument to be just as weak as it is in non-game development projects. I'm not saying there is nothing that can't be unit tested because that's not even the question. The question is whether the effort spent on unit testing is outweighed by benefits derived. The trouble is that the vast majority of "things that can't be unit tested" that I have been shown over the years are really just design problems in the code that only become apparent when a unit test is attempted. Making a small change to the production code fixes this problem. For those developers (both inside and outside game development) who have never gained the benefit of a good regression test suite, the idea of changing the production code to make it easier to test sounds like pure madness.

Of course it's not pure madness, it's just the scientific method.

Game Projects Are Too Hardcore For That Crap 

I've heard this one from game developers who, let's just say, do their bit to perpetuate the stereotype of the macho code-all-night-eating-pizza-guzzling-caffeine-optimising-the-engine dude. All nighters are not generally seen as sustainable by most enlightened teams I've worked with and whenever it's done it's seen as fail. Fail happens. Heroic efforts are sometimes necessary. And if you feel that the burn out that results is a badge of honour then it can be kind of fun. It's like the pride an extreme sports junkie has of their broken limbs and sick x-rays. We all know this is true because most of us have been there.

Like a "breakdancing battle" I remember many schoolyard bragging sessions about how many sprites I could animate on screen at once. My friends challenged me to make more impressive graphics than them and I relished the challenge. I believed in my ultimate mental power over the machine. I felt invincible and omnipotent in my coding. And when I look back on the code I wrote then I can barely read it.

Perhaps it's optimal and can't be improved. Only half of that is certain. It can't be changed at all. I'd rather disassemble a binary than read my own teenage source code.

But while it may or may not be fun, it's not sustainable or profitable, except in very narrow windows of opportunity.

To some game developers, game development is like going to war. You have to be tough like a soldier and all the props and niceties of civilian life (unit testing, source control) are luxuries you don't get on the battlefield of a game project. There's no time. There's too much chaos and that goes with the territory. Game projects necessarily have grueling schedules because they must to survive. It's a tough market and if you're not prepared to wade through the swamp in combat boots and 30kg packs then you're not cut out for game development and you should go back to the unicorn and rainbow world of civilian development because you are soft.

I think these guys (invariably this is a guy thing) are delusional. They're living in their own game world.

This sort of attitude will convince starry-eyed coder kids of who has the most chest hair, but it seems to blind some game developers to the simple fact that games are made of the same material as all software: source code. Software practices are solutions to a common problem: a faster stream of features with an acceptable level of performance and an acceptable defect density, not to mention making the right direction and priority decisions.

In the past I would have been more convinced by arguments about the absolute need in games for hyper-performant code and crazy schedules but these days I think those things are less true. As with non-game development before it, the necessity of maximal performance is becoming a marginal one, suited to fewer projects less of the time. Games used to win success on technology and now this happens less than ever.

The online games markets, especially so-called "casual games" have grown phenomenally in recent years such that established games companies are taking notice of new generation companies that understand the importance of community, longevity, and viral distribution channels like facebook.

I think we'll see more legacy game code.

All of this suggests that the majority of game companies are less and less like the mega hit tech-driven games of the past few decades and a larger part of the growing gaming market is in projects that could easily benefit from decent software development practices. Maintainable code, automated test coverage etc. 

Small Projects?

There are a lot of small software projects in the games industry. Small iPhone projects probably don't have enough bugs to warrant industrial strength bug tracking, especially when the whole team is sitting around one table and the duration of the project is less than 6 weeks. 

Several of the engineering practices I've mentioned seem to better suit larger teams and projects, releasing versions on a regular basis. Small projects that aren't like this arguably find benefits of these practices are reduced.  

Absolutely I consider this to be a relevant factor for code review and sophisticated bug tracking, but I think more of the reason for small game projects not having source control or unit testing are questionable. 

Flash, for example, very popular for online games, strikes me as one of the worst platforms to integrate source control and unit testing into. I've done some flash programming and I just gave up and went with the flow. No unit tests and no source control. 

I survived.

However if I was going to write games in Flash on an ongoing basis, I would find the flashunit framework I'm sure exists, and if it doesn't I would build it. I'm vaguely aware of methods in Flash and ActionScript to solve source control issues like merging and you can bet that I would prioritise getting that stuff working. If I had a team working on a MMOG in Flash, I would make sure I put in a Continuous Integration engine, probably Bamboo and not just because I work for Atlassian. After saving my arse several times I'm convinced these tools and practices are worth the trouble to set up. Hopefully my fellow game developer team mates would not be resistant.

What Do You Think?

I'm not presenting this stuff about game developers as fact, and I'm making a lot of generalisations, a lot of assumptions. I'm not trying to insult any game developers, in fact I'm interested in learning more about game development, especially on the tooling, process and architecture side.

Am I being unfair? Am I out of date? Am I wrong?

Feedback, flames and factual corrections are most welcome.


  1. Hey Chris,

    Great post. One thing I thought of is - where do "games engines" fit into all of this? Like the "Unreal" engine, or the "Quake 3" engine. That seems to be at least one component of a produced game that kinda looks like a traditional piece of software - it is initially released, licensed for other projects, improved (presumably?), released again. So I wonder - when creating these engines, are the non-game software practises more likely to be applied? The product undoubtedly has a longer lifespan, and if you were a game developer wanting to pay for a license to use a third-party engine, you'd want some kind of guarantee on it's stability and the quality of the code?

  2. Tokes,

    I think game engines are more likely to benefit from unit testing. In fact I've read exactly the scenario you paint as happening to one game studio.

    I forget which one it was - maybe Epic or Id? - but they said that when they started licensing their engines they found they needed to maintain code way longer and unit testing etc. started to become really important. Not to mention documentation etc.

  3. This seems like an interesting collection of assumptions and I have no idea where most of them have come from.

    Try looking at http://altdevblogaday.org/ and I'm sure you'll find posts talking about each of your assumptions.

    Agile : http://altdevblogaday.org/2011/04/02/on-sprint-reviews/
    Unit Testing : http://altdevblogaday.org/2011/03/29/3-2-1-planned/

    As for the rest, well, let's just say that I bet *your* source code control systems and backups don't process 200Gb of source art as well as code, and continually integrate them all on every checkin. :)

    Gamedev studios do.

  4. Drew,

    You're almost agreeing that there are technical reasons for not doing CI there aren't you!

    Since you asked, my project has many dozens of CPU hours of work to do on each checkin, so we triage, parallelify etc. You don't have to do it on EVERY checkin. It's not religion, it's cost-benefit trade-off. And this stuff isn't impossible!

  5. I recommend doing some research into what AAA devs do regarding unit testing, sensible scheduling, crunch and the like. The people you quizzed on it have no idea at all and do not represent the companies who are good at game development, or even the average IMO.

  6. Chris,

    Quite the opposite - I'm just saying that our cost-benefit trade-offs sometimes have different costs and benefits to yours. Thinking you understand an entire industry well enough to make judgement calls on where that line is is presumptuous even if you're *in* that industry.

    What I am suggesting is that your post doesn't represent the industry I know at all.

  7. Insightful comment from ex EA employee on reddit:

    "I worked at EA for eight years. My running joke-that-was-not-a-joke was that we were twenty years behind the times, but I was probably exaggerating. Fifteen is a pretty good estimate."

    Read the rest at http://www.reddit.com/r/programming/comments/giq5c/are_game_developers_15_years_behind_the_rest_of_us/c1nuhri

  8. Drew I could tell you how I know about game developers engineering practices in general, but I'd have to kill you.

    I guess I'll have to take the hit and be called "presumptuous".

    I do acknowledge (again) that there are plenty of game developers who do not fit the stereotype.

  9. "You could tell me", or I could just assume it's because your project's marketing team laud their gamedev credentials. However as a start in rebuttals, let's look at Atlassian's JIRA survey taken before GDC 2010.


    You: "games developers ... will not ... adopt agile processes"
    The Survey Says: "well over half of the respondents using our tools for agile planning (62.8%)"

    You:"games developers ... will not ... use proper source code management systems [or] have proper backups"
    The Survey Says: 0% of respondents say they use no SCC. 70% use perforce.

    If you're really interested in "learning more about game development, especially on the tooling, process and architecture side." then I'd suggest you try groups like the IGDA Tools-SIG (http://wiki.igda.org/Tools_SIG) the various other professional industry bodies or blogs.

  10. Thanks for the pointer!

    The survey results report raw figures for the game industry. Even if we assume that they map onto usage of all tools or practices, which they don't, we're talking about the ratio of adoption in game to non-game industry projects.

    Anyway, I *am* really interested in learning about it and I apologise if I offended you.

    I especially love Atlassian's game developer customers and listen to them when they tell me about how tools and practices do not suit them.

    While I don't speak for Atlassian I'm very supportive of game developers' needs.

    While I've got you here - what can Atlassian's tools be doing better for you as a professional game developer? Do you use Continuous Integration?

  11. Tell the World of Warcraft team that they are doing it wrong. Somehow their money factory just isn't what it should be. I think you'll find that they are doing everything they should. In fact, you'll find they have not only implemented the practices you mentioned, but have pushed the envelope to improve it.

    Tell EA's Sims Studio, who have been printing their own money for a decade, that they are doing it wrong. Again, I think you'll find very solid practices for software development. Having worked with the code, I can state that we had a large battery of unit tests, a rather large collection of build servers with continuous builds, and all the other goodness you mentioned.

    Or perhaps EA's Madden group, with over twenty years of incredible profit, that they are being hindered by using such old and bothersome practices. You may be surprised to learn that your assumptions are false about the team as well.

    Yes it is true that many small games are made by hobbyist developers, basically teens in the basement, who don't understand the business of software development and don't follow best practices. IGDA, one of several major industry trade groups, have developed a lot of statistics on these people. Most are groups of individuals who hope to get rich without ever doing the basic steps of legally organizing a business or assigning their rights to a single entity. Not surprisingly, there are an enormous number of these which are started and most of these games fail commercially. They tend to horribly skew the statistics.

  12. Thanks Anonymous but I think you miss the point.

    I'm sure X Y and Z teams are "doing it right". If you want to call out names then I'll follow your lead. I would say those names you mention are more likely than most to be doing automated testing etc.

    However it's not me who is telling game developers they are doing it wrong. Have a look at munificent on the reddit thread I linked back to. He seems to actually know what the Madden team do.

    "Madden (at least as of a while back) is of course using revision control and backups. They have huge comprehensive bug tracking systems. They recently started doing code reviews (but for much of the time I was at EA, they didn't). Very little unit testing, some continuous integration." -munificent on reddit

    If he says they don't do unit testing I say why?

    I have been told by game developers why and I'm interested in the thinking behind it. I'm happy to be corrected as I wrote in the article.

    Perhaps you are right about skewed statistics by hobbyists. In fact I did mention this factor:

    "Another aspect to this is that a lot of self-professed game developers participating in online discussions about this stuff literally are kids in the bedroom!"

  13. I dunno. I didn't sample soo many game dev studios and I dunno anything or let's say very little about the world of web or database or other development.

    But from my experience, code reviews and continuous testing are a de facto standard in any serious gamedev studio nowadays.

    Also from what I hear, the average of non game dev shops is not that incredible wonder of unit tested well written code to say the least!

    I think this article is just the result of some personal experience with some mediocre studios.

    One fact that I can bring to the discussion is that AAA gamedev involves a lot of $$$, super strict ship dates (most of the times you just _can't slip_, most of the times...) and products that have to ship with close to no bugs (also because they have to pass third-party certification by sony and microsoft and so on). And (hopefully) they sell million copies to million of users/testers that will destroy your product if it crashes once...

    All that while still being fun and doing things at 30 frames per second on a toaster with 256mb of ram...

    So I'd suspect on average, they do things better than the average desktop app shop or so on.

    Now I know that there are shitty games and golden applications, and shitty game studios and golden application studios, but on average I'd say game devs know what they do.

  14. While I've got you here - what can Atlassian's tools be doing better for you as a professional game developer? Do you use Continuous Integration?

    For #1 - I don't know (I've never seen them in use in any of the studios I've worked at).
    For #2 - Yes. I'll drop you an email if you'd really like to talk about how and why game dev tool sets differ from more enterprise development. I've worked in both.

  15. I work in the gaming industry, on AAA games. I have to admit that your article makes me rage, badly. The amount of prejudice and unfactual statements baffle me.

    I used to work as a software consultant and I've worked with world leaders in software, telecom, packaging and machinebuilding. They were all much, much, worse at software engineering than any of the game studios I've seen. We use CI, source control (who doesn't!?), code reviews.

    We work normal hours. We like to test. I completely agree that a good regression test suite is a life-saver but that's not necessarily the same as needing unit tests. I personally don't like unit tests but I know people who do in the games industry. We have "industrial strength" bugtracking (JIRA as it so happens).

    And the indie developers (in the bedrooms as you somewhat condescendingly said) I know are at the forefront of advanced technologies and project management.

    Of course there are bad apples in the gaming industry as well, but with the pressure that's on a game studio there's simply no room NOT to use modern best practices. I'm fairly certain that for every studio with a badly managed software pipeline I can find 10 java "enterprise" devs that are much, much worse.

    You are being unfair, you are out of date, you are wrong. Sorry, that's the facts.

  16. Dude, how can you even be remotely serious about this?

  17. In college, yes, this is very much the case. There's more pressure to have some half assed program going than there is to reinvent the wheel before a deadline. Realistically, it is difficult to maintain industry standard (whatever that is) when we can pass on a half working project. There's no time for testing when we're trying to figure out an ill documented home brewed library.
    Of course this means we're coming out of college with a lot of bad habits. What's that gonna say about the future industry? Frankly, it worries me.

  18. Anders nothing condescending about coding from the bedroom. I just relate my own experiences being a teenage coder as just not knowing about unit testing (how could I?)

    Perhaps the stereotype is more rare than it seems from the outside. That's encouraging.

    I'm glad to hear of your experiences. What kind of Continuous Integration do you do?

  19. We try to avoid branching, update workspaces on a daily (if not more often) basis.

    One button does a complete build.

    Manual build, test and review before check-in.

    Automated build and test on check-in.

    Newly built executables are checked in as soon as they're done/pass by the build system.

    We work hard to keep build times down (custom tools to detect increased build times, find include chains, find things that could be forward declared, etc).

    Build/test results are published to a webpage.

    Game is always playable by just getting latest in Perforce and double-clicking the executable. (Automatically starts all servers, and things you need locally).

  20. We could move this discussion to reddit if that's more comfortable. :)

  21. Anders that sounds fairly civilised.

    Do you work on titles that expect long lived code bases like MMOGs or online hosted stuff like Zynga? Or on more traditionally distributed single delivery on physical media? Consoles or PCs or mobile?

    The game industry is cleary large and varied.

  22. stick to your java drone existence.

  23. This comment has been removed by the author.

  24. This comment has been removed by the author.

  25. I used to work in video games. Bugs were always a problem, but the problem was usually fixing them rather than finding them :)

    This didn't convince me personally that unit testing was worth the bother, but I would be interested to see a successful game (that was released on time) that was thoroughly unit tested, so I could see what they did.

  26. Wow... I think it is your view of the gaming industry that is 15 years behind. You fall for almost every stereotyped misconception about the gaming industry.

    Btw, the type of companies you described exist both IN and OUT of the gaming industry, it has nothing to do with the game industry.

  27. The games industry is a nasty, clueless place, but not for any of the guesses you've put together (and I might add, Atlassian's products are pretty damned questionable themselves - JIRA in particular needs ninety five extremely slow page loads to accomplish even the simplest of tasks, making it absolutely agonizing to use without a dedicated staff member to wrangle it into basic adequate performance on a regular basis.)

    The reason the games industry is so ugly is simple - they only really got stared in the mid-1980s, growing out of a garage hobby into one of the richest industries on earth.

    It's still run by those garage hobbyists. They have *no* idea what they're doing. Most game shops won't let you develop in C++ for current consoles because they imagine it's too heavy.

    You want to fix the game industry? You can't do it with process - these people will follow it like zombies, observe that it didn't really work, and drop it. Scrumm's had several failed assaults on the games industry, as has the Agile cult, both driven by ill-advised E3 promos.

    The long and short of it though is that the people at the top of the tree are doing just fine burning out college kids on 90 hour workweeks and shipping marginal garbage. Their current method is extremely risky; one large game gone south can sink a publisher.

    As a result, it is much too risky to experiment with doing it right - especially in the minds of men who've made billions of dollars doing it wrong, and cannot face (like Atlassian, natch) that they are in fact ten years behind the times.

  28. John, thanks for your detailed comment.

    I take your point about JIRA. If you haven't, try a recent version, I think you will agree the number of page loads necessary is dropping with each release, e.g. inline operations and pure keyboard navigation. But you are right to call us out on UX - we are behind the times in that, and for the past few years it has openly been a priority for us.

    As for the game industry - you add some interesting detail. I remember the performance arguments about C++ vs C in the 90s and C vs assembly in the 80s. Just like managed runtimes and GC in the past 10 years.

    As for process, it's just another kind of technology. It's only suitable for solving specific problems. Like any technology, if applied blindly by order of management it will fail to provide value. This is "process 101".

    Process must be applied by highly skilled practitioners in a gradual and sufficient manner. This means if your tech leads aren't on board then give up now. Tech leads need to be driving this, exploring methods for doing things better all the time. Of course the good ones do.

    Agile methods have cultists yes, and Agile is not universally applicable but it's sure as hell not new. It's almost as old as Java!

    And for the record I think automated testing is much more important than whatever else people mean by agile processes.

    I proposed that the game industry exhibits, in some camps, a disproportionate bias against this stuff and that the changes in the business provide an opportunity to make a fresh assessment of it. Many game companies are doing just this and I suspect they will find future competitive advantages in the rapidly changing games market.

    Analogously, the whole software industry is behind on, say functional programming. I think we need to step up and learn, adapt and where appropriate, adopt functional programming languages and methods. But I see that the game industry is doing this better than others already (e.g. SIMD). I don't think the game industry is behind on software or hardware technology in the slightest! But on process and tooling?

  29. Having been to the Automated Testing round table at GDC this year, I got this exact same reaction. I used to think it was only the places I worked that were behind on process, but I'm willing to say that it's the majority of AAA game developers.

    It's easy to think that "this is how it needs to be" when you're a part of that business. Leaving the traditional game industry to work at a company that "gets" agile development and testing was a huge eye-opener for me.

  30. You have made the most arrogant, back-wards article I've ever read. I doubt you what C++ even is. Mostly your just being a douche ass troll that knows nothing of one of the most evolved and toughest ares of programming. To work for a game studio you need to have be well developed in not only a high level language but also in lower level languages.

  31. I have to agree with what some already have managed to say so well. I don't think you get it, but you can get an idea if you get to know the right people.

    First, there are people who know the industry and there are those who don't. The people I'm talking about have been around awhile and are among the most respectful and insightful people I've had the opportunity to learn from or know of. These are the people that give great presentations at conferences such as GDC and help the industry move forward as a whole.

    With this in mind (and mind you, I'm not one of these people) I'd like to share some of the things that I've found to come into stark contrast with my existing beliefs as a more traditional software engineer.

    Game code is disposable, means to an end. You're not going to maintain that code for that long, the platform will change, the design will change. Having great people around that can write great code, is much more valuable to a game studio than having the right process or discipline. This does not mean that it does not exist, it's a different beast altogether but what would make sense in your run-in-the-mill company doesn't necessarily translate so well, if you have to ship your game on a specific date.

    Console development, specifically PS3 development is rather absurd from a performance perspective. The code that run well on a PS3 is very different from your general purpose software. These people know what the hardware is and they design a their work around that. You have to understand that the more you can get out of a console, the more you can spend on things that will make your game great, this will give you a competitive edge. This is also the reason why game code will shock some people, it was not written to be perfectly readable it was written that way because it got the job done and it was fast.

    My last point, is a bit harder for me to argue objectively about but game development grew from a culture that wasn't motivated by greed (simply making a game for the purpose of making money). These people wanted to make a game because it was part what they believed they should do. A lot of the traditional churn that plague software development does not exist when your reason for doing what you do is so well spoken. These people are self-motivated talented people and they get to do what they love while many of us don't. These people make rational decisions about what they need to do next to move forward, they don't waste a lot of time in meetings. If they did, they'd run out of business, because they need to ship the next game.

    If you want to know more about the process of game development I urge you to read some of the publications available from EA DICE or Insomniac Games (they talk about this stuff becuase it make a lot of sense in the context of what they do!) I can personally recommend #GDC12 Ron Pieket: Developing Imperfect Software: The Movie (http://www.insomniacgames.com/gdc12-ron-pieket-developing-imperfect-software-the-movie/)

    That said, game development is not traditional software development, if you think that, you will fail. As to whether they are ahead or not, I'm pretty sure they've been ahead the rest of us from the start. You just don't know where to look.

  32. Thanks for your thoughtful comment, John. I hear loud and clear that you believe I don't get it. You might be right. But reading your comment suggests that the only way I have available to reach an understanding is to talk to an expert who will explain it to me or become a game developer.

    Is this a fair representation of your argument?

    I'll keep my mind open to being wrong about this and make a note to take any opportunity to learn from expert game developers, which, incidently, I have certainly done in the past. John Carmack, Tim Sweeney, Jeff Minter, David Braben, Chris Sawyer, Notch, these are some names off the top of my head who I have had the pleasure of following over the years and learning something awesome and inspiring from them.

    As for the other elements of your argument, I think they fall fairly well into the "game development is a different category" form. This is often stated with great certainty but rarely any more detail and I can't help feeling this is a lost opportunity to learn something specific.

    Games on the PS3 certainly have distribution and licensing constraints that, say, internet distributed or online hosted games do not have. Mostly I think this is because of Sony's business choices rather than anything technical. I have stated quite plainly my predictions and emphasis that update streams will be increasingly common in game development projects and in 2013 this seems quite uncontroversial.

    Anyway, I'm not interested in pissing off game developers (or anyone) so I'm not likely to elongate this discussion any further, especially for points I think have been well covered in this blog post, in the comments, in my other posts and elsewhere on the internet.