Programming Team Best Practices

[holygrail]

What are some of the best practices for an effective programming team?
I'm looking more for best operational practices rather than how to actually write the code. We are trying to bring a couple of new programmers up to speed quickly and effectively and I think it would be valuable to hear how other teams do it.

1. How does your team effectively delegate the work between programmers? Do you have several programmers work on separate parts and then put them together or do you have everyone work on the same program?

2. How do you plan the code before you start programming (flowcharts, etc.)?

3. What kinds of benchmarks do you use to keep the programming team on task throughout build season?

4. What backup techniques does your team use to manage files effectively (cloud, etc.)?

5. Other tips, tricks, or suggestions?

THANKS FOR YOUR HELP!

[F22Rapture]

Use a Version Control system (VCS) such as Subversion or Git, and a code hosting website such as Github or Google Code. It takes some extra effort to learn, but it makes keeping track of your code changes a billion times easier, and if something happens you'll always have a backup copy of your code.

Always have code that compiles. When you make a substantial change to the robot, make a new branch (in version control) and make your changes to that branch instead of messing with your clean copy. When all the kinks have been worked out and everything works as expected, you can merge that branch into the master branch and continue the cycle.

Work in sprints. Set milestones that you want to achieve by the end of each week and try to hold yourselves to those deadlines as much as possible.

For other non-code materials such as reference guides, installers for software and compiled programs, we put them in a shared Dropbox folder or something similar (Google Drive, etc, but I prefer Dropbox.)

I can't comment on how to delegate work because our team has only had one programmer since its inception 2 years ago. Since he graduated and we gained a few new members who might be interested, I'll be interested to see how the other teams manage things.

Git (Version Control System) - http://git-scm.com/
Github (Code Hosting) - https://github.com/
Dropbox (Cloud Storage and Sharing) - http://db.tt/EkhzyId

http://en.wikipedia.org/wiki/Agile_software_development

[Jay1986]

After programming training, we had our new members attempt to put together running code for our previous robots (such as 2011). With the help of experienced members, they grew into the mindset of how to actually program a robot instead of silly tasks in training.

1. We have a Lead Programmer and a Mentor work on the overall robot, putting together programs, more difficult work and writing equations. While we give other programmers simple tasks that can keep them busy (such as a solenoid for a gearbox).

2. BEFORE we start writing code, we pull out a huge pieces of paper and label each one a file of the project (periodic tasks, teleop, ect.) and write out every task we want our program to do using words and arrows. This process reduces many headaches.

3. We had a piece of paper taped to the wall with "todays tasks" and what needed to be done/fixed. A whiteboard would work better.

4. DROPBOX SAVES LIVES

5. I dont know if you already use it but use DEBUG MODE on labview (run robot main). It saves many many many hours of compiling and deploying.

[connor.worley]

In my opinion, pair programming is a more effective use of people than splitting up the codebase into chunks. Honestly, our FRC projects are small enough that people can understand and work on the entirety of them.

