|
Re: On the quality and complexity of software within FRC
OP wanted to raise the bar for the FRC software quality.
What are some ways to do that without being too preachy (and without getting dragged into the weeds by topics like what-is-the-the-one-true-code-formatting-style, or the-one-true-way-to-use-a-Hungarian-naming-convention?
Publish some reference designs (several... the number of good ways to do things will be legion) that guide students, and lead them to ask good questions about details, but that don't hand them answers on a silver platter? Students are given physical kit-bot parts. Maybe the kit-bot BOM should include some software parts they can put together to form a basic FRC software system (does this already exist?)?
Perhaps put a few good examples of software requirements specifications in the Kit of Parts?
Create simulators (that expose the appropriate APIs) that students can use when their own team's real equipment is unavailable, or during off-season practice sessions, thereby giving them more development time during build season, and more practice time before build season?
Something else?
Blake
__________________
Blake Ross, For emailing me, in the verizon.net domain, I am blake
VRC Team Mentor, FTC volunteer, 5th Gear Developer, Husband, Father, Triangle Fraternity Alumnus (ky 76), U Ky BSEE, Tau Beta Pi, Eta Kappa Nu, Kentucky Colonel
Words/phrases  I avoid: basis, mitigate, leveraging, transitioning, impact (instead of affect/effect), facilitate, programmatic, problematic, issue (instead of problem), latency (instead of delay), dependency (instead of prerequisite), connectivity, usage & utilize (instead of use), downed, functionality, functional, power on, descore, alumni (instead of alumnus/alumna), the enterprise, methodology, nomenclature, form factor (instead of size or shape), competency, modality, provided(with), provision(ing), irregardless/irrespective, signage, colorized, pulsating, ideate
Last edited by gblake : 17-06-2015 at 00:44.
|