The 6 Week Build Season and 'Mentor Burnout'

[EricH]

Originally Posted by Nemo

My responses to some of the arguments favoring bag and tag deadlines:

If we eliminate bag and tag, some teams will work the same insane schedule for 3-4 months instead of just for 6 weeks, and other teams will be forced to follow suit in order to stay competitive.

Some teams already put in insane hours between bag and season's end. If your team doesn't match that number of hours, you've already proven that this argument is false.

I disagree. The key words that you appear to have overlooked are "to stay competitive". If a team does not match that number of hours, and is still competitive, then yes, that is false. But if the team in question is NOT competitive, then I would consider it at best a "no-contributor" to the argument--that is, it's not doing anything to show whether it is true or false.

Work expands to fill the available time.

The available time is already 3-4 months long. We can always work on 30 lbs of fabricated items, and that is typically enough weight to create multiple complete robot subsystems. That time is available to all teams, whether they currently take advantage of it or not.

And darned if teams don't take advantage of it to the max, at least the ones that want to stay competitive do. Again, it's those words: To Stay Competitive. Low-resource, high-resource, doesn't matter--teams with any amount of resources that want to stay competitive ARE using EVERY POSSIBLE DAY they can work. Why? Because they know that if they don't, someone else will, and they'll lose.

Now expand that to an official, with-robot, 4 months. If they aren't building, they'll be doing drive practice.

We would not be able to prevent ourselves from working lots of extra hours and burning out.

That is not a good reason to place limits on other teams. Your team needs to sit down and figure out a reasonable schedule and stick to it. That brings me to the concept of the "build sprint."

Ahem... I would like to point out that most teams do figure out a reasonable schedule. Then at about Week 4, somebody looks at the calendar, realizes that they're behind even where they wanted to be, which is probably behind period, and goes pedal to the metal. (I know you were competitive this year--but did you stick to a reasonable schedule?)

Build Sprint

Why does FRC have to be a sprint? Why can't it be something that we do at a slightly slower pace over a longer time period? It's an embedded tradition to have a "build sprint", but why does it have to be that way? Are you going to argue that all projects that one would work on in industry are sprints? They're not.

The sprint concept is one of the reasons people are afraid of an open build season. Some people can't imagine scheduling an FRC build season in any way other than letting it fill all available time slots for the entire period during which we're allowed to work. If the season is short enough, we can get away with that. [...]

If we had a 3-4 month build season, I think it would be easier to recognize that we can't simply meet during every possible time slot. It would force us to answer the question of "how much of my life does it make sense to dedicate to this team?" In a 6 week season, it's easier to cheat your way out of that question by simply assuming that you have to work during all possible times since the timeline is so severely limited.

Nice theory. For some folks, I think the answer would end up being "Oh, I don't have anything important from X to Y dates, so I can show up all those sessions", "hey, I have something on Z, but other than that I'm free", and I think it would probably end up being a meeting during--maybe not every, but almost every time slot. However, I think what would also happen is that there might be some "rolling" or "staggered" days, such that crew A is in on certain days, while crew B is in on other days, or "Oh, yeah, we're not doing much on X day, so go ahead and take the day off".

Oh, right: FIRST also mimics a real-world experience. Let's go with I haven't had a build sprint per se at work yet, but other groups have been doing them--it's just a matter of who it is this time.

Get rid of the 30 lb allowance so the build season really is only 6 weeks long.

True, this would make it more difficult to do robot work after bag day than it currently is. Right now it's pretty attainable for a lot of teams to improve the robot after bag day. With this limitation it would be harder. But we'd have less competitive, less inspiring robots. I've said this before - the extra time it takes to get a machine to actually work is really valuable. Quitting at the point when it almost works really sucks a lot of the power out of this endeavor. How many FRC robots have you seen that almost work? I've seen a lot.

I don't think anybody's actually proposed this. I think it's been proposed to trim it down, but not remove it entirely.

I also don't agree on the "less inspiring" part. Sometimes, the best inspiration comes when you've duct-taped parts that weren't necessarily meant to work together into something that works. Apollo 13's filters, for example. "We need to fit this into this, and this is what we have to do it with." Some pre-planning required for at-competition assembly of any improvements, of course--but any team that is able to stick to a reasonable schedule (and most of the ones that don't) and remain competitive should be able to do that no problem.

Keep the bag deadline, but add limited robot access periods after bag day. This creates a compromise that allows mentors to have a break.

I could live with this, and it would be an improvement over the current rules. That said, why does this break have to be enforced through the FRC rules? Would you advocate forcing teams to take at least 1 or 2 days off per week for the purpose of preventing burnout? If not, how is that different than forcing us to stop working after 6 weeks?

I don't think we're aiming to force teams to take days off. I think it's more about allowing them to use their competition robot for development--within reasonable limitations, such as a certain amount of time per week--so that they don't have to build a practice robot, which, at least in theory, will allow them to use less time and still remain competitive. Of course, there's no restriction on how you use time outside of any such open bag windows.

In many ways, FIRST and the community have embraced the concept that different teams run themselves in their own ways according to what works best for them. Why not extend this to the schedule? Some teams might be better off spreading it out over a longer period, working less severe hours in a given week. Some teams might be better off loading it more heavily in February and March. And so on. I see nothing wrong with that sort of flexibility. Lack of ability to schedule realistically on the part of some teams is not a good reason to limit flexibility for other teams.

FIRST is a mirror of real life. If June 7, 2050 is the best day for a Mars launch, and NASA is sending something there, they want the hardware on the rocket, upright, and ready to launch on or before June 7, 2050. Not a day later. Preferably a day or 30 earlier. If you are building the payload for that rocket, there are going to be deadlines--you really don't want to miss those. There is going to be a fixed amount of time--it might not be 6 weeks, but there are a limited number of man-hours that can be put into the project between the contract award date and the launch date. And you better make that deadline.