[Butter's]

1. We split our members into there best area of interest. Some would rather do back-end, while some prefer doing autonomous.

2. Whiteboards & Paper are the best way to get ideas down & plan things out.

3. The best I can suggest is in the start, focus your time on preparation. Getting your laptop imaged, setting up the work environment, etc. Once your team knows how your going to approach the game, start planning how the team is going to tackle it from the code. After that you can't do much until you have a robot you can deploy too. If you have a lot of extra time, now is the chance to mess around with the old robot & refresh yourself with coding, api, etc

4. As suggested, Github is a great tool for storing your code / implementing version control. If your just making presentations or documents I'd go with Google Drive. It works the same as Dropbox, but has a great editor online to make Documents, Presentations, Spreadsheets, etc. It's all accessible online & via desktop (Once you download the application).

5. Try new things & experiment! This year I wanted to see if we could switch to Java. During the process I ran into a ton of issues, but I learned a ton from fixing them. Even if you don't end up using what you experiment with, it's always a fun new challenge, and can sometimes provide you with great knowledge you might need one day.

[BigJ]

Document your code, and write comments!

Everything is common sense now, but in 6 months when you're tweaking something or fixing a bug in a long untouched file, it's gibberish.

[~Cory~]

+1 GitHub

They are offering free professional hosting for robotics teams:

https://github.com/edu

[Andrew Schreiber]

I'm breaking this into two answers each, one we use in FRC and one we use at work.



1. How does your team effectively delegate the work between programmers? Do you have several programmers work on separate parts and then put them together or do you have everyone work on the same program?

FRC - we try to break it into logical groupings (usually by component) and then divide our team into groups that then pair program on the problem with the support of one mentor. We are fortunate to not only have a rather large programming team (looking at 12 students) but also having a fair number of mentors who, while not all terribly familiar with FRC are engineers.

Work - We tend to write user stories and then assign each story a developer. Where parts need to talk to each other we simply tell the developers that they must talk that out. We are also a highly distributed facility, last year I worked as part of a team that was spread out across most of the east coast as well as with another team with half the members in Colorado.


2. How do you plan the code before you start programming (flowcharts, etc.)?

FRC - Simple planning meeting wherein we discuss what the robot needs to be able to do and write the user stories.

Work - Actually, identical process just replace robot with whatever project we're working.


3. What kinds of benchmarks do you use to keep the programming team on task throughout build season?

FRC - Every meeting the student sub groups need to answer "what did you do, what are you going to do, and what are your blockers?"

Work - Similar process, we also tend to use tools such as Jira and Pivotal Tracker to track who is doing what.


4. What backup techniques does your team use to manage files effectively (cloud, etc.)?

FRC - SVN but we are in the process of switching to git.

Work - SVN/Git/HG and our in house servers for each of them. Each project has the choice to use whichever they want. I do not suggest this approach at all for companies. It works here for a couple reasons that are fairly unique to us. 1) we work in a huge variety of languages and problem spaces. 2) projects are prototypes with life spans measured in months to a year NOT in decades.


5. Other tips, tricks, or suggestions?

I'm a fairly big fan of taking sticky notes on the walls with tasks. Three columns; To Do, Doing, Done. When someone takes ownership of a task (they start it) you move it from To Do into Doing and write their name on it. They are responsible for that task. When they move it to Done they can grab another task. The benefits of this, each developer knows what they are supposed to be doing. Each one can instantly see what other's are working on. Each knows how much work is left. And they won't come to you with "ok, what do I do next"... well, they might, but now you have a convenient board to point them to. Obviously you can prioritize or color code this board as you see fit.


Build code as building blocks and test the crap out of your blocks.

Modularize where logical but don't over think it. Following great OOP principles is admirable but complexity is the enemy of reliability. It's better to have code that is logical, readable and clean.

Comment stuff. Heck, keep a wiki somewhere that has testing procedures for each sub system. When you go to competition make a checklist based off this wiki so you can perform the tests each time you make a code change. Make a second checklist that can be performed as a preflight check. Make sure these lists catch your edge cases (limits or motion for example).

Sleep on problems. When I spin my wheels at work on a problem for more than an hour if I'm not making progress I switch to something else and don't come back to it until the next day. Some days just aren't good days and I leave work early. Sometimes I just take a walk around outside or read a book for 15 minutes. Point is, staring at a problem won't make a good solution jump out at you.

Mountain Dew and Cheetos are NOT a valid dinner. If you insist on eating them constantly you better wash your hands because if everything ends up with a fine coating of Cheeto dust someone is going to be cleaning every surface with a toothbrush and it won't be me... (mentors, I suggest you keep a handful of old toothbrushes handy for 'cleaning detail').

[Alan Anderson]

Mountain Dew and Cheetos are NOT a valid dinner. If you insist on eating them constantly you better wash your hands because if everything ends up with a fine coating of Cheeto dust someone is going to be cleaning every surface with a toothbrush and it won't be me... (mentors, I suggest you keep a handful of old toothbrushes handy for 'cleaning detail').

http://wondermark.com/c/2010-03-05-601chopsticks.gif

[Andrew Schreiber]

http://wondermark.com/c/2010-03-05-601chopsticks.gif

