View Single Post
  #9   Spotlight this post!  
Unread 21-09-2006, 01:44
Donut Donut is offline
The Arizona Mentor
AKA: Andrew
FRC #2662 (RoboKrew)
Team Role: Engineer
 
Join Date: Mar 2005
Rookie Year: 2004
Location: Goodyear, AZ
Posts: 1,289
Donut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond repute
Re: Software Team Organization

This is a good idea that's been tossed around on our team before, but unfortunately none of us have the time or experience to really implement it.

If you're looking for simple alternative methods (or anyone in this thread is), here's what worked quite well last year for us (note this is on a team where all of the coding was done on 3 laptops, since we couldn't install programs on the school computers):

1. Make a new project everytime you have a major code change (in case it ends up not working and you have to revert). Try to keep a simple naming system that makes sense; we had "Base 01", "Base 02", etc. for our beta builds, and "Release 101", "Release 102", etc. for our official tested and working builds.

2. Try to divy out the different tasks to a few different groups, so that each of you can produce different files and then merge all of them together in one super project. This eliminates alot of the over-writing each others code problem since you work in entirely different files for most of it.

3. Make sure the code is updated on all systems at the end of every day. In our case, we uploaded the most recent version of each file onto a flash disk in one updated project, then uploaded this project back onto all the computers. As an alternative, have each group work in different builds (group programming autonomous in base 01, group programming drive in base 02, etc.), and upload the most recent version of each project onto each computer.

4. Have one person focus on making sure everyone elses' code will fit together and that everyone is in a group doing something, a "project manager". They might also want to keep a running Read Me file as to what has been added to a project since the previous version.

5. Set a meeting with the electrical team heads, and make sure all wiring decisions are settled and documented in something both groups have a copy of. Create an alias file that is very easily changable in case someone doesn't adhere to this code, and you end up having to change a wire or 2. If you have the programs to, try to have a visual wiring diagram that shows what everything is going to (if desperate, powerpoint works nicely).

That's a general gist of what we did last year, and we should be using about the same method this year. Not being able to use school computers can be very restrictive upon your team, but it also forces you to really know where everything is since you can't have a network sitting there to store everything.
__________________
FRC Team 498 (Peoria, AZ), Student: 2004 - 2007
FRC Team 498 (Peoria, AZ), Mentor: 2008 - 2011
FRC Team 167 (Iowa City, IA), Mentor: 2012 - 2014
FRC Team 2662 (Tolleson, AZ), Mentor: 2014 - Present