Programming Team Size

[coastertux]

From your experience, what is the ideal size of a programming team? Last year my team had 2 people, but we have about 10 people interested this year. Is that too many or is it possible to find enough to do for everyone to stay busy? Thanks in advance!

[Ryan M.]

Originally Posted by coastertux

From your experience, what is the ideal size of a programming team? Last year my team had 2 people, but we have about 10 people interested this year. Is that too many or is it possible to find enough to do for everyone to stay busy? Thanks in advance!

10 is probably too many. Depending on how complex you plan on making things, anywhere between 2 and 5 is probably plenty. We had 3 last year.

[Greg Marra]

Our programming team is about 5-6 kids. I think at times it is hard to keep everyone doing something, especially when something specific needs to be accomplished. Everyone sort of has to crowd around the laptop and watch the one person at the keyboard, and it can be a little (actually, a lot) boring.

One good way to break it down would be to have part of your programming team working on programming the EDUBot or the Vex robots. They're very similar to the full size robot, and it's a lot easier to test code on them since you don't have to worry about smashing into anything. That way you can have two programming teams that work together on different objectives.

[Rickertsen2]

Our programming team has never had more that 3. It seems that with any more you will start spending more time on coordination and less time on productivity. I'm not saying its impossible, but you will have to focus much more on keeping everyone together. I have told several interested people that i would be happy to try and teach them some programming, but we need effeciency when build season comes around and we already have enough experienced programmers. There is only soo much to do on a project this small.

I would put down 1-4 as the ideal number.

[Ian Curtis]

I'd say maybe 1, but 2 or 3 is far better. One experienced programmer can get things done by themselve, assuming you get the robot to them with enough time remaining (and let's face it, that doesn't often happen). Therefore with a team, more can be done in a short time. However as soon as people start hanging around the computer(s), you've lost your effiency as a team.

[hoag]

My programming team is a combination of programmers/custom electronic people. We have 8 people in the group. Some of us work on code, others work on encoders. With a large group, we tend to get off task and do random things like shout quotes from Zero Wing. But it's great having a large group, we usually get lots of things done.

[phrontist]

One person.

Really.

In the offseason there should be multiple people learning the ropes, and all members of the team should of course understand how the other subsystems work (doubly so for programming), but the robot code is rarely complicated enough to allow for any reasonable task division.

The only case where I'd consider more than one would be if you had a co-processor for some specialized function that required a lot of code.

[Greg Marra]

Originally Posted by phrontist

The only case where I'd consider more than one would be if you had a co-processor for some specialized function that required a lot of code.

Last year I was pretty much "the camera guy." If there's another component with as much complexity as the CMUCam this year, it might make sense to give a person or two that task to work on separately.

[Ryan M.]

Originally Posted by phrontist

the robot code is rarely complicated enough to allow for any reasonable task division.

Very true, but there are ways to break it up a bit. Last year, we had three people. One got autonomous (we didn't use the scripting, so it was slightly more involved), one got drive controls, and one got arm control. By breaking it up, we were able to each make our part more complex and advanced than if one person had to do all three.

[Redneck]

Last year, my team had 6 programmers: 3 experienced, 3 n00bs. We divided into three sub-teams of 2 (one vet, one n00b) and each sub-team worked on a seperate programming section. One team worked on the CMU Cam, one team worked on other sensors (encoders and gyros) and one time worked on a dead-reckoning autonomous.

[wilshire]

one is all that is really needed and there should be several on the team that should know C and basic componets of the default code and the code you have on your microcontoller just in case. When you have more than one person then the code can get messy if you aren't using uniform variables. But everyone here im sure uses good programming practices

[raiofsunshine]

Our team this year has about four people, which seems to be a good size.

[jdhawg]

Team Fusion had one engineer (me) and one student during the 2004 season. In 2005 we upped it to the two of us from 2004 and 4 additional students. In reality, one experienced person (engineer or really sharp student) and two or three people wanting to learn about programming are what you need. Since I was always about 1.5 - 2 hours late each night of the build season, I broke our programming team last year down into semi-scouts. I put one person with the mechanical team, one with pneumatics, and one with electrical. When I got to the shop from work we would meet to discuss what surprises the other groups had added to the robot without letting us know in advance.

[Ryan M.]

Originally Posted by jdhawg

I broke our programming team last year down into semi-scouts. I put one person with the mechanical team, one with pneumatics, and one with electrical. When I got to the shop from work we would meet to discuss what surprises the other groups had added to the robot without letting us know in advance.

Now that is a dang good idea. People who's only job is to keep track of robot changes which affect programming (IE, everything). I suddenly have a use for the 6 people who want to learn programming...

[TechnocratiK]

One person is the way to go, unless you have a nice RTOS setup, which you hopefully don't, since it's a great way to waste memory on the PIC. If your robot testing grounds are away from where you build the robot, though, make sure you have someone check on your programmer every so often - returning at 2:00 am one Sunday morning after 8 hours of programming, I found the rest of my team concerned that the robot had run me over, which it had, although without injury.