I am on 1024 and the software team captain as well as manufacturing coordinator. We use C and have 7 people on our programming team. I've found that everyone can have a purpose...
I have one guy thats awesome at Visual Basic 6... so, he makes rockin front ends that eat data off the dashboard port the robot passes back... mostly his tools are used for debug. He works closely with an interface programmer on the robot side that does the feedback going through the dashboard port (there are 8 user bytes that can be passed back, they usually operate on a rotation schedule so we get anywhere from 8 to up to 32 bytes (depending on update rate you're ok with) passed back).
Then, we have people who all have various parts of the robot... novice programmers work on the teleoperated period getting data from the OI... more advanced programmers take on different implements on the robot and write the drivers for them... this class of programmer also writes drivers for any new sensors we might encounter (camera two years ago, ultrasonics last year). The most advanced/gifted programmers and myself work heavily on the autonomous mode programming and any highly complex sensor drivers.
Anyone left over does cool stuff (extra features) for the robot... usually there isn't any one left for this... but this year we have a couple that want to try doing automatic rollover mitigation for the robot in case we have an unavoidably top heavy design.
For multiple codings to interface with single motors (i.e. teleoperated PID velocity control interlaced with rollover mitigation) overarching conditional structures are implemented to decide which control output to use based on the magnitued of 'decision indicies'... basically these values relate how dire the need is for one or the other algorithm to get at the motor. The fancier approach we're trying this year is wiritng algorithms such that their outputs sum to a final control output. That last part's still in R&D but expect it this year.
Anyhow... yes you can use a lot of programmers.
-q