Hi, I'm thinking of tryign to get into making games with a few friends of mine. (Don't worry, not starting 'over our heads' and thinking we can make Mario Kart right off the bat) A thought came to mind: the group as a whole has varying skill levels in programming. So I was kinda wondering... since there are obviously people here who have obviously collaborated in similar conditions: how do you cope with something like that? How do you split the project up, make sure all the code works and will be able to work with the different sections being made by different people? Thanks.

1) I generally try to make sure that those of us with experience and know how do the overall structure/design. That means a list of all the classes that more than one person are going to use, and a listing of all their functions, arguments, purpose, etc. This way you can tell someone which piece of functionality to implement and they know what they have to do.

2) Find out what people DO know how to do. Try to match their skills with one of the tasks at hand. If someone has only ever done GUI programming, get them to make the GUI interfaces for your tools.

3) Assign jobs so that the less experienced the smaller the job is. It needs to be a small piece of functionality thats purpose is easily comprehended, so that someone without experience won;t sit there and think "How do I do this?" For example, you don't tell someone without experience to write everything having to do with saving and loading levels, but you might ask them to write out a list of everything that needs to be saved in a level file, and then ask for a format for the level file, then a saver, and then a loader.

Basic jist is that the inexperienced require a higher level of micromanagement at times.

4) Avoid "flexible" work arrangements. People can work at home, but there should also be some definate meeting times where actual programming is happening. If someone isn;t actually doing anything it should put up a red flag. It could be they are stuck on something that someone else can help with and do so right away, at the meeting). It could also mean that someone needs a smaller task, or isn;t really ready for the project.


Of course, your mileage may vary.

In any project there will be simple and difficult bits. A good up-front design is always important on any project, especially when multiple people are working together. I tend to break the project into clearly defined modules and define the interfaces between the modules.

Once you have done this, you can work out which are easiest to do. If it's a game, something like arranging the high score table (for example) is reasonably simple and a lesser skilled person could do it. Each person then has their own modules and interfaces to develop. Then bring them all together and work together on getting it all working.

Plus you benefit from having self contained modules which can be used in other projects, provided the interfaces are generic enough.


Good luck!

Robert C Martin has written an excellent book called "Agile Software Development" that will def give you a few ideas on team management and compensating for different levels of skill. If you cannot afford to buy, I encourage you to try and get it from a library or something.
It also shows you *practical* applications of software design patterns, with decent samples - so if you've heard of this pattern stuff but don't get why - this will show you the why and importantly when to use them.

Quote:have always spent a lot of time fixing and doing the work of the members with lower "skill levels".

That's why you need test driven development. Structure your code in lots of independent bits/subsystems. Make sure that each subsystem is fully unit testable. If there's a bug, first write a unit test that reproduces the bug (by failing), then check in that test. Then fix the bug. This means that finding and fixing the bug can be done by two different people.

It's also important to only develop parts that have immediate users. If someone checks something in as "done" and the user can't use it, that should provide ample feedback loop back to the contributor that it wasn't, actually, "done".

"Agile Development" and "Test Driven Development" and even "Extreme Programming" might be good terms to search for to figure out how to build a development organization that can develop working software in a heterogenous environment.

Quote:Original post by hplus0603

Quote:have always spent a lot of time fixing and doing the work of the members with lower "skill levels".

That's why you need test driven development. Structure your code in lots of independent bits/subsystems. Make sure that each subsystem is fully unit testable. If there's a bug, first write a unit test that reproduces the bug (by failing), then check in that test. Then fix the bug. This means that finding and fixing the bug can be done by two different people.

It's also important to only develop parts that have immediate users. If someone checks something in as "done" and the user can't use it, that should provide ample feedback loop back to the contributor that it wasn't, actually, "done".

"Agile Development" and "Test Driven Development" and even "Extreme Programming" might be good terms to search for to figure out how to build a development organization that can develop working software in a heterogenous environment.

*nods*