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.]

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]

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.]

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.]

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.

[coastertux]

<off-topic>Ha ha, that reminds me of when I was almost hit by our robot's knock-down arm. A very close call (it would have injured me if I got hit). :ahh: </off-topic>

So it seems like the "special number" is 4 people...is there any way I can get more involved? I hate telling people they can't do a certain job that they want to do. I happen to agree though, any more than four would be bad as people would just end up sitting around and/or making more work for us.

[TechnocratiK]

What limits the number of programmers you have is mainly the complexity of the code. I can see 6 to 10 or more programmers working fine without interfering with each others' work if the robot is properly built. Must haves for a large programming team? Encoders and a gyro. Just to name a few, here are some of the things that you could add to your robot's code to make it a bit more interesting:


In autonomous mode, have a function that moves the robot to a specified location on the field, and turns to it face a certain direction.
Use that same piece of code outside of autonomous mode to turn a tank or four-wheel drive robot into an omnidirectional robot.
Instead of doing empirical analysis, use your robot to keep track of the acceleration with respect to the input value, and make it modify your motor outputs to linearize the top speed with respect to the input value.
Create a waypoint-selection system and "go to" button interface so that, in the dying seconds of the game, when your drivers are weary and blurry-eyed, they can press a button and let the robot get itself back home for those extra 10 points.
Create a full-fledged navigation system in which the robot is aware of its current location on the field, as well as the location of any static field objects, so that it will turn to avoid bumping into walls, goals, etc. when going from point A to point B.
For multi-jointed manipulators, add position sensors (potentiometers, optical sensors, etc.) and convert awkward polar motions into clean, intuitive linear motions so that when the operator pulls back on the joystick, whatever the arm's holding moves straight up - no circular motion.
Use scripts (or, if you really want to get fancy, arrays of instructions as well as a script processor) to automate tasks, both in and out of autonomous mode.

[MarkVH]

We have had only one programmer in the past, now we have 5 interested people.

[seanwitte]

The size of the team depends mostly on resources. If you have a few PCs and robot controllers then you can support a larger team. If you only have one laptop it will be hard to get more than a handful of people involved. A team of one person, unless you have no choice, is ridiculous. Just because the person with the most experience can't be bothered to integrate source from a few less experienced people is not fair to the rest of the team. What happens if the ivory tower alpha geek gets sick and can't make it to the competition? I would say you need two people minimum, on a larger team appoint one tech lead for design and integration.

[coastertux]

Sean, we have plenty of PCs and this will be our second year in FIRST so we will have two controllers.

[Squall]

I would say that this can vary from your creativity.

First is about a lot more then just robot programming, if you're creative enought you can make all kinds of stuff.

Last year we updated our picture to our website, and we had to add our team number into each picture.

Then I've just developed a software that would do that, it helped a lot our website team, I know that photoshop can do that, but we don't have Photoshop, and were's the fun on using it right ?