THIS CHANGES EVERYTHING!

[BigJ]

I usually eat snacks with residue from a cup! Easier than chopsticks :)

[Woolly]

Mountain Dew and Cheetos are NOT a valid dinner. If you insist on eating them constantly you better wash your hands because if everything ends up with a fine coating of Cheeto dust someone is going to be cleaning every surface with a toothbrush and it won't be me... (mentors, I suggest you keep a handful of old toothbrushes handy for 'cleaning detail').

Hm... that's why most of my team sticks to cheez-its.

On a more serious note, with the recent expansion of our programming team, we're going to have to move to actual program team management rather than 3 guys keeping each-other in the loop.
So yeah, we're looking to go to some sort of SVN or git Version Control. One issue we've come up upon is that many version control systems aren't exactly designed for a graphical programming language such as Labview. We're kind of looking at running Tortoise SVN and hosting our code on Google code, though if git-hub has a better password system than Google code and isn't blocked by our school's overprotective firewall, I'd be willing to switch in a heartbeat.
We're also working on/ironing out some naming and documentation standards for our team. Just something to keep from having confusion come up later, such as the classic "What is Math.vi?".

Being on a team going through the same kind of growing pains (3 programmers last year to 10 this year), these are a lot of the same questions we've been asking ourselves, and I am very curious about what other teams are going to say. Thanks to those who've already been responding, we're definitely taking your thoughts into consideration as we prepare for the upcoming season.

[Andrew Schreiber]

Hm... that's why most of my team sticks to cheez-its.

On a more serious note, with the recent expansion of our programming team, we're going to have to move to actual program team management rather than 3 guys keeping each-other in the loop.
So yeah, we're looking to go to some sort of SVN or git Version Control. One issue we've come up upon is that many version control systems aren't exactly designed for a graphical programming language such as Labview. We're kind of looking at running Tortise SVN and hosting our code on Google code, though if git-hub has a better password system than Google code and isn't blocked by our school's overprotective firewall, I'd be willing to switch in a heartbeat.
We're also working on/ironing out some naming and documentation standards for our team. Just something to keep from having confusion come up later, such as the classic "What is Math.vi?".

Being on a time going through the same kind of growing pains (3 programmers last year to 10 this year), these are a lot of the same questions we've been asking ourselves, and I am very curious about what other teams are going to say. Thanks to those who've already been responding, we're definitely taking your thoughts into consideration as we prepare for the upcoming season.

While operating in an environment you may not have internet access I suggest git as the version control system. It is distributed which means you can utilize it without access to the server. I suggest reading up on it.

[F22Rapture]

While operating in an environment you may not have internet access I suggest git as the version control system. It is distributed which means you can utilize it without access to the server. I suggest reading up on it.

I second this motion.

There's also been some work done to get git and github to play nicely with LabView: http://www.youtube.com/watch?v=2dEI6tEMTmQ

[mythbusterma]

Best advice if you're going to be working in a team of people programming is to comment comment comment.

//like this
/* Or maybe
even like this
*/

Just because your code might make sense to you now, it probably won't later. Then imagine how someone else feels reading your code. Then imagine how a noob feels reading your code (hint: bad).

Also, I have used git in the past and have had no problems and only success with it, if you're looking for a closed source alternative to GitHub, you can try Assembla, the site I personally use.

http://www.assembla.com

[Golto]

I remember that we had a huge whiteboard that we would "pseudo-code" on before writing it to the bot, we made sure that we had photos, so not only did we have comments in the code, we had reference of the creative process that went into it.

[Ether]

Food for thought: Software Design by Contract

http://www.cs.ucsb.edu/~bultan/courses/272-F08/lectures/Contract.ppt

http://cs.olemiss.edu/~hcc/papers/sesec02final.pdf

http://en.wikipedia.org/wiki/Design_by_contract

[Hugh Meyer]

We use Subversion. It works great! Here is a link to a workshop I have done explaining how to setup a SVN server. You don't need a super computer. Just about any old machine will work.

http://rar.meyermat.net/workshops/index.html

