FRC Blogged - Frank Answers Fridays: August 30, 2013

[billylo]

In support of releasing software kit sooner. Here are my reasoning.

1. Game specific examples/sample codes is a very small part of the entire development kits. It can be released during kickoff with relative ease.

2. Doing it prior to kickoff enables FIRST to spread out the network bandwidth demand, making it easier for teams to get the manuals and rules efficiently. Thousands of big downloads can really slow things down.

3. 'Leaking' a little bit of the game is actually good for generating excitement and fun.

I hope FIRST would consider this.

[sanddrag]

As the lead teacher and manager of IT resources in our engineering labs, installing the software after kickoff is a nightmare for me, and I can't imagine how difficult it must be elsewhere. FIRST needs to realize that teams are working in shared school labs where students and even sometimes teachers do not have software install privileges. In school districts such as ours, getting district tech personnel out on a work order to install software can sometimes take months. We don't need to deal with this in January. Please give us the software in November.

[Tom Line]

I would disagree with a more wide-spread Beta Test.

The coding team that works for FIRST is fairly small. Even with the current Beta-Testing setup, the FIRST volunteers have a ton of data and questions flowing back toward them: far more than they can handle in many cases. In addition we (the beta testers) tend to stay in touch with them, not just during the beta testing period, but year round.

Opening Beta Testing to all teams would create a flood of complaints and bug reports. Many of which would be false, due to inexperience or incorrect expectations. It would overwhelm the FIRST volunteers quite quickly. Quanity is not quality.

True Beta Testing is quite rigorous. We meet 3-4 times a week for 3-4 hours each meeting. Usually we recode for our last 3-4 robots in the new environment and test. Biweekly webpage updates, community updats, and seminars follow.

By having a limited number of teams who have programming expertise learn the software early, you've easily tripled the number of people who can provide knowledgable, correct answers to questions.

I believe the frustration level on the team side would be much higher if they received software that didn't work as they expected it to. People tend to be negative when things don't work. Multiply that by a couple thousand.

HOWEVER. I'd wager that FIRST and their volunteers don't work on this stuff through kickoff and New-Years. I like the idea of the base development environments like LabView being sent out pre-holiday so that we can install the main portions of them before kickoff. Then they could release the updates like they normally do for us to download.

[SoftwareBug2.0]

How about a much lower bar: make it so that the software that's available at kickoff is legal to compete with.

[wilsonmw04]

Originally Posted by SoftwareBug2.0

How about a much lower bar: make it so that the software that's available at kickoff is legal to compete with.

That will never happen. You really won't know what product they have delivered until it gets in the hands of all the teams and they try to apply it to the game that year.

[SoftwareBug2.0]

Originally Posted by wilsonmw04

That will never happen. You really won't know what product they have delivered until it gets in the hands of all the teams and they try to apply it to the game that year.

It might never happen, but not because it is hard. It would require a different design philosophy: Correctness over features.

The mandatory part of the code should be as minimal as possible, and anything that is merely a convenience should be optional. This would cut down on both the size and number of mandatory updates.

Then, updates to the core could be mandatory while updates to any optional part could be applied at a team's leisure, allowing for a proper testing cycle.

[apalrd]

I agree with the correctness over features logic.

Why do we even have updates, with the thread of not being able to connect to the field or stuff like that, after 5 years with this control system? Haven't they ironed out all of the field comm bugs yet?

[Greg McKaskle]

"after five years ..."

Good question. The reality is that some portion of the system changes each season. Bridges are discontinued, manufacturers release firmware updates which they highly recommend using. The Einstein problems meant that many weeks were spent identifying what could have happened, investigating what probably happened, and confirming what did happen. Because of what occurred, radio configurations changed, antennas changed, DS had new responsibilities, logging was enhanced, etc.

And yes, features were added as well. NI had postponed releasing simulation for several years already and we decided to squeeze it in. SmartDashboard/NetworkTables had some issues that needed to be resolved from the previous year, so it was reworked for each language.

I've released SW with large betas and small ones. There are benefits to each approach. I'm not sure how much this really impacts the policy in the original question.

Greg McKaskle