Software team organization


I’m Ian (nice to meet you!) and this year has been my first as 2342’s software lead. This year our team, especially code, had a massive proportion of new students due to the majority of our experienced students graduating, which left me with a subteam (at the start of preseason) of about 15 new students of various skill levels and experience and 2-3 returning including myself. Naturally this made it really hard to keep everyone engaged throughout build season due to two things: a lack of individual coding projects that got us closer to bag, and the fact that what we did have to do required a lot of prerequisite knowledge. In the end, we ended up losing more kids during preseason than I would have liked, and only a core 4 or 5 new students really ended up in “the swing of things” by the end of build season.

So, with build season winding down, I was interested to hear if any other large teams had suggestions on how to keep such a large group, particularly of new students, more engaged on software. Sorry for the long post, and good luck to everyone with week 1 comps :wink:

-Ian C

Without things to learn and things to do, you will not retain your members. So the solution is to make sure you have learning, and work.

First on the work front, there is more than just the robot itself.

  1. Website. If you want to do programming on a website, don’t just setup a Wordpress site, get a VPS (Virtual Private Server. Digital Ocean is a great place to get a more than adequate one for between $5-$15/mo) and then write the website from scratch in the language of your choice. PHP, Javascript with Node.js and express, Python with Django or Flask, Java with JSP or Tomcat, Ruby with Ruby on Rails, and many other options.

  2. Vision. Even if you run your vision on the RoboRIO, its practically a project on its own, and so having members dedicated to it, is very useful. Vision is useful to varying degrees every year, but most years there is at least something you can gain from it. On top of that is the option for co-processors such as the Raspberry Pi to offload the vision processing, and opening new options.

  3. Process Automation. Applications can be made to automate process for teams. One example we had on 3946 at one point (never came to fruition, but it was a good idea) was digital attendance keeping. We wanted to have a scanner and computer where students could scan their student ID (or enter id manually) and it would update in a Database that they were present at the meeting. The technology and language options for this are only limited by the scope of the problem, available resources, and your imagination.

Also important is making sure the work is split up well. When it comes to the robot, this can be difficult in if some members better understand the code than others, resulting in those members handling all the work. This is also more difficult in LabVIEW compared to the other languages as Merging VIs is more difficult than with tools such as Git.

On the learning front, it is two-fold.
First, you must have facilities to be able to teach concepts, be it to everyone in a classroom-esk setting, or purely individually. It is important, particularly for those who are new to programming, to be able to get some help from other members, either on there level to help research and figure it out, or with guidance from a more experienced member or mentor.
Secondly, the members must be ready not only to learn, but to teach themselves. Having others to show them tips, tricks, or help them logic through a problem, is awesome, and having someone to walk through the process of how the robot functions and how to tackle development is better than not having it, but if that member isn’t going to be willing to go on their own and learn the language and the libraries, then they typically aren’t going to stick around in programming. I provide a resource document (for Java) to every team I mentor, showing where to go to tutorials, documentation, and such. It becomes very clear, pretty quickly, who is using those resources, and who is not. Typically because those who are using them ask me questions, not the other way around. Naturally, you don’t want to lose members, but in my experience, those who aren’t helping themselves, typically don’t stick around. So more so than showing your members the ropes, show them the resources available to them to learn at their own pace.

I noticed that your team is also programming in Java this year, so here is my resource document from this year if you’d like to look it over: Java Resources - Google Docs

I realize this may not be the type of answer you were looking for, but I hope it can help.