And the one really great thing we created was the Autonomous Control software, wich is a graphical windows software that can be used to control the Robot in the "arena" and it would just create the code for our autonomous implementation.(I must release the source code to everyone, but some menu stuff are in portuguese, it's not 100% translated.)

And you can always try to use first a real programming lesson for the students. You can have some methodology to follow, like RUP or MSF, this kind of stuff that involves lot's of documentation and discussion before actual coding, this could be done in a larger team.

The big challeng will be to convince a 15 years old not to play with the robot joystick and develop programming documentation. or if he's a programming crazy, to make him stay away from code, and use only Word;

[Ryuichi]

My team actually has seven Programmers on our team this year. I believe this is our fifth year as an established FIRST team.

And I agree with you, Squall. We do have a hard time not playing with the robot joysticks, but keeping away from the Anime viewing on the laptops and drawing on each other's papers with notes. We tend to procrastinate, but we get the job done, as our CMUCam actually recognized the green, and accelerated forward for a few meters and just stopped...

[Astronouth7303]

And the one really great thing we created was the Autonomous Control software, wich is a graphical windows software that can be used to control the Robot in the "arena" and it would just create the code for our autonomous implementation.(I must release the source code to everyone, but some menu stuff are in portuguese, it's not 100% translated.)

That I would be very interested in. I've done autonomous abstractions (in the form of "scripts"), using primarily the preprocessor. But I have yet to make an external tool.

[Hutch]

I solo'd this last year for our team in a few days. At most, you'd need like 2 people - any more than that the marginal costs of adding people (extra source control, etc.) would far outweigh the gains of having one more person working. Besides, a FIRST robot doesn't need a lot of code, probably only 1-2.5KLOC with an autonomous mode.

[Eldarion]

On a FIRST robot, one or two. I was the only member of the software team last year and it looks like the same this year as well.

[Rickertsen2]

That I would be very interested in. I've done autonomous abstractions (in the form of "scripts"), using primarily the preprocessor. But I have yet to make an external tool.

Last year we wrote a nifty tool called ARCAMS(autonomous robot configuration and monitoring system) that allowed you to graphically create autonomous scripts and then upload them to the RC EEPROM over the serial port. It also allowed realtime graphing and datalogging of just about any robot parameter you can think of.

[aaeamdar]

Our team overall is fairly small, numbering about 15 fairly commited (we're rookies). Kinda unfortuneately, we have 5 people doing programming. I don't know how tough it will be to keep them all working.

I know at CTY I started work on a little space shooter game written in Java (C is not my first language so to speak (no pun intended)). I worked with another guy and he was less confident about the programming. Unfortuneately I ended up doing most of the programming (not that I'm not competent, but we could have gotten more done).

I Guess it'll be my responsability to give out tasks, and whip those sorry recruits into line (*pirate-like, drill-sergeant-reminiscent growl*).

Just my 2cp (again).

[charrisTTI]

Ways to involve more people in software:

Build simulator boards with components and controllers from previous years. Use them for training and for testing concepts. Multiple simulator boards can allow multiple programmers to work at the same time.

Use the simulators with "mock ups" to validate concepts while the mechanical team is building the real robot.

Learn to use the simulator in the Microchip IDE. The simulator allows you to "run" code on your PC, including the ability to provide sensor input. This is a great way to check basic flow of execution because you can single step the simulation. Once the code is on the robot, all you have is print statements and the dashboard.

Organize the software project (the MicroChip IDE project) to make it easier to have multiple contributors. Don't have everything in one or two source files. Break the different aspects of the program into separate source files. This allows multiple people to make changes at the same time (without overwriting each others changes).

Implement a version control system to keep track of changes. A simple way is to take "snapshots" of your project file directory on a regular basis (daily, hourly, any time you make a big change, just do it). Learn to use a diff (difference) tool to compare different revisions of the same file to see what was changed.

Implement a backup system so that failure of a hard drive etc. does not result in the total loss of source code. When taking a "snapshot" (see above) make second copy to different computer, a pocket drive, zip disk, floppy disk, SOMETHING!

Write a separate diagnostic module to download to the robot to aid in debugging and testing. The code that actually runs the robot is not always the best for trouble shooting a problem or performing a system test to insure that all sensors, motors, etc. are working properly

Team new members with experienced members (for the whole development cycle). Train for next year while developing for this year.

Assign software team members to act as the interface point with the other design groups. That way the other design groups know who to go to with a question. That person should attend design meetings of their assigned group to make sure that needs of software group are being met by the design. (ie do we need a sensor, where is it going to mount, how many do we need, what kind should we use)

Assign software team members to become the team expert in various areas, there is so much information no one person can possibly learn everything.
Microchip IDE/Development Environment expert
Operator Interface Expert
Robot Controller Expert
Victor, Spike, Radio Link Expert
Sensor Expert(s)
....

Assign a member to document the interface (how does everything hook up). When a wire comes off, people can lookup where it goes.

Have a design document which describes how each major "component" will work. If you can't explain in words how something is going to work, you shouldn't start writing code. This document can be the source code file. Describe in words how the function or module will work. Later add code between the descriptive text lines. Voila - clearly documented code that someone else (or you 3 weeks later) can understand.

Software development can be a "team sport" if we work at it.

[tckma]

I think the best thing to do is to have one or two veteran FIRST programmers (if possible, i.e. not a rookie team) and two or three people who are learning. This way when your seniors graduate you have the people who are learning becoming the veterans the next year.

In my FIRST experience (4 years with three different teams), if you have only one student (or in certain cases, one adult! ugh!) writing the code, then you don't get people very interested in the programming. You also have potential problems when mechanical decides to change the design of the robot 16 times in one day and overloads this one kid with programming demands.

Any more than 5 people on the programming sub-team and you run into problems where no one understands the code, and software version control becomes a problem.

[JamesBrown]

last year it was just me, this year it is me and a college student. It helps to have atleast one person with decent knowledge of code structure and one with a decent knowledge of the bot, subsystems sensors, custom electronics etc. If one person can do all of that then you only need one. If not then break it up.

Any one who says no more than one person can program this simply means your code lacks comments and structure, someone with little knowledge of the code should be able to follow your changes with little effort. 2 experienced programmers should be able to work easily side by side

[SoftwareBug2.0]

Ways to involve more people in software:
Implement a version control system to keep track of changes. A simple way is to take "snapshots" of your project file directory on a regular basis (daily, hourly, any time you make a big change, just do it). Learn to use a diff (difference) tool to compare different revisions of the same file to see what was changed.Without an easy way to tell what changes have been made, you're better off with only one person programming the main controller.

As far as diffs, I would recomend KDiff3: http://kdiff3.sourceforge.net/
There are versions for Linux, Windows and MacOS X

[X-Istence]

I am currently a one man programming team, with one rookie who needs to learn the ropes of the current code, and then needs to use that for next year, to program the robot.

I for the purpose of showing what changes have been made over a certain week (so that I as the programming team can show that I am contributing to the entire project), I have versioned the entire code into subversion, which allows people to check the code at the same time, and then merge changes into the project.

Makes tracking progress a lot easier, and knowing when things are happening and why. Also the possibility to go back several revisions, to working code, means that there should never be a problem with having code that is not working properly.

[varcsscotty]

if you guys want a good programming team you need more than one. I'm the lead programmer and not only do I have to teach kids for next year but I have to actually get the stuff done.

There is plenty that my programmers do. Build the camera, program Auton modules, set up the controls, take notes, do research, calculate physics, run tests. plenty of tasks for everyone. if you go a little more in depth.

but I would say no more than 5 probably. plus trainees

[Total Meltdown]

Our programming team size is pretty good. We have Myself, and SubQuantum, who are basically the programming Gods of the team. Then we have a member who knows C, but isn't entirely to our level, and I think 3 rookies. This allows SubQuantum and I to work on the more advanced stuff, such as our proposed Neural Network Autonomous code and the automated Ball turret, while the other 4 do driving code, LED control, and maybe a few simple Dead-reckoning State machines for Auton. mode.

I say Two for the super-advanced stuff, and then a slightly larget team of 3-4 for the mid-range stuff. Either way, for a project like this, I wouldn't go with any more than 6.