Six Lessons from the "Mainstream" Software IndustryClay Dreslough and Sports Mogul
On the whole, the games industry has always lagged behind the rest of the software development world in terms of "mature development processes." Government and corporate software customers often require information about a developer's level of maturity, such as CMMI (Capability Maturity Model Integration) certification.
Some of this difference is useful, as it allows for more creativity and market flexibility in game development. And we shouldn't kid ourselves. Most software development that occurs outside the game industry has its own problems with time and budget overruns. Nevertheless, there are some lessons we can learn from the vast body of research into conventional software development:
1. Switch from Wishful Thinking to Project Planning
Research has shown that programmers are actually pretty good at estimating programming tasks. It's when they try to massage their estimates to fit a schedule (or just a culture of "aggressive scheduling") that they get themselves and the entire project into trouble.
Ask your programmers to deliver realistic estimates and cut features that don't fit. Most of us are in this industry because we love the work. This means you can get better overall productivity by having a realistic schedule and adding features as time becomes available (instead of having an "aggressive schedule" and being behind for the entire development cycle).
2. Use an Iterative Development Process
There are too many development methodologies to go into here: Spiral; Waterfall; Incremental; Prototyping; Staged Delivery; Extreme Programming. They generallybreak into two types: linear and iterative. Linear methods plan out the entire project at the start and then chug along. The game doesn't "come together" in any meaningful way until very near the end.
Iterative methods focus on getting some version of the software working very early in development, then evaluating the project and its risks before revising the plan and diving back into engineering.
This has two main advantages relevant to games. The first is increased visibility. Any great game requires some degree of innovation. This means the designers, producers, marketers and managers need to see a working version of the game as soon as possible in order to fully understand it. No matter how detailed your design document, QA can always write more useful test cases from a working game.
The second is flexibility and quality. Iterating lets you decide if parts of the game don't feel right and need to be reworked. You can shift resources in the middle instead of trying to rework everything at the end.
Iterative models also work to counteract the natural tendency for schedule overruns. If you can't get some form of your game working in the first half of your schedule, you probably aren't going to hit your date.
3. Purge Problem Programmers
It is well documented that productivity differences of at least 10-to-1 exist between the best programmers and the worst programmers on small projects. On larger projects, some programmers actually have a negative impact on the project.
"Problem Programmers" aren't difficult to identify. If you have one or more on your team, the other programmers almost certainly know who they are:
a) Problem Programmers care more about looking smart than learning from other programmers. They hide their weaknesses by refusing to document their code or explain their processes.
b) Problem Programmers are territorial, often exclusively checking out code for long periods of time—slowing down the progress of other programmers.
c) Problem Programmers complain about management choices, after the fact. Unwilling to share the blame for development issues, they would rather revisit issues that have already been resolved.
You might worry about falling behind if you eliminate a programmer. But bad programming practices are almost always caused by bad attitude, not low intelligence. If you can't change the attitude, you need to help out the other team members by removing the problem. I've never met someone who regretted removing someone from a team; but I've seen several situations where someone who wasn't removed should have been.
Before you add programmers to a project, see if you can improve productivity by removing one. Your technical leads should already know if this is an area that needs addressing; they just aren't always willing to raise the issue.
4. Code Belongs to the Project
If I had a nickel for every time I heard a programmer say "don't touch my code"...
The game industry is filled with programmers that talk about "my code." It also has a high turnover rate. This is a bad combination. For this simple reason you need to make sure that at least two programmers understand each section of code. There are different ways to accomplish this, from code reviews to "team programming." Regardless of the exact method, you will also find bugs early (when they are less costly to fix) because the simple act of explaining or commenting code can find bugs before the code is even checked in.
The majority of programming effort is spent fixing bugs, not writing code. Most programmers know this—they just need a team environment that encourages good practices such as pseudo-code and naming conventions.
If you are working with code that is hard to decipher (even if you didn't write it) document the section so that the next programmer knows what's going on. It's helpful to include your initials and a date. For example, if you commented someone else's code incorrectly, the original programmer can discuss it with you and clear up any misunderstandings.
5. There are no Silver Bullets
A consultant once recommended to me that we convert our entire code base from C to C++ simply because "C++ is a better platform." The extent to which a tool will help your project is correlated with how well it is already customized to fit your needs. A new programming language won't help you solve the problems specific to your game title.
This is true for art tools, source control, and the like. I've heard the claim that switching from Visual Source Safe to Perforce would cut development time by 20%. Make sure you investigate all tools internally before committing your entire project to the newest "silver bullet."
No development tool can replace good development practices. Instead of forcing your team to learn new tools, help them learn better practices.
6. Catch Bugs Early
Have the bug database up and running from the start (don't wait until Beta). This lets everyone on the team formally contribute bug reports and suggestions. It also gives you the entire product cycle to develop the best system for categorizing and reporting bugs. If QA and development have been working together for over a year, they won't get into a fight in the final weeks about what really constitutes an "A" bug.
The corollary to this is that QA, the people you entrust to "assure" the quality of your software, should be empowered to do that. Clustering your least-experienced employees in another building and asking them to "play the game" isn't going to work on the next generation of games.
Final Words: This article glosses over a lot, from project planning to programming to personnel. Googling key phrases from this article is a good place to start looking for more information.