On the quality and complexity of software within FRC

[Ari423]

Limited robot access: It is inherently difficult to develop software for a machine that isn't built yet...

Time limitation: six weeks is a really short timeframe for software...

What I find helps is writing the code before the robot is built. Sure you end up modifying or deleting most of it, but taking the time to make things looks nice while you are waiting for the robot to be ready to be tested gives you the standard for the modifications you make to your code. Also, thinking about all of the different possibilities for a general idea opens your mind to new ideas the mechanical team hadn't thought of.

Not enough manpower: I think that many teams have only a single programmer. If so, it is not trivial for one person without any support to learn and apply everything that goes into buiilding a good project.

Not enough support: I also wouldn't be surprised if many teams had no dedicated software mentors.

I understand about what people are saying about only having one programmer and no programming mentors, but I am in that situation as well and I still am able to make efficient and well-formatted code. I think what is important is having someone else's clean code to look up to. The programmer before me left me his old code. While some of it was dirty, most of the competition code was neat and easy to understand, even without comments. Perhaps it's because he was an artist as well, but I really appreciated the time he took to make the code look nice (which helped debugging and such because you knew instantly what you were looking at).

Not enough incentive for good software: aside from innovation in controls, there is very little incentive for medium or low performing teams to put a lot of resources into their code....The roboRIO is more than fast enough for pretty much everybody, and with the CAN Talons, the vast majority of functionality is achieved by very simple code.

While I agree that there isn't much incentive in FIRST, I feel that programmers should strive for more than functionality. When you leave FIRST and go to get a job, your employers will want other programmers to be able to understand your code, and bad practices and dirty code don't help with this. When your code is clean it makes updating it and advancing it much easier.

Most teams' programmers get the robot really late in the season--and most teams' programmers are then trying to get the robot running under pressure from mechanical who wants drive time. Ugly code that works is of far, far greater value to the team than really nice, standards-compliant, reusable year-after-year code.

This, again, is where making code before you get the robot helps. You will need to rewrite stuff, but it's less work than writing the entire code from scratch.

To many, FIRST is an engineering competition. Teams must engineer a solution to a problem in a limited amount of time, just like real engineers do in the "real world". There is a finite amount of time to optimize an infinite number of things, so engineers must make tradeoffs.

I agree with what you are saying; there is a point where code can become over-developed. But there are some practices that take no extra time, but make the code more efficient and easier to read. And if it doesn't work the first time, it makes it easier for the programmer or someone helping to debug. Learning good coding practices in the off-season can greatly help during the build season.

It's an engineering competition, where we are making a robot that scores points. When code efficiency scores teams points, you'll see a lot of teams start making efficient code.

Even though optimized code doesn't score you points, it does make getting to the point where you can score points and debugging when you can't score points easier. It takes less time to copy to the robot and a well-formatted dashboard can help you debug the robot mid-match and save yourself half a match (which we needed to do and we able to thanks to our dashboard).