Team 254 Presents: FRC 2016 Code

[Jared Russell]

Originally Posted by Turing'sEgo

This is an extremely large project in the scope of FRC (but excellently done). How does the team handle development? Do you follow a development methodology? I assume you have multiple students working on various parts at the same time, how does version control work? Check out with merge requests?

Non-sequitur question: Where do you programmers ultimately end up beyond frc? Year after year quality code is released (and has been since at least 2011), and the knowledge your graduated programmers must have is well beyond that of your typical freshman cs student.

It's pretty informal. We all worked on our various pieces and commit to head/email patches as we go (occasionally there's a long-running branch, but we try to avoid that). Typically in the lab or at competition, we had one person on a laptop and push all of the changes at the end of the night (and we take another computer and find a quiet spot to iron out a problem in parallel if it takes more time, then merge). We did occasionally have build breakages or regressions (most of our students are new to git) but nothing that was ever particularly impossible to iron out.

I can't really answer the second question very well - I have only worked with the team for 3 years so all of the programmers are either still on the team or in college. Perhaps someone else can speak to history before that. More generally, I can speak to the team's approach to programming the robot for the last 3 years. Programming an entire 254 robot to the level of performance the team demands is a challenge for experienced software engineers, let alone high school students (and on our team at least, it seems that the more capable and brilliant the student, the more other demands are made on their time by school, the team, or other activities). We try to divvy up tasks among the team based on interest, ability, and time commitment; both students and mentors make direct contributions to the code.

For younger students, it is expected that by and large their job is to learn, be self-starting/pursue additional learning opportunities, and make small contributions as they are able. The more experienced students should take ownership (or at least, co-ownership with a mentor) over some area of the code. For example, in 2014 we had a student (now in college) take ownership over our autonomous spline-following routine (deriving all the math and peer-programming the implementation with me). He definitely graduated high school knowing more about robot navigation than most college graduates. Similarly, a student last year made great contributions to our vision algorithm; he now knows more about computer vision than most college students.

Most of the programming students from last year are returning this season (and some of the mentors are stepping aside), so I'm looking forward to seeing what they do next year!