View Single Post
  Spotlight this post!  
Unread 09-09-2016, 16:16
gblake's Avatar
gblake gblake is offline
6th Gear Developer; Mentor
AKA: Blake Ross
no team (6th Gear)
Team Role: Mentor
 
Join Date: May 2006
Rookie Year: 2006
Location: Virginia
Posts: 1,933
gblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond repute
Re: paper: Stop the Stop Build - Counterpoint

I like what you have written, but I personally would have finished with a differnt, perhaps more sharply contrasting counterpoint.

The on-the-field performance of teams/robots is not the central focus of the FRC program described on FIRST's website, nor is it the thread tying together the many descriptions offered by FRC's founders and current leaders. However, in the day-to-day operation of many FRC teams, and in the minds of many participants, on-the-field performance becomes the tail that wags the dog. With that in mind, and wanting to reduce the amount of dog-wagging done by that tail ...

A) I believe that having (recreating?) an actual 45-day build season would be (restore?) an excellent part of the foundation of wise compromises that FRC rests upon. FRC should push in this direction.

B) I think that the the on-the-field performance exhibited by the teams that are already doing well (in that part of FIRST), is good enough. I don't mean to say that better performance would be harmful; but if I'm right, I do mean that across the globe, for the teams that aren't struggling, improving the on-the-field part of FRC should not be pulling time, attention, and other resources away from the other parts of FRC.

Now, to get to the heart of it:

For the teams that are not doing well, and are consequently exhibiting the trouble-on-the-field symptom, giving them an 8 hour out-of-bag period each week (or not) seems to be a relatively small item a big picture. I think that properly preparing them to make good use of their 45 days will make the 8 hours unnecessary (the extra time won't hurt, but it won't be *necessary*). If a team makes good use of those first 45 days, they will be ready to do well enough when they roll into their first event. If instead they are currently using the 45 days poorly, it seems intuitive to me to expect that after a year-or-two transition they will be using added 8-hour windows poorly too.

So ... Please don't let a post-stop-build-day weekly unbag period rise to the top of the list of ways to assist struggling teams. Instead let's focus on helping them with project management, and everything that is tied to that subject; along with helping them with the soft skills of recruiting students and mentors, finding funding, having effective meetings, etc.

I know the original paper's author isn't focused so strongly on the 8-hour unbag topic that he is ignoring other ways to help struggling teams. I also know he is part of a large, deeply-caring and highly-motivated FiM team that wants all students to succeed.

But, reading this paper, a reader can get the impression that the OPR tail ought to (and will) wag the FRC dog. Instead I think OPRs and similar symptoms/metrics won't change for the long haul until the dogs are healthy. A few unbagging periods will help a little, but still won't make the dogs healthy. The root causes for struggling will still be there.

Given my beliefs, I'm personally led to believe FRC shouldn't be churning its ranks with debates about ways to extend/expand build seasons. There are much more important fish to fry.

Sure, ask permission to try a handful of small well-designed unbag experiments, but worry about them only after getting permission to carry out pre-build-season experiments that will attack likely root causes, before attacking what is likely to be only a symptom. If that is what is already happening, the paper does itself a disservice by not mentioning building on or amplifying those efforts.

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
Reply With Quote