It depends which company you work at, obviously.

e.g. At the games studio I'm currently working for, whenever I check-in code, it's compiled and tested by a remote machine before being pushed to the trunk (meaning I can't break the build). At a previous games studio, any commits to certain libraries were automatically added to a task-tracking system flagging the need for them to be reviewed. I've never had those luxuries in corporate software jobs.

I've worked at a top 50 corporation (not games) that was far worse -- Emailing ZIPs for version control and still laughing at OOP as some academic ivory tower concept... So I've got an equally bad stereotype of PHB's and corporate code-monkeys and "architects".

The blog post is a bit silly, in that it's pondering why a stereotype doesn't hold up under analysis.

I wouldn't say that gamedevs are 15 years behind, but 10 might be more accurate if for no other reason than the unholy obsession with C++. Combine that with the relative immaturity of middleware tools and qa processes (development processes have actually improved a bit here)...

Anecdotal evidence and lore from the internet do not reliable data sets make.


This entire article is built upon a very flimsy straw-man image of game developers, which in my experience simply holds no water. Every successful studio I know about (in the sense of being privy to their development practices and habits, not just "oh hey I played their game once") is far more advanced in terms of engineering process than you make them out to be. Now, I don't mean that to be an attack on you or your article; I just mean that you're basing your opinions on faulty data, and therefore the resulting critiques are basically misguided at best.

Highly reactive, prototype-based, iteration-driven development models have been central to most mainstream game development for at least 15 years. We were doing "agile" many years before The Manifesto. We left behind waterfall almost as soon as the ink dried on the ill-fated paper that accidentally made it popular. (Well, to be accurate, game development never really did embrace waterfall or similar BDUF methodologies very seriously; it went from hack-it-until-it-works in the early days to a more iterative system in the '90s. A few places have tried BDUF over the years but I'd be surprised if any of them survived very long, at least not without changing things up pretty drastically after the first expensive failure.)

In terms of methodology, games are probably actually one of the best sectors of software to be in. They're demanding as all hell in many ways, and that forces us to be up to par on how we get things done.


Now, if there's one area where game development might lag, it's in tools adoption - or, rather, was several years ago. Centralized task coordination and tracking software, centralized documentation systems/wikis/etc., and so on have different degrees of buy-in in different corners of the industry. However, while this was spotty when I first did investigations into the matter about 8 years ago, I've been refreshing my own personal data lately and it turns out that this has all but disappeared as an issue in game development. Ironically enough, basically every studio I know of (again in the sense of knowing how they do business, not just passing familiarity with a name) is using... JIRA. Many of them also use Confluence. I find it rather humorous that someone at Atlassian of all places is questioning the practices of some of their most loyal customers


However, that only applies to process-related "meta" tools. Game development has had better end-to-end in-house tool pipelines than most commercial software for decades. For instance, at my current workplace, we're shuffling literally several terabytes of assets and code around, all in automated tool chains, and spanning over a dozen different software packages, libraries, and custom "glue" apps. We have this down to a finely tuned science, not because of some idealistic notion of process, but because we have to. We can't do our jobs without it.

I think about trying to introduce that level of complexity and sophistication to the more traditional IT-type shops or shrinkwrap application shops I've been at, and all I can do is laugh. Their poor heads would explode Now granted, my personal experience doesn't span some of the larger-scale apps out there, but still; what we had was a far, far cry from what game studios have done for ages.


I had to pull some serious teeth to convince one former employer to even introduce bug tracking software and incremental software releases. We sold a shrinkwrap application that you've probably heard of (well, if you have kids anyways). In the end I wrote our own custom bug tracker in my spare time because they refused to spend money - even a trivial amount - on buying an existing package. When I left, there was still substantial resistance to the very notion of tracking our bugs, and several years later I have it on good authority from inside sources that they virtually stopped doing any kind of formal defect tracking or update planning. They begrudgingly started doing it again as part of contractual obligations to the company that bought them out when they started to flounder.

There were speed bumps getting my current (game industry) employer to adopt some more modern practices and tools as well, to be fair; but nothing like that other company. And once we had things in place and running smoothly, nobody has looked back. For a while we had a staff member whose entire responsibility was to manage the defect and task database, and monitor our automated regression testing systems. I've never talked to a non-games software shop that even knew what regression testing was, let alone practiced it.


I can now name, off the top of my head, probably half a dozen companies who have better pipelines, better processes, and smoother adoption of best practices than my current employer (which isn't to say my current employer is bad at any of that stuff). All of them are games studios.



Now... in the interests of fairness, I'm countering your anecdotal ideas with more anecdotal ideas of my own, so I'm not trying to claim that I have the empirical standard of all evidence on my side I just wanted to provide a counterexample to some of your assumptions and illustrate that the stereotypical cowboy-coder image of game developers is, frankly, totally unfounded.


Maybe in 1983.


Not today.

I really don't get it what does it mean "to be 15 years behind". I always thought that being up to date was related more than anything to releasing stuff for the most modern hardware.

@chromofo, what do you think it means?

For any absurd set of thinking, you can probably find a non-zero percentage of the population who is utterly convinced of its truth. (There's a really nasty, below-the-belt comment about religion hidden in here someplace )


Why do some developers think that clear-win best-practices are not applicable to games? I dunno. Maybe you should ask them... to me it seems like an exercise in rationalizing someone else's delusions. Fun for psychiatry majors, but not my personal favorite hobby