![]() |
Programming Team Size
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!
|
Re: Programming Team Size
Quote:
|
Re: Programming Team Size
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. |
Re: Programming Team Size
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. |
Re: Programming Team Size
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.
|
Re: Programming Team Size
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.
|
Re: Programming Team Size
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. |
Re: Programming Team Size
Quote:
|
Re: Programming Team Size
Quote:
|
Re: Programming Team Size
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.
|
Re: Programming Team Size
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 :)
|
Re: Programming Team Size
Our team this year has about four people, which seems to be a good size.
|
Re: Programming Team Size
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.
|
Re: Programming Team Size
Quote:
|
Re: Programming Team Size
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.
|
Re: Programming Team Size
<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. |
Re: Programming Team Size
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:
|
Re: Programming Team Size
We have had only one programmer in the past, now we have 5 interested people.
|
Re: Programming Team Size
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.
|
Re: Programming Team Size
Sean, we have plenty of PCs and this will be our second year in FIRST so we will have two controllers.
|
Re: Programming Team Size
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; |
Re: Programming Team Size
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... |
Re: Programming Team Size
Quote:
|
Re: Programming Team Size
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.
|
Re: Programming Team Size
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.
|
Re: Programming Team Size
Quote:
|
Re: Programming Team Size
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). |
Re: Programming Team Size
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. |
Re: Programming Team Size
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. |
Re: Programming Team Size
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 |
Re: Programming Team Size
Quote:
As far as diffs, I would recomend KDiff3: http://kdiff3.sourceforge.net/ There are versions for Linux, Windows and MacOS X |
Re: Programming Team Size
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. |
Re: Programming Team Size
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 |
Re: Programming Team Size
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. |
| All times are GMT -5. The time now is 00:10. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi