Software Development Functions for the Non-Techie Grog

[FarAway Sooner]

We spend a lot of time on here talking about specific computer games, what they do well, what they do poorly, etc.  We voice lots of opinions on how certain games are great, and on how certain games suck.  But we don't spend much time talking about why certain games suck.

What follows is hopefully a concise and readily accessible explanation of how software development works, so even the non-techie layperson can figure out, if a game sucks, perhaps why it sucks.  This is written by a non-techie for other non-techies, and I'm intentionally simplifying some stuff.  So folks with PMI certification in software development, please don't yell at me!   :D

In the beginning, there were business requirements.  These represent a plain English explanation of exactly what a game is supposed to do.  At a high level, it includes things like how movement or combat work, what statistics affect what outcomes, how units improve their stats and whether they should emit big explosions or screams of agony when they die.  At a more precise level, they include thinking up how the interface will handle situations like "What happens if somebody spends 50 Gold to hurry up production on a Spearman and then decides he only wants to build a Militiaman this turn?" or "What happens if my hero kills the enemy hero to end the battle but is then slain by damage from his dying opponent's Fire Shield ability?" 

Computers do exactly what you tell them to do, but not much else.  Some games suck because the game mechanics themselves just aren't very engaging.  That's a business requirements problem.

After business requirements comes the technical requirements.  This is where people who understand how all the pieces fit together try to provide very detailed instructions to the software developers around exactly how to go about making stuff happen.  Tech requirements don't tell developers exactly what code to write, they just tell them what databases to drill against for different values, what sort of math to use as they're running their calculations, etc.

After tech requirements comes development.  This is where people actually write code to make stuff happen as outlined in the requirements.  In smaller companies (and that includes most game outfits), there's often a lot of overlap between the people writing the requirements and the people writing the code.  The line between business requirements and technical requirements is often blurred or eliminated altogether.  This can simplify things, because too much documentation can kill anybody. 

BUT, if you're relying on all of your developers to also have a great understanding of exactly how all the aspects of the game and the game play experience are supposed to fit together, you're relying on finding some dynamite programmers.  It's a bit like requiring that all your officers also be excellent marksman.

The developers then sling the code.  They write the game in such a way that it runs quickly and without crashing to desktop.  They should also write it in such a way that somebody else can come in, understand what their code is doing, and make changes to it later on if needed.  When they see instances where requirements are vague or perhaps somebody didn't anticipate one way a user might try to do something, they can ask a requirements expert or they can just come up with their own solution, depending on how skillful they are.

The testing function is the unwanted bastard stepchild of the software development function.  They spend time pounding on the software build, trying to break it however they can.  They test different systems to determine hardware functionality.  They try to dream up wild use cases where users do things in a sequence nobody's ever imagined (e.g., "What happens if they hit the ESC key at just the wrong moment?").  They go back and try to make sure that newly released functionality doesn't screw up old functionality.

The project management function is what tries to tie it all together.  They balance trade-offs between what the folks on the requirements side want to do and what the other folks actually can do.  They keep Development from wanting to keep adding glorious new code and functionality because the Testers need to get busy actually seeing if the code will run.  They also go back to senior management and highlight budget risks (e.g., "We need more money") or timeline risks (e.g., "We need to delay the launch of this game 2 months") so Senior Management can decide what to do (e.g., "Give the testers less time.  We'll let our early buyers beta-test it for us.")

Senior Management are the folks who overrule all the other functions when people can't agree.  They're also the ones who scare up money to pay all the other people, make high-level decisions about what's in-scope and out-of-scope, handle PR, etc.  It's their job to work with Project Management to make sure that the other functions are playing nicely together.

What does all this mean?  Below are a few simple rules to live by as you evaluate different software shops:

• When games are released buggy, that might mean that testing is at fault.  More likely, it means testing wasn't given enough time by the project managers or senior management.  Testers are the bastard stepchildren of software development.  They're treated a bit like Russian infantry were in 1943.
• When game release dates are pushed back at the last moment, that's usually a breakdown in project management.  Good Project Managers know exactly what needs to be done when and they know where people are at on most big tasks.  If people are missing deadlines here, they need to adjust their timelines.
• When game mechanics just aren't very engaging or are too simple, that might mean the business requirements suck.  Or it might mean that all these great design ideas had to be left out because one of the other functions couldn't hold up their end of the bargain.

[li]At the end of the day, Senior Management gets a big share of the blame for anything that goes wrong.  If any one function tied to a software development cycle sucks, Senior Management should have figured that out and moved in to fix the problem.  Of course, at the end of the day, Senior Management usually gets a bigger share of the money whether games go right or wrong.
[/li][/list]

I've intentionally left out how graphics development fits into this overall structure, because that's not something I know about and because it's different.  If anybody has comments to add or wants to insert a blurb around graphics development, I'd love to hear it.

Does that all make sense?  Is anybody still reading?

[crickets begin to chirp]    ;D

[Jack Nastyface]

For most of my technical life, I was an infrastructure guy, so the OSI model for data was always a more relevant template.  Just to review, from layer 1:

Physical
Data-link
Network
Transport
Session
Presentation
Application

Unfortunately, the OSI model neglects the three most important layer necessary for successful IT project delivery

Business - includes cost overruns, timelines, and refusal to regard IT as anything except a cost centre
Political - includes vendor choices made due to personal relationships, etc; also includes CIO making decisions because he thinks he's right
Religious - Acts of G-d that negatively impact the project timelines, and prayers to G-d that may positively impact the timeline.