Understanding the problem

Sam Hart

2009-09-02 21:42:27

Before we begin, let's take a look at the problems that many Indie game developers face when they want to work in a team.

No central office

When you're working in a large and well funded organization chances are you are working from an office (or cubicle) with other fellow employees. This means that potential team development problems can be easily avoided by simply getting up from your desk, walking down the hall, and talking to someone else on your team. About to work on a particularly hairy bit of code that could break the build or block your fellow teammates? No problem, go and tell them what you're about to do!

In an Indie team, however, chances are you don't have a central office where everyone can be found. If you're anything like most Indie teams, you're working in a distributed fashion- Each developer working at their desk in their home/apartment/condo/cardboard-box (hey, as long as you have wifi, right?), possibly in their underpants, potentially in different cities, states or even time zones. You probably don't hold regular office hours and may even have drastic work schedule differences between developers (maybe one is a night owl who works wonders after mid-night while another is an early bird who does more before noon than most people do all day).

These factors can lead to real problems when it comes to actually working together in a team.

Working in isolation

This leads to one of the biggest problems people new to distributed team development typically struggle with. It becomes very hard to effectively work in isolation. How do you handle code skewing (i.e., when two or more developers start wandering off working on different parts of the project) and merging the work of multiple code sources?

Tasks, issues, schedules, and general project management

The final problem is one of general project management. When a new issue or bug is found in the code, how do you handle it in this distributed team, and then how do you track progress on it? If something needs to get done in the code (a task), how do you keep track of not only who is working on it but how well they are proceeding on it?