I came from traditional software development, and the first dev company I worked for made all the classic mistakes of no process, projects finishing only based on individual heroics, finishing late and of poor quality.
There had to be a better way.
The company hired a process consultant. This fella came from a software development house that had a reputation for always delivering on time and on budget. We were dubious at first, but our software system was already two years late and 200% over budget.
Like a lot of software companies, our culture wasn’t ready to embrace the changes he proposed whole-heartedly. As a result, a mish-mash of processes were used that somewhat improved things, but not a lot.
Frustrated, I left that company to join another development firm at the opposite end of the spectrum: it was being crippled by process. They had process for no other reason than for the sake of process. Everyone, and I mean everyone, hated the process owner, a PMP who smugly wielded more power than the executive management team to decide whether or not a project was green-lit. Ultimately, this company’s software was late, over-budget and buggy, but the process was followed rigorously.
Eventually I hired on with a management consultancy, where I learned all about, and started teaching about, requirements (i.e. design), estimation, and risk assessment.
Always having loved games, I jumped at the first opportunity to work in a game studio. I was in heaven, with the exception that process definition was where the software development industry was 30 years ago. Heroics, long hours, and missed deadlines. I started asking the questions about process, at every studio I worked at. And every time I heard a similar response:
“Ve make gaaaames, darlink, not softvare. Now vhere did my unicorn go? I have a brunch meeting at ze Lucas ranch. Zey looove me in San Rafael, you know.”
Um, that console disc contains…oh, never mind.
So here I am making games. And guess what? Many traditional software developers sneer at game developers because games can’t be taken seriously. I know this, as my co-workers and I used to be the sneering ones before I joined the games industry. I’ve since learned better. The irony is that game development is significantly more difficult to do than traditional software development.
Why? Well, you can check all the functional boxes off from your design, but that doesn’t cover “fun”. Nor does it account for emergent gameplay mechanics that come about due to an AI-based system.
But I was equally perplexed by the closed minds in the game industry when it came to implementing process, with the excuse that this is a creative industry and therefore process has no place. This is known as faulty logic. Dusting off your first year university logic textbook, the argument goes like this:
“We have to continue without process in order to be creative, or we will fall prey to our competitor.”
This is known as the Either/Or Fallacy, or False Dilemma, where the speaker implies that only one of two choices exist. It’s only one example of faulty logic that I’ve heard over the years to justify lack of process.
I’m not an advocate of process for process’ sake; I think that’s as crazy-making as no process at all.
What do you think? What’s the right balance of process to keep a game project moving in the right direction? How do you wrap the fun-factor into a documented dev process? I’d love to hear from you.
IMG Consulting 