Too many programmers ?
 

We had a team meeting tonight -- our team is having tremendous growth (approx 50-60 total) , and we are going from a handful of programmers last year to maybe 20 people expressing interest in programming this year. Not a lot of experience (either inside or outside FRC that we know of yet)

Any tips on how to keep so many programmers involved? I can't see how we can manage a programming team where everyone is going to contribute to the competition robot... We are having some LabView training classes/seminars once every two weeks thru the end of the year, but the Mentors are not very far ahead of most of the students. We have one student who is ahead of everyone and has been lead programmer for pretty much the last three years.

Re: Too many programmers ?
 

It may be useful to have training, challenges, or competitions based on the new simulation features. More details are on the 1718 beta site.

Greg McKaskle

Re: Too many programmers ?
 

We are in a similar situation, although I can't say we have 20 people interested, we have far more than needed.

As the lead programmer, I am assuming that interest will slowly fade away, and it should end up being 3-5 people. It's definitely not doable to have 20 people contribute to the robot code.

Possibilities if they don't fade away:
- Make a core group for robot code, and let the others work on other projects (apps, website, etc.)
- Make the robot code a 'competition' of sorts. Have 2 groups that are competing to make better robot code, and at the end combine the best parts of the two.
- Although this is the least favorable, it's certainly possible to put a cap on how many programmers are allowed on the sub-team. If a lot of them have little experience, I'm sure they'd have just as much fun doing CAD or machining or anything else.

Re: Too many programmers ?
 

Our team had this exact problem in the 2011 season.
The fact of the matter is, having 30% of the team as programmers is overkill. You should try to engage students in other fields that may be of interest, (namely CAD, Website).
If you still find yourself with a large group of dedicated programmers then have some of the new guys pair up with the veterans and assign them a task, make sure they document everything they do (with a large group of students this is critical).
Either way, students will mingle in and out of groups throughout the season.
Good luck!

Re: Too many programmers ?
 

Writing a scouting system is another thing that extra programmers can work on.

Re: Too many programmers ?
 

Try and find out why they are interested in programming as opposed to another subteam. If someone wants to program because their friend wants to program, and their friend is only there because the first kid wants to program, look at that, you can already relocate 2 students to another subteam.

Re: Too many programmers ?
 

I would break them into 3 teams: robot, scouting, and website. That will let them all stay involved, while cutting down the number of people working on any single project.

Re: Too many programmers ?
 

Oh man you havent seen nothing yet. Our team has over 100 people and 27 of them are programmers. When I say programmers I mean only programming the robot. We already have a cad team, webdesign, videography and photography. Right now we are going FTC and we have 2 teams. I basically split up the programmers and told them to write their own pseudo-code. After that I would split them up into sub teams to write their part of the code, like 2-3 people would write the drive code. I still havent figured out a plan for FRC yet. I hope this helps.

Re: Too many programmers ?
 

+1 to this. People generally like the 'idea' of programming, and not really programming itself. Which isn't to say that you won't have 20+ dedicated programmers, that's definitely a possibility. This is just to say that it probably won't go down that way.

- Sunny G.

Re: Too many programmers ?
 

http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Re: Too many programmers ?
 

Interesting read.

Re: Too many programmers ?
 

This year I expect up to 8 returning, 2nd year programmers and at least 1 rookie (we had all rookies last year). I am planning on a multiple project approach similar to Jon's.

Eric

Re: Too many programmers ?
 

We typically have 9-10 interested programmers each year on a team of about 32. So we usually split 3-4 of them into programming the scouting system, 3-4 basic robot code, 3-4 of them specialized code for vision, dashboard, autonomous. It usually ends up as one student in each of those three areas doing most of the coding, while the others learn and help diagnose/troubleshoot.

Re: Too many programmers ?
 

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!

Re: Too many programmers ?
 

I would suggest that if you have one person who has programmed the robot before, keep them on it. Then take the top 3 from the rest, and have them 'shadow' the programmer so that they can see how it all works, and the lead can hand off small projects to them, such as compressor code or the like (assembla has free perforce hosting which makes this easy).

I would say that if they haven't programmed before, you will see at least 50% drop off the programming group, as it has what a friend once described as a 'vertical learning curve.'

Also: put people at work learning with some of the new robot simulator code, but only if you have full mechanical teams already. I am one of the lead programmers for my team, and I am speak from experience that labview is difficult to learn if you haven't programmed before, but I will always try and steer programmers in training towards mechanical during build season if it will get the robot to me faster for debugging.