Sign in to follow this  
tntcheats

Different programming skill levels + splitting up the project

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by tntcheats
A thought came to mind: the group as a whole has varying skill levels in programming.


Ooh, you are treading on dangerous territory here. Throughout my degree (compsci) I've been involved in three different group projects developing software - and have always spent a lot of time fixing and doing the work of the members with lower "skill levels". While it is fun to work with your friends, if you are all at different levels then I would consider not trying to develop some software together. However you will only learn his lesson by going through the paces, so I recommend giving the people with the lower skill levels utility coding jobs, like level editor, character editor, etc.

Good luck.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Signed, Paul

Share this post


Link to post
Share on other sites
However you will map jobs to your team, NEVER offer any job that is not needed at the moment. If someone develops anything for you: try to give always feedback, tips and inform them of how and when you are going to use the product. And integrate it as fast as possible, this will motivate them very much!
Just my 2 cents:)
cheers,
Patrick

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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*

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this