Attached is a document that explains how to use LabVIEW with TortoiseSVN.

-Hugh

[holygrail]

Thanks to all of you who have posted so far, we have already started putting some of these recommendations into place. I'm also interested in finding out how other teams manage their programming groups especially during the early parts of build season when they don't have a new robot to work on yet. They are working on a test board now with several different sensors and the Kinect to practice with. Any other ideas about how to keep them away from the video games and focused would be appreciated as well. Again, thanks for everything so far. Good stuff!

Side note: chopsticks worked well with cheetos, a little tougher with hot wings though. Gotta work on that.

[Woolly]

Thanks to all of you who have posted so far, we have already started putting some of these recommendations into place. I'm also interested in finding out how other teams manage their programming groups especially during the early parts of build season when they don't have a new robot to work on yet. They are working on a test board now with several different sensors and the Kinect to practice with. Any other ideas about how to keep them away from the video games and focused would be appreciated as well. Again, thanks for everything so far. Good stuff!

Side note: chopsticks worked well with cheetos, a little tougher with hot wings though. Gotta work on that.
Butter's said some great things about preparation, which is a good morning/afternoon of day 1 activity.
At the moment we plan to have our programmers work with our design team for the first couple of days, just to make sure they know what sensors we need and where so they can incorporate it into the design and not be added in via duct tape and string at week 4. At least in my experience, fabrication, electronics, and design has a skewed view on what programming can do, so by being there you could potentially stop them from going forward with something that will be incredibly difficult to get to work, but also get some ideas out they wouldn't think of otherwise. Also, logical proof-of-concept VIs are a great thing not only for documentation for the design process, but usually can also be dropped right in the robot code later if the team decides to go that route.
Not to mention, in the early days you can usually work on basic drive code for both teleop and kinect hybrid, and maybe even test it if you happen to have an older robot with the same style of drive-train you plan to use.

Oh, and I think tongs would work well with hot wings, especially if you can somehow lock them down like a pair of vice-grips.
Note to self: Hot wing vice-grip tongs. Get on that, along with the nachobot.

[wireties]

Mountain Dew for the students, coffee for the mentors! Add a white board and you are in business.

Well, I reckon it takes a little more than that. We put a lot of time into the design stage using basic flow-charting and message sequence diagrams. Our robot firmware is multi-tasking using the VxWorks message libraries to communicate between tasks. This makes it easier to separate the design and the work into isolated efforts (drive, arm, wrist, claw, camera, ds comms, autonomous, etc) with defined interfaces (the messages) to the rest of the system.

HTH

[stingray27]

Thanks to all of you who have posted so far, we have already started putting some of these recommendations into place. I'm also interested in finding out how other teams manage their programming groups especially during the early parts of build season when they don't have a new robot to work on yet. They are working on a test board now with several different sensors and the Kinect to practice with. Any other ideas about how to keep them away from the video games and focused would be appreciated as well. Again, thanks for everything so far. Good stuff!

Side note: chopsticks worked well with cheetos, a little tougher with hot wings though. Gotta work on that.

Make sure all of the programmers know the electrical side as well!! This is extremely important. We are taking the time now to have our programmers learn all the electrical components because they need to know the system that they are programming before they can program it. Our programmers are literally going through the same training as the electrical students.

[Gdeaver]

Our programming team has more than a few programmers. As soon as there are more than 2 programmers project management system becomes critical in the tight First schedule. After a near disaster in 2010. Our lead programming mentor implemented the Agile development methods. I definitely saw an improvement in product development and delivery. Our programmers are a scrumin. For 2012 I tried to apply the scum method to the mechanical build. Started out OK but as the pressure mounted things kind of broke down. I'm mostly at fault. So far I have not been a very good task master. It's one of the things that is at the back of my mind all the time. What went wrong, how did it get off track, what do I need to do different this year. How I communicate to the students Is my main focus. Effective communication is my main goal. The students rated my performance last year. One of our college student mentors did it. I'm trying to roll their evaluation forward. Every First team should implement some form of project management style. What works for one team may not work for another but, each team needs to develop their own system.