I wanted to share another great question I received in response to my latest Gamasutra blog on “Developing To Deadlines” last week. This question picked up on the inspiration we’d taken from the magazine publishing business for our development process.
Question:
“‘I’d really like to know more about this approach, you’ve convinced me that philosophy/background is very sound, but I have no idea how to actually apply it to our development process.. 
The main issue I have is that magazines are purely content-driven while games have an element of technology/engineering. All you need to complete a magazine is to write (and do layout, etc), which is a known, well-understood process for an established format.
If your games are purely about executing an already established design, then I can see how you could make this work in a magazine-type way. However, for a non-trivial game design, it’s not clear how to make things work.
For instance, let’s say you’re crazy and you decide to make a game based around the simulation of dynamic locomoting robots. Making characters move and balance in a physics-based world is an active research area in compsci/robotics, so even though we can cheat a bit in gamedev, we still have some hard problems to solve with no known existing solutions. This means that, while we can establish a plan of “try (a), try (b), fallback to (c) if all else fails” it’s very hard to determine exactly how long this plan will take to find a working solution, or whether such a solution even exists!
This is the part I find hard to reconcile with magazines.. magazines aren’t involved in R&D type work, they’re just churning out content. But I would _love_ to be proven wrong since it would make scheduling a lot easier around here ”
Answer:
“You raise some very astute points here and, again, the answer could fill a blog of its own. However, what I’d say at this point are two things:
a) Denki’s development process places significant emphasis on working with established repertoire. In other words we try not to put games in to production unless the parts we don’t know how to do have already been figured out previously during non-project critical R&D phases. That process we equate to actors learning parts – no one would risk putting a Broadway show together that called for the lead actor to perform acrobatics unless the actor chosen already had acrobatics as part of their repertoire, or had proven their ability to learn acrobatics.
In your specific example about dynamic locomoting robots, I would never expect Denki to work on a project that required to solve this problem unless we’d already created a prototype that gave everyone involved in delivering it the confidence we could achieve it within the tight constraints of a commercial development process. I do appreciate however, that there are many games companies around who wouldn’t think twice about promising to deliver dynamic locomoting robots as part of their next project if it meant it would get it signed; but that’s a whole different issue…
And b) the magazine industry seems very established and certain to our 21st century eyes, but it hasn’t always been so. Type “history of magazine publishing” in to a search engine and you’ll soon discover that what seems a “well-understood process for an established format” was once a dark art of its own – and not all that long ago either. Just this week a colleague told me they’re planning to introduce some sort of video advertisements in to newspapers, and I can just imagine the looks of horror on the print manager’s face as they try to figure out how they can deliver that to schedule!
Magazine production is undeniably simpler, with less variables than the game development process, but from my perspective that just makes it an even better model to take inspiration from. It’s easier to understand the implications of getting any part of it wrong and see what the impact of solutions may be, but I appreciate the parallels aren’t always directly analogous. Great question though – you’ve highlighted that this would be a good topic to explore further in a future blog.”
I find it really inspiring to receive this kind of feedback, as it all helps to refine “The Denki Difference” that little bit more. So please keep it coming!
Colin.
—
This is a friendly rebuttal to the assertions made in this article by Colin from Denki. In it, he argues that within software engineering (specifically games development) it is possible to adhere to tight, immovable deadlines and still produce high quality results. I intend to demonstrate that this metaphor does not work, that this trivialises the discipline of software engineering, and that in fact there are better ways of perceiving time constraints in a development environment.
For a start, let’s address the poor choice of metaphor represented here. If the intention was to find a comparable vocation to software engineering, then surely choosing another engineering discipline is more appropriate than choosing journalism? The two have (quite literally!) nothing in common. When was the last time a magazine crashed or was rendered unreadable by people of a certain specification? When was the last time a magazine was required to be anything but letters and pictures printed onto dead trees?
I do agree with Colin that in an ideal world, we would never be presented with situations mid-development which we did not already know how to handle, but that is simply not the case in practice. I’m not saying that Colin is exaggerating at all, but figuring out how to deal with new situations and problems is in fact the very essence of engineering and none more so than in software engineering where the very landscape we develop in can vary to the extreme on a year to year basis. Magazines, on the other hand, have retained the same functionality since their inception.
Many poor articles do, in fact, make it into magazines and newspapers every day, but we do not live in a culture where the end user of a magazine would demand their money back on a magazine that has been poorly written. There are no “reviews” of magazines, and whilst a consistently low quality magazine will find its readership dissipating over time, one poorly written article isn’t going to bring the whole thing crashing down.
And then there’s the nature of magazine articles themselves. I know very little about journalism myself, but I would imagine that a first workable draft is written first, and then this is reviewed and edited as appropriate. If the deadline is reached, and the article is maybe not quite as good as the author would like it to be, it can still make it into the final edit “as is”. Readers will still be able to use it, although some may not think very much of it.
Software on the other hand, if not complete by time of release, can be rendered completely unusable. It’s the journalistic equivalent of somebody opening a magazine only to find that, half way through the article, the story consists of only random letters and numbers.
This “immovable deadlines” problem doesn’t just extend to the games industry – it applies to software engineering as a whole and I think that’s partly to do with how young the discipline is. If we were to compare software engineering to another engineering discipline (say, bridge building) then suddenly you’d find that the planners and managers would take what their engineers were saying *very* seriously, and the notion of releasing a low quality bridge is not one that is likely to be taken lightly.
But again, this is a poor metaphor. People don’t die if they play a poorly developed game! Perhaps the youth of the discipline means that it doesn’t *have* a comparable other vocation. Perhaps over time the people who DO the engineering and the people who USE it will build up a rappor in the same way that architects and builders have, who knows.
In my experience, the law of managing software projects has been as follows. There are three aspects: Speed, Quality and Completeness. Now, two of these, you can have for free, and whichever you don’t choose MUST be managed. For example, a firm who wanted Speedy, Quality software projects would need to manage “Completeness”, which would likely be done through patches and/or extensions. A firm requiring Complete, speedy projects would have to manage quality (likely to be achieved through hiring more staff to refractor code, and only hiring top quality developers who adhere to standards at all times). In this instance, where the company requires quality, complete software, it is time that needs to be managed and unfortunately this means no tight deadlines can possibly work.
Anyway, hopefully this provides a decent counter-argument. Ciao all!
@Mike – Wow: I wish all my critics were so well considered in their opinions!
You’ve certainly provided some food for thought there. Let me consider it for a bit and I’ll address it in a future blog post, because this deserves much more of a response than a simple “I agree” or “I don’t agree”.
My initial thoughts are that it comes back to this notion of repertoire, and de-risking technical issues ahead of entering production, but I’ll need to check that’s true for each of the specific examples you provide.
This is exactly the sort of counter-argument that helps us improve, so thanks for taking the time to articulate it so clearly. Much appreciated!
Cheers,
Colin.
—
@mike You definately make a good point about hardware constantly changing. It’s hard to build re-useable repertoire when they keep changing the goal posts every 5 years. It happens much more gradually in other industrys, whereas we repeatedly get a complete overhall in a one-er.
@stew I wouldn’t be in this industry if it didn’t keep changing mate – keeps it fresh and interesting
@Colin Hey man, no need for a response or anything, I’m just glad the comments were taken in the spirit they were intended.