Working Online
Author
I'm sure most of the people who browse these boards either work alone or online with other like-minded game developers. Unfortunately, working alone will only get you so far and, from my own experiences and reading about others', working with people online is hard! You can't gather around a whiteboard to discuss architecture, you can't pop in the office next door to ask a question, often your fellow developers aren't even in the same timezone, you might not have the kind of control over your build server you would in your own office, you probably have a few language barriers between your members, your team is probably working for free...
All of the problems of creating large systems are multiplied several times over, and some new ones are added to the mix. This has consequences in other areas, like content development and gameplay design, but the software side of things takes the biggest hit.
I'm going to be rejoining a team that I was on hiatus from, so I opened this thread to ask the question: What do you do to help get past the problems inherent in an online development team? Tools, practices, plans... anything that could help other teams overcome the difficulties of working online. Even if it's something that worked only in your specific situation, just putting it out there could help another team a whole lot.
To start things out, I think the #1 thing is: Make sure you have team members that can handle the increased responsibility. A lot of the practices your team agrees on will require every member to pitch in to have them work -- tested check-ins, consistent code style, discussion-before-implementation, etc. -- and having one "I do things my own way" programmer on the team can do a lot of damage. This rule might apply to teams of all sorts, but in an environment where you can't easily check up on your fellow teammates, it's especially important that you trust each and every one of them, and that they be worthy of that trust; all of the good practices and tools in the world won't do you a bit of good if they aren't followed.
Personnally I use several methods to make sure things keep running smoothly.
I use dotproject relgiously. Dotproject is a project management toolkit. It's browser based and very easy to use.
Besides that theres the code that needs to be maintained. For this I use a code formatter combined with checkstyle. With the code formatter you can format your code with the press of a button to conform to an approved standard. The checkstyle tool checks the created code on a large list of items, for formatting to javadoc commenting. Both the formatter and checkstyle run from within the development IDE so this works a treat. As long as everyone uses both you are sure to have a consistent code base which makes the life of the developers a lot easier.
I'm also running my own SVN server for version control and I'm looking into tools to create nightly build on that server. With these I should be able to detect coding errors early on.
For code testing I use JUnit. These unit tests can also be run automatically with a script, so when I get the nightly builds sorted, I can have it run the testscases as well.
I've run a few indie projects before, although this is my first atempt at game building. But I find that a good, stable project managent system and a good way to ensure code consistency are the two most important aspects. Even more so then the ability to talk to eachother on all hours of the day.
I use dotproject relgiously. Dotproject is a project management toolkit. It's browser based and very easy to use.
Besides that theres the code that needs to be maintained. For this I use a code formatter combined with checkstyle. With the code formatter you can format your code with the press of a button to conform to an approved standard. The checkstyle tool checks the created code on a large list of items, for formatting to javadoc commenting. Both the formatter and checkstyle run from within the development IDE so this works a treat. As long as everyone uses both you are sure to have a consistent code base which makes the life of the developers a lot easier.
I'm also running my own SVN server for version control and I'm looking into tools to create nightly build on that server. With these I should be able to detect coding errors early on.
For code testing I use JUnit. These unit tests can also be run automatically with a script, so when I get the nightly builds sorted, I can have it run the testscases as well.
I've run a few indie projects before, although this is my first atempt at game building. But I find that a good, stable project managent system and a good way to ensure code consistency are the two most important aspects. Even more so then the ability to talk to eachother on all hours of the day.
Author
Just thought I'd share what I've come up with since my last post, and maybe motivate some more discussion -- this is a big issue, after all. :-)
A big problem with working online is the desire to be formal, but the difficulty in enforcing it. You *say* tests should be run before checkins; X, Y, and Z should be true for cross-project use; etc., but you can't really *force* people to do it. Even with a good team (or, for that matter, a one-person team), it's hard to get people to follow those rules all the time.
So automate! Create a script that runs unit tests, then checks modified files into the repository. Create a small program that sorts through the code and makes sure X, Y, and Z are true. Make it *easy* to follow the rules; maybe even *hard* not to!
A big problem with working online is the desire to be formal, but the difficulty in enforcing it. You *say* tests should be run before checkins; X, Y, and Z should be true for cross-project use; etc., but you can't really *force* people to do it. Even with a good team (or, for that matter, a one-person team), it's hard to get people to follow those rules all the time.
So automate! Create a script that runs unit tests, then checks modified files into the repository. Create a small program that sorts through the code and makes sure X, Y, and Z are true. Make it *easy* to follow the rules; maybe even *hard* not to!
I'm preparing smoething along these lines atm.
I've setup my own svn server which my team uses for code versioning. I also have setup junit tests in the first project in there. Next step is to setup s script on the server which checks out the code from the svn and then runs the junit tests. Java even has a tool to check for codeblocks not hit by your tests. (Jcoverage).
I've setup my own svn server which my team uses for code versioning. I also have setup junit tests in the first project in there. Next step is to setup s script on the server which checks out the code from the svn and then runs the junit tests. Java even has a tool to check for codeblocks not hit by your tests. (Jcoverage).
On one project I'm on, we use BaseCamp for non-realtime group discussions, although gmail makes this possible through email thanks to the clever threading. However, I'm a big fan of the telephone. Actually talking to your team-mates can make it seem more "real" and break down some of the barriers you get in entirely online projects. Of course it can be hard with timezones, but if people can't find 1 hour a week that's not a great sign (unless you literally have people in all timezones, but normally it's just people in Europe & US and this is not a big deal).
You can also get online multi-user whiteboard apps, which combined with a conference call or MSN can give you a lot of ways to express yourself.
You can also get online multi-user whiteboard apps, which combined with a conference call or MSN can give you a lot of ways to express yourself.
Quote:Original post by ractocAll the stuff you mention is great. But I would anticipate you'd have problems getting a team on unpaid hobbyist game programmers to adhere to it. Many amateur game programmers are self-taught and young enough not to have had any formal teaching on this stuff, they like to simply start coding rather than plan things out... and as for testing, if it works then it's fine. This isn't a slight at amateur coders... in the games industry this is quite a common way for things to work. Unit testing and so on is not that common in the game industry
I'm preparing smoething along these lines atm.
I've setup my own svn server which my team uses for code versioning. I also have setup junit tests in the first project in there. Next step is to setup s script on the server which checks out the code from the svn and then runs the junit tests. Java even has a tool to check for codeblocks not hit by your tests. (Jcoverage).
I would love to hear how it works out... it would be great to know if you can get people to follow your ideas, but I have a suspicion it may be slightly idealistic to think they will - if you are constantly complaining about people not writing unit tests it can make you seem like a nagging boss which is not what people want when doing a project for fun.
Author
Quote:Original post by d000hg
I would love to hear how it works out... it would be great to know if you can get people to follow your ideas, but I have a suspicion it may be slightly idealistic to think they will - if you are constantly complaining about people not writing unit tests it can make you seem like a nagging boss which is not what people want when doing a project for fun.
Maybe a slightly modified TDD could be the solution: have the lead programmer(s) write the tests, and the other programmers write the code that fulfills them.
That sounds like a recipe for terrible engineering to me. If the "grunt coders" don't feel like they get to make modifications to the unit tests -- and, therefore, the code interfaces between modules -- then they'll feel forced into whatever design the leads come up with. This is usually a Bad Idea.
One thing that is vital to keep in mind on any team (online or all in person) is that the person closest to the front lines has the best intelligence on the battlefield. In other words, the guy actually implementing the module generally knows better than anyone else how the interface should look, and therefore the guy writing the module should be the one writing the module's tests.
I'm a bit of a hardass on this next concept, so feel free to completely ignore my opinion, but - IMO there is no good way to get people to follow a particular convention or coding practice (or design, for that matter) if they don't want to. Therefore, the only way to deal with people not sticking to the plan is to fire them (even if you're all working for free). You can decide for yourself how many warnings to issue, but eventually anyone who won't work with what everyone else has decided needs to go. This basically falls in with your original point that everyone needs to be trustworthy.
Now, these two points are related. Fact one is that the person closest to a single module is usually best qualified to decide how the module interacts with other areas of the code. Fact two is that anyone who doesn't do a good job needs to get sacked. The implication is that you need to make sure your definition of "a good job" is very carefully chosen, or you'll sack everyone and get nowhere [wink]
Specifically, never approach a multi-person project's design with just the ideas of a lead or two. Even if your grunt programmers are total newbies without a clue, they need to be involved in discussing how interfaces are to be designed and how elements of the code interact. Without this discussion, you have two problems.
First, the newbie with a strict set of marching orders isn't going to understand why these decisions were made. This makes it easy to assume that there isn't a good reason for a given decision, and the newbie gets the idea that he can do better. Which, maybe he can, but probably not. This ends in disaster and frustration for everyone.
Secondly, a newbie who never gets to make mistakes will never learn anything. This is a tragedy in a company team, where investing in your team members is paramount. In a hobby team, it's basically just a waste of everyone's time.
Obviously you don't want to carry this too far and end up with Design by Committee, which is of course Totally Evil. However, the other extreme can be just as harmful.
Just for clarity, this is the procedure I would personally recommend:
The biggest thing is to make sure everyone stays in touch and there is regular, complete communication. It's hard to do, but it's possible.
One thing that is vital to keep in mind on any team (online or all in person) is that the person closest to the front lines has the best intelligence on the battlefield. In other words, the guy actually implementing the module generally knows better than anyone else how the interface should look, and therefore the guy writing the module should be the one writing the module's tests.
I'm a bit of a hardass on this next concept, so feel free to completely ignore my opinion, but - IMO there is no good way to get people to follow a particular convention or coding practice (or design, for that matter) if they don't want to. Therefore, the only way to deal with people not sticking to the plan is to fire them (even if you're all working for free). You can decide for yourself how many warnings to issue, but eventually anyone who won't work with what everyone else has decided needs to go. This basically falls in with your original point that everyone needs to be trustworthy.
Now, these two points are related. Fact one is that the person closest to a single module is usually best qualified to decide how the module interacts with other areas of the code. Fact two is that anyone who doesn't do a good job needs to get sacked. The implication is that you need to make sure your definition of "a good job" is very carefully chosen, or you'll sack everyone and get nowhere [wink]
Specifically, never approach a multi-person project's design with just the ideas of a lead or two. Even if your grunt programmers are total newbies without a clue, they need to be involved in discussing how interfaces are to be designed and how elements of the code interact. Without this discussion, you have two problems.
First, the newbie with a strict set of marching orders isn't going to understand why these decisions were made. This makes it easy to assume that there isn't a good reason for a given decision, and the newbie gets the idea that he can do better. Which, maybe he can, but probably not. This ends in disaster and frustration for everyone.
Secondly, a newbie who never gets to make mistakes will never learn anything. This is a tragedy in a company team, where investing in your team members is paramount. In a hobby team, it's basically just a waste of everyone's time.
Obviously you don't want to carry this too far and end up with Design by Committee, which is of course Totally Evil. However, the other extreme can be just as harmful.
Just for clarity, this is the procedure I would personally recommend:
- Make your requirements and suggestions for conventions, practices, etc. known up-front. Tell any new members what your baseline is, and warn them in advance that failure to adhere to team standards is asking for a pink slip and a bus ride home.
- Once you have a team of programmers (or any more than one programmer), hold regular discussions of how each person's piece is progressing - with everyone involved. One of the key problems with online teams is morale. When you can't see what your colleagues are doing, it's hard to stay motivated. Keeping a development journal is a good supplement to this.
- Any time a new piece needs to be designed, or an existing piece needs changing (speaking of interfaces here, not implementations) figure out everyone who will be affected by the addition/change. Have all of them weigh in with their opinions, with the programming lead having final say on how things are actually done at the end of the day. Decisions about implementation can be held down to the person implementing the code, and the lead.
- If you notice you're having an awful lot of meetings about changing things, stop, take a deep breath, and reconsider your entire architecture from the ground up. Make sure you aren't making any huge mistakes. Always try to recover early rather than late -- and constantly fiddling with things is usually a sign that something is wrong. Sprints are a great way to detect this kind of problem and react quickly.
- Try to keep programmers decoupled from each other; if there are two modules that are tightly integrated, don't assign each module to a separate programmer. This avoids problems where two programmers try to solve the same problem in two different ways. I can say from hard experience that this is something to avoid at all costs.
The biggest thing is to make sure everyone stays in touch and there is regular, complete communication. It's hard to do, but it's possible.
I can only agree with the previous post. I can setup all the tools I want, but in the end, people will have to use them.
Some tools I can enforce, like checkstyle, writing tests is something I need to check myself though.
With respect to different programmers writing different modules, this is my setup as well. Each module then has an external interface. Whenever a consumer of the module needs a new method, he can request it and the module owner will then add it to the interface. The actual logic behind the method is totally up to the module owner though. The owner is even allowed to alter the logic at any time, as long as the interface doesn't change. So if a certain method yields a certain result, this result mustn't change, other then that any changes to the underlying code are allowed.
Part of a request for a new interface method is the reason for the method and how it will be used. Both of these are important consideration needed for building the method. A method that's called only occasionally can have the emphasis on manageability while a method that's called very frequently will have the emphasis on performance.
Some tools I can enforce, like checkstyle, writing tests is something I need to check myself though.
With respect to different programmers writing different modules, this is my setup as well. Each module then has an external interface. Whenever a consumer of the module needs a new method, he can request it and the module owner will then add it to the interface. The actual logic behind the method is totally up to the module owner though. The owner is even allowed to alter the logic at any time, as long as the interface doesn't change. So if a certain method yields a certain result, this result mustn't change, other then that any changes to the underlying code are allowed.
Part of a request for a new interface method is the reason for the method and how it will be used. Both of these are important consideration needed for building the method. A method that's called only occasionally can have the emphasis on manageability while a method that's called very frequently will have the emphasis on performance.
Author
Quote:Original post by ApochPiQ
I'm a bit of a hardass on this next concept, so feel free to completely ignore my opinion, but - IMO there is no good way to get people to follow a particular convention or coding practice (or design, for that matter) if they don't want to. Therefore, the only way to deal with people not sticking to the plan is to fire them (even if you're all working for free). You can decide for yourself how many warnings to issue, but eventually anyone who won't work with what everyone else has decided needs to go. This basically falls in with your original point that everyone needs to be trustworthy.
Very true, but easier said than done. Sometimes it feels like it would be easier to just take all the work on yourself to make it as easy as possible for the "underlings" to follow the rules -- it's a recipe for failure perhaps, but especially with "good" programmers so hard to find (hell, *any* programmers -- look at the help wanted section), it's really hard to take one of the few you have and fire them.
I suppose the old adage is true though: a team is only as good as its (weakest) members.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
