I too expect some, if not many of that initial group to drift into other sub-groups, or just milling about. Large numbers of programmers can, and do work on single projects regularly. Although it is less common for LabVIEW enviornments compared to the other languages, I worked on one LabVIEW project where it would have been very easy to have 30+ people working on it. The biggest challenge will be to separate the various tasks very discretely, and with very clear chains of communication.
Source control will be of interest to you, and I highly recommend it to all teams anyways. With GitHub just allowing special help to FRC teams, I would highly recommend you take a look.
Reference
I would suggest these modules as a starting point:
- Vision
- recognition
- targeting
- tracking/PID
- Drive systems (This will include acceleration controls, etc.)
- Various sensors (May be to small to split up, but any processing you would do with these)
- Dashboard
- Probably the easiest to split up into smaller tasks if you decide on advanced driver controls.
- Practice field testing procedures
- Just like a checklist for the mechanical side, you will want to test various features. You will have to come up with ways to test and validate these features. (Re-testing for bugs is critical, as a small change can always introduce errors in code that was working before.) I would personally put several people here if you can afford too. Have these people watch the other coders, and figure out what needs to be tested, then actually design these tests.)
- documentation (for the mentors, drivers, and the following year's team)
- (This could probably be the same checklist people)
- non-competition code, and features. (Things that you would want to do for advertising your robot in your community.)
- Website
- Mobile phone stuff to communicate to the robot. (This is eye-candy like, but very effective)
- I'm sure you will think of many more largish modules.
I also like the suggestion of giving a bit of a mini competition to the programmers. This will get their productive juices going, and weed out the non-programmers. (IE. The ones that are just tagging along. Identifying these kids will let you know who will need help to figure out their roles in the team. Ideally keeping them in the team instead of them drifting away.)
Good Luck!