In any event, the purpose of Ada Lovelace Day is to write a post celebrating the achievements of women (or a particular woman) in the technology industry and thus, I would like to call out Tess Ferrandez, ASP.NET escalation engineer extraordinaire.

But this post isn’t about Ferrandez’s achievements in the domain of ASP.NET, specifically. Instead, this is about commending her for her work in educating the development community about debugging in the .NET environment. Ferrandez has been at Microsoft for more than a decade, working with .NET technology since it was in alpha, and offering her knowledge to the community at large through blog posts, podcasts, interviews and by speaking at conferences. She often discusses techniques for diagnosing obscure bugs or memory issues, providing great insight into the tools used or the systems affected — and she’s always informative, easy to follow, and extremely helpful.

I, personally, can attribute the entirety of my understanding of WinDbg and SOS directly to her, as well as a good portion of my understanding of the .NET internals. I am certainly not the only developer to have benefited from her work. So I want to congratulate you, Tess Ferrandez, on what I feel is the greatest achievement of all: teaching others through your own wisdom and experience.

“While espousers of crunch often equate it with creative passion — a necessary duty, a sacrifice shouldered in the realization of a nascent gaming opus — I grow increasingly skeptical. Any project, enshrined in the pregnancy of its own importance, is able to distort the realities of its true value to the world, skew the definition of success for team members, and inflate the supposed creative caliber of team leadership. Not all games are game-changers.”

I think this is such a critical point because I have seen so many cases where a project develops this aura of misleading significance, this notion that slipping the release date will result in disaster and grievous consequence. Yeah. Right.

The release date is generally only of such dramatic importance to investors and major stakeholders, and as Prout says, reliance on crunch is actually a disservice to them as well: “Common practice or not, one cannot make good faith assurances to an investor regarding budget and date targets, if said assurances are dependent upon significant, but unknown, quantities of free labor.”

The full article, “A Closer Look At Crunch”, was published today on GamaSutra. It’s an excellent read, especially since it explores various ways to avoid the need to crunch by avoiding what Prout believes to be the fundamental root cause of the issue: premature production. While I’m not sure that I would agree that this is the cause, it can certainly be a contributing factor and the preventative techniques Prout outlines do have some merit regardless of their ability to eliminate crunch from the development cycle.

This kind of inquiry is something I am familiar with fielding; even within the industry itself, tools programming is often regarded as less than glamourous. Some — such as the fellow who asked me that question — seem to regard it as a lesser programming discipline. This is unfortunate, because there really isn’t any aspect of game programming that is less important than others, in general. Sure, certain studios may have no need for a server programming team, and some studios may not need much in the way of a tools programming team, either. But when you need one of those teams, you really do need them. The whole development machine has to work together, and if any one cog or widget goes missing, the whole thing breaks down.

But it is true that tools programming is rarely a position of high visibility. As Jeff Ward recently wrote in an excellent post over at the IGDA Toolsmiths SIG:

“…in my experience, when you talk to people both inside and outside the industry and say you’re a game programmer, the first thing they’ll ask is “So what did you do on the game?” expecting that you’ll be able to point to something specific. Gameplay programmers can say “I made that system work.” AI programmers can say “I made that person move.” Graphics programmers can say “I made that thing render and look good.” Tools programmers can really only point at the team and say “I made that work better.”"

But, Ward continues, “that’s the way we like it.” And he’s right. I smirk when people ask me if I’m “still doing tools,” because if I get my way, I will always be doing tools. Building tools is really all about helping people, and it turns out, I like doing that. I enjoy working with the other developers, trying to figure out why some program isn’t addressing their needs exactly, why some bug is manifesting its nasty little head, or what I can do to further optimize their workflow. I love the sense of satisfaction and accomplishment I get from succeeding at such an attempt.

There are other benefits, too: I get exposed to nearly every other developmental discipline in the studio, which gives me a pretty clear picture of where the project actually stands (and produces a feedback loop allowing me to better customize the tools I build). Additionally, I get to work with a wide range of technology, and have a lot more freedom to explore new ideas and conduct research. In short, I think that being a tools programmer is the best job I could ever land in this industry.

This instigated a series of replies, including my own. But since Twitter is a really poor medium for discussion (especially as the number of participants, and thus @replies, grows), Drew elected to expand his argument via a blog post, which he published earlier today.

As it turns out, Drew and I seem to agree on the critical issue, which is that the onus is on the individual developers to take responsibility for the quality of their own work life. Where we differ is our opinion of the IGDA and its role in that process.

The IGDA is not — and never has been — an agent of change within the industry. The organization is about communication: enabling networking between peers, or advocating on the industry’s behalf. But they’re not a regulatory organization: they have no authority to alter how a studio or publisher runs itself. While some would call this a failing of the organization, I feel instead that it is simply their ideal state. In this sense they are impotent, and impotent they should remain. I don’t really feel like the industry has reached a point where it needs a governing body.

That the Rockstar developers are beset with the trials of long, thankless hours is unfortunate, but they allowed themselves to put in that position. It’s naive to think that, as an individual game developer in a studio, you can hunker down and focus on your isolated area of responsibility, letting all the other goings-on in the company pass you by. When you do that, you become complicit in your own misfortunes: you become the faceless cog in the machine. We, all of us, need to take charge and be proactive. When schedules get changed, or features get piled on, when it starts to become apparent that something might be wrong, ask the hard questions. If you don’t think you can ship when the new release date is pinned down, say so, and say why.

Yes, it might be hard. It might be scary. You might feel that speaking up puts your job on the line, and maybe it does. If so, talk to your peers beforehand — a unified front is more effective than a single man or woman. It’s likely to be especially risky in today’s economy, but it is what needs to be done in order for this industry to outgrow these exploitations. You need to convince your bosses, who need to convince their bosses, who need to convince the VPs, who need to convince the publishers, and so on. It’s not the IGDA’s job, it’s yours. If we want to grow up, we can’t expect to run crying home to mother every time a bully says something hurtful about our pocket protectors. Which brings me back to the original topic, and where Drew and I disagree. He says:

“So unless you’re ready to start from scratch and form your own organization to simply create a more complex problem out there, or you really think we’re all better off acting as individuals (look how that’s turning out) I suggest you get involved with the IGDA by becoming a member. Do it simply to support all the other members actively working and using the monetary resources you provide to continue to improve standards and reach out to more areas of the industry with their advocacy. Or, if you support the idea of the IGDA but feel there are parts of it that need to change, roll up your sleeves and join a SIG or request the formation of your own to address a certain issue.”

Unlike Drew, I do believe that an individual acting alone (or in concert with peers, but not necessarily via a third-party organization) can catalyze change in game development. But I choose not to renew my long-lapsed membership because I do not believe in the IGDA as an aid to that end.

I don’t believe that the SIGs and chapter meetings bring about any more good than the individuals participating in them could do on their own. Having seen no evidence that the IGDA has ever successfully been engaged to mediate a debate, I’ve no faith they could do that effectively, either. Nor do I see anything going on in any given local chapter that couldn’t occur were that chapter their own, independent interest group. Indeed, each chapter is so unique they may as well be. True, we must recognize the IGDA for their work on standards for QoL, crediting, and such… but a standard is only as reliable when it is accepted widely enough — and from what I can tell, much of the IGDA’s standards are accepted by virtue of being common sense.

In the end, I simply see a dearth of evidence sustaining the notion that the IGDA can act as a force-multiplier for the individual actions and opinions of its constituents. That’s not something I want my time, my money or (most importantly) my name associated with.

These schools are pretty popular candidates for kids searching for colleges, and it’s easy to see why. Game development has an appeal to it that conventional software development just… doesn’t. This makes a program that professes to teach you how to be a professional game developer sound pretty darn attractive. Alas, electing to attend one of these schools isn’t always the best choice. Before we go much further, I want to point something out – both in the interests of full disclosure and for the purposes of establishing some credibility on the subject. I’m not speaking from an external perspective here. I started college as a computer science major at Drexel University and then, having discovered after a number of semesters that the school wasn’t to my liking, transferred to DigiPen. I’ve also worked with, interviewed, spoken with or otherwise interacted with students, graduates and employees of most of the game schools out there.

Game development is just an extension of software development – games are, after all, a specialized kind of software. It follows, then, that in order to excel at game development, you should also excel at software development in general. This is the crux of my biggest problem with game schools. They focus very heavily on the games-specific aspect of the process, often neglecting huge swaths of knowledge, techniques and best-practices from the traditional, fundamental grounding of software development; since the programs are often so specific and focused, you also lose a lot of general education course and course options that can help shape you in a well-rounded individual with a strong ability for problem solving and for thinking on your feet. It’s an education focused on the goal, not on the journey. This is a shame, because the journey is where the real experience is.

Attending a game school can thus leave you with pretty big gaps in your education and skill set relative to your peers with their traditional computer science or engineering degrees. This might even cost you a job somewhere. It follows, then, that you’ll want to get a firm grounding in both the tradional techniques of computer science that form the basis of your craft, and of the particular application of those techniques in the domain of games. With that in mind, consider which of those two bodies of knowledge you’ll likely have more interest in studying on your own. Nine out of ten people will tell me that learning how to make games on their own a more attractive option. Those people will also usually agree that it’s much easier to discipline yourself to write games in your off-hours than it is to learn what order notation or lambda calculus is really all about. The logical conclusion then, is that these people should probably be considering a traditional computer science (or similar) degree, and should study game development as a hobby. Besides, it’s pretty hard to effectively apply the craft to making games if you’re still learning what exactly the craft is all about.

This brings me to another issue – occasionally, people want to go to a game school because they think they’ll be able avoid all those scary computer science topics. I find myself wondering what these sorts of people think game development is really like. Did they really buy those commercials about tightening up the graphics on level three? Game development is software development, my friends. You can close your eyes, stick your fingers in your ears and shout all you like, but that isn’t going to change reality. If you’re a poor software developer – and you probably will be, if you don’t learn what all the other software developers learn – you’re going to be a poor game developer. You can’t be in it just because you love the industry. You need to love the industry, of course – if you are unfortunate enough to work on a project with serious crunch time, you really need to love the industry. But you have to want to be a part of what the industry really is, and to do that you have to know what the industry really is.

Now, some people will be capable of bridging the gaps left by a game school, but not everybody. It takes some considerable discipline to force yourself to study a subject you don’t have to study; one that you might not even think is useful. Sometimes the danger is in the very fact that, since you’re essentially teaching yourself, you don’t even know what you don’t know or what you should be looking in to. I do think that game schools are right for some people – I’ll touch on what I felt were some of the positive aspects of my DigiPen education below – but I think the majority of people should be practicing game development as a hobby while they complete a good, traditional educational program. There’s another benefit to be had from that choice, as well: remember how I said that most game schools are so narrowly focused that they leave little room for elective coursework outside the scope of games? Cross-curricular courses make you a well-rounded person, and thus more attractive to a lot of employers – when you have a varied background, you add diversity to the skill pool of the studio, and you’re more interesting to interact with, professionally and around the water cooler. If you’re one-dimensional, if you’re one of those foaming-at-the-mouth-oh-my-God-I-live-and-breathe-games types, nobody’s going to hire you. You’re creepy, get a life.

While working on this article, Ravuya raised an excellent point that I want to share. The original context was an IM conversation, so I’ve taken the liberty of removing my useless interjections and paraphrasing somewhat. I’m fairly sure he won’t sue me:

“It’s more like an education driven by the love of the industry, not even the goal. The students are in love with the cultural artifacts of the industry (Nintendo, et cetera) and want to emulate it, not improve it. The schools’ practices are outmoded, but they refuse to adjust or augment them out of fear of losing the ‘magic’ that they’re emulating, since they’re so in love with the industry itself, and not their sanity, development talent or free time. They almost slavishly refuse to go a ‘different way’ unless forced to do so by the industry. The problem with vocational schools in general is that they hire so many people with industry experience they have no appreciation for what other industries can teach.”

He managed to articulate a concept that I was having trouble figuring out how to put into words myself; I’m especially fond of the last point. The practice of having former or current professionals teach is usually regarded as a plus, something with a positive impact — but we don’t often consider the negative impact that recirculation of knowledge can have, as well. Many game schools are overly concerned with producing graduates that will maintain the status quo — although this the case everywhere, as Ravuya continues, “in a lot of ways, computer science education is the same way — it can’t change academia because it’s focused on being academia, so a lot of massive failures stay in academia to screw up the next generation of students.” Sure, there’s the lecture on quality of life and crunch time now and again, but this isn’t really drilling to the heart of matter. Most such schools have students band together in teams and build games over a lengthy period of time (usually a semester or a year). These projects usual suffer from the same failures in estimation, planning, and infastructure that larger, real-world projects will suffer from, and yet the reward (the grade) is still based on the finished project, and not the road the team took to get there. It’s a great little microcosm of the industry, but it’s not helping anybody become better software developers.

On balance, though, game schools aren’t all bad. My goal here isn’t to give you the impression that game schools are worthless scams (although some of them are; you can usually tell because they have TV spots). My goal here is to make sure you understand what you’re getting into. It’s shocking how many people show up at DigiPen on the first day of classes, only to fail out within a year or so. It’s not because DigiPen’s curriculum is particularly difficult – it’s no more or less work than most. No, they fail because they didn’t know what they were doing. They were so enamored with the idea of making games that they couldn’t, or didn’t even try, to see DigiPen’s program for what it was: a four year computer science degree that’s very light on the computer science and very heavy on the practical application of programming and math as it relates to games. Most of those drop-outs thought they’d be studying to be game designers, sitting around all day discussing how to balance their dream MMORPG or designing levels for Counter-Strike: Source, or something. Don’t make the same mistake.

But I promised I’d leave you with some positive points regarding my experiences at DigiPen, so here they are, in closing.

DigiPen, at least, has a really good computer graphics program. If you’re interested in graphics, this is a definite plus, as most other schools don’t provide very many computer graphics options to undergraduates. DigiPen has courses dedicated to the fundamentals of modern graphics programming theory (as in, what goes on beneath the sheets that DirectX or OpenGL give you). They also have a number of upper-levels electives in the area, some stuff that other schools only offer as part of their MSc or PhD programs.

At game schools, you do tend to get experience on projects of non-trivial size. Now, you want to be careful of the Doghouse Analogy here: you’re not building large projects, in fact you’re probably only barely approaching the size and scope of some small casual game projects. Nonetheless, the projects are usually much larger, and longer, than those you’d be doing at a traditional school, and you also get some good experience working with teams. That alone can go a long way, because so many people getting into computer science or game development don’t have the greatest social and communications skills.

Finally — perhaps, most importantly — you get a nice, ready-baked collection of industry contacts when you graduate. Game schools have more networking opportunities than traditional schools, in terms of meeting people in the industry itself. Plus, you’ve got all your friends and former teammates who will graduate with you. They’ll get jobs at various studios, and you’ll have a nice network all set up. It’s a big head-start over what somebody graduating from a traditional school might have.

But you’ll notice that none of those points have to much do with being a good software developer, or even (with exception of the graphics programming) with the quality of the education, and for the most part they’re all achievable anywhere you go to school, as long as you have the motivation.