Mythical Six Week Build Season

[Mark Sheridan]

Originally Posted by EricH

A proposal: All robots MUST bag at the 6 week mark. Teams are expected to enforce a tools-down policy--this includes practice robots and software development.

Just to nitpick this. some students on my team delay their participation in week 6 so they are rested and ready to dive in with the practice bot after bag day. Its also a good time for peer review of code, to clean up while week 6 is still fresh in your mind.

I personally don't like the concept of bag day but I do think it provides closure for my team and permits them get needed rest. There are those like me, who are too excited and immediately want to play with the practice bot.

However we did get very burned out this year, we asked ourselves almost everyday if we would be more upset if we did not give our best. We gave up on the can war to keep our sanity.

[AllenGregoryIV]

Originally Posted by Jared Russell

...and because the scoring mechanic underlying both minibot racing and can grabbing was a winner-take-all, asymptotic race to the bottom.

I think this is the key point, my statement about not ruining things was meant to be more about the watch ability of robots and diversity. Those game mechanics were unquestionably broken.

[Jared Russell]

I just want to point out (again, as is annual tradition) that those who go "tools down" on "stop build day" are already making a choice. Don't pretend that you're not.

The only barriers to continuing to iterate on your robot legally are (a) the expense and extra work of building a practice robot (a few thousand dollars and many person-hours, which is significant), (b) fitting your post-bag modifications into your withholding allowance (which IMO has not been a problematic constraint in recent years), and (c) the feasibility of transporting your modifications to your next event (which is an issue, albeit a big one, for a small number of teams like my international and Hawaiian friends).

What tenable arguments could there possibly be for keeping the stop build day?

Fairness? Totally out the window. In fact, there are artificial obstacles to continuing to work that make it harder for a low-budget, low-hour team to keep up.

Preventing duplication of successful designs? (a) Copying happens to some extent already, but (b) it will never happen to the same extent as in Vex and FTC because it is much more difficult and nuanced to copy and perfect something in FRC. Moreover, I think that games that converge to a single optimal solution are fundamentally not very good games.

Saving us from ourselves? I sympathize with this and know all-too-well about burnout, but still don't think it's a convincing argument. Again, you are already making a choice and are more than welcome to continue to do so if build season rules are relaxed. For every "in the real world there are hard deadlines" point, there is a "in the real world, nobody keeps you from working yourself to death" counterpoint. I work at one of the most competitive companies in the world, and see at least as much value in the latter lesson as in the former.

Preventing escalation of the competitive arms race? This is already present to some extent, but every single year there are tons of examples of teams that succeed despite a disciplined approach to build hours. Look at 67 in any year - they are the prototypical example that proves that a team doesn't need to spend 80 hours per week in their lab to build a world-class robot. I actually think that removing the stop build day would remove barriers to competition rather than add to them.

[PayneTrain]

Since I have obviously never been in a situation where my team has developed something everyone wants to copy, maybe it can be explained by someone with that experience. Why do you think the potential for increased design convergence is a bad thing? As far as I can see, design convergence has a net positive for both teams off the field and the on-field product.

The only defense I have seen is anecdotal evidence to where design convergence already exists in the current environment only where conditions can easily present itself (a lightweight, simple and potentially even fully COTS solution to an over-weighted game mechanic).

[FTC5110]

Originally Posted by Lil' Lavery

I would love to hear the perspectives of FTC and VRC teams on this line of thought. They have an even larger competition window and much more affordable robots, making strategies like this even more feasible.

Originally Posted by Karthik

This is very common in VRC. By the time we get to VEX Worlds in April, design convergence has usually set in, with 2-3 designs that have been extensively cloned/copied. Some teams really like this, others really don't.

In VRC it becomes very difficult for teams to design something unique and innovative yet still remain competitive because of the design convergence. Although it's fun seeing a design so good teams attempt to duplicate (sometime almost screw for screw) the downside is having them on the other side of the field and your team loses the match. The single worst part is knowing you'll probably do worse arriving at a competition with something innovative versus just following the convergence crowd.

FTC is a different story because materials are less constrained giving teams more scope to build innovative robots that can't easily be copied without someone doing all the engineering again. You can actually make something different and win. Design concepts do converge somewhat by the FTC world championship but implementation is always different and this often determines match outcomes.

Time limits? Our team participates in both VRC and FTC with the later usually constrained to about 8 weeks of actual build work followed by perhaps 4 weeks of fine tuning. Wouldn't want the season any longer to be honest. VRC being a full 12 month season actually gets boring and we usually have a little fun in the first few months then just sit back and observe trying hard to figure out something innovative that will be a match for the convergence crowd.

[waialua359]

Originally Posted by Jared Russell

Preventing escalation of the competitive arms race? This is already present to some extent, but every single year there are tons of examples of teams that succeed despite a disciplined approach to build hours. Look at 67 in any year - they are the prototypical example that proves that a team doesn't need to spend 80 hours per week in their lab to build a world-class robot. I actually think that removing the stop build day would remove barriers to competition rather than add to them.

"world-class" robot with world-class engineers.

[Basel A]

Removing stop build day would be tremendously helpful to my team and others like us. We're a mid-level team, maybe the 50th to 60th best team in Michigan. Building a practise robot is both a significant financial burden and a significant temporal burden. A few $k can go a long way (an extra event, new tools/equipment, extra stock/components/motors). As for time, building a practise robot takes enough time to hurt the quality of our robot at our first competition. Over the course of the competition season, the practise bot makes up the ground, but not having to build one at all would immediately make our robots better.

I'm honestly not sure which teams making this change would hurt. I suppose it would narrow the gap between the teams who have to struggle to make/use a practise robot vs. those that do it pretty easily. But those teams aren't the type to shy away from competition.

[Al Skierkiewicz]

I have to start off with a nod to Dave Lavery. Go check out his "six weeks" speech from Championships. I think that speaks volumes about our motivation.
While there are likely equal reasons for both views, I personally have some other reasons to keep the six week build.
One of the greatest things that grabs casual observers and potential sponsors is the statement that every robot on the field was built in six weeks or at competition. The additional development time is never discussed because, for those people, it is irrelevant. The memory trigger is watching any robot on the field with the thought that it was the result of a team approach to a six week build and design.
While students are constantly under a time constraint for projects in their academic life, very few schools actually teach techniques on how to best accomplish great results in a limited amount of time. The six wek build does that with mentor help.
I have been around long enough to know that the best built robot is not going to win just because the team has a lot of resources or time. Likewise the best design is not going to win every time because there are other factors like driver fatigue, mechanical breakdowns, and miscommunications.
Yes, we are one of those teams that builds a practice robot. Yes, we continue to improve designs after the build. No, we are not a team that has a lot of resources. Yes, we are a team of very driven students who feel a need to make improvements, assist other teams and play a part in improving the overall competition. One of the things that has not entered into this discussion is the value of the additional learning experience in planning the robot modification that can only take place a competition. We always talk about how we are training our students for a life in industry. Well, no industry sits back and does not make improvements to it's product. Many of them need to plan on improvements in the field. (Hubble to name just one.)
So for my money, I am all for keeping the six week build. I don't think we could attract as many sponsors and supporters without it. I don't think we can provide a quality, real world, experience without it. I don't think the competition will improve without it. (I suspect it actually may suffer.)
On a personal note, I often surprise my coworkers with the solutions and direction on projects we are given. I attribute that with my work on the team. If you think six weeks is not enough time, you need to work in live TV. By the time you have realized you screwed up, your work is on it's way to Mars.

[GKrotkov]

I had heard of this proposal before, and hadn't thought about it much beyond a knee-jerk reaction of something along the lines: "Oh, hell no! Don't take my bag day away!" So when this thread popped up, and I saw some folks I respect a lot arguing the other way, I figured that it'd be better for me to actually think about it, talk to some students on 1712, and come out with an opinion I felt I could defend. I can say confidently that my answer (and the answer of a lot of students on 1712) is still: "don't remove bag day." The main reasons for that (burnout and time limits) have already been covered in this thread, but I'd like to throw a personal example into the ring. Feel free to nitpick or criticize, I promise you that I won't be offended.

Bag day absolutely helps keep FRC viable for me. When I joined the team, I mainly characterized myself as a musician and performer, and they are still major factors in my life. For the 2 years I've been in FRC, I've always pushed the envelope as regards time management: it's difficult for me to maintain the grades that I require of myself, be a strong part of 1712, and keep music in my life. During build season, other parts of my life get pushed to the side and I focus on robotics. Asking for students to sacrifice other aspects of their life for 6 weeks is fair, given the massive benefits that FRC brings. It is not, however, reasonable to expect that students give much more than that, because we're getting to the point where it will prevent students from joining, or even continuing with the team. (I certainly do less after bag day. I still work, and work a lot, but no longer to the exclusion of other parts of my life.)

I am now more interested in CMU/MIT than Juilliard/Oberlin; in Randy Pausch than Placido Domingo; in data storage and analysis than in opera. I don't think it's overly narcissistic of me to consider that a success for FRC; it seems very much like what FIRST was founded to do. If bag day were removed and our build season schedule extended, however, then it may not have been possible. The "responsible" decision for me would have been to not join my FRC team, not be exposed to engineering as a possibility, and stay with music and performance as paths for my life. That would have been a shame. Ignoring the time demands of students with other interests detracts from FRC's appeal to students who aren't already interested in STEM.

That said, the compromises from previous threads look like really good ideas.

[Nathan Streeter]

Originally Posted by AllenGregoryIV

I've made my stance clear for a long time, the six week build season negatively impacts lower resource teams to a greater degree then large resource teams to the detriment of the entire program.

If we remove the build season limitation across the board we will see a dramatic increase of the quality of the product that we put on the field in front of the public.

I agree wholeheartedly with this, and think it's the most compelling and important argument against the 6-week build season. Yes, the top teams (and a growing number of middle tier teams) build two robots... expending more resources, etc.... but they'll always expend a lot of effort and will probably compete marginally better without the "6-week" system. The difference is that the teams that don't have the resources to make a second robot can suddenly have a far more developed product at their first event if they still put in at least as much effort.

[MrForbes]

Originally Posted by Nathan Streeter

The difference is that the teams that don't have the resources to make a second robot can suddenly have a far more developed product at their first event if they still put in at least as much effort.

I think the major "resource" that teams need to improve their robots, either in 6 weeks or in a longer time, is effort. Getting the motivation to put in this extra effort is the tricky part. Having the time available is not the issue--we've heard from a few self proclaimed low-resource teams that consistently produce great robots in 6 weeks, because they effectively use all the time available.

Teams that have their act together can build a great robot in 6 weeks, or 12 weeks. Teams that don't have their act together will probably build the same so-so robot in 12 weeks that they now build in 6 weeks.

[techhelpbb]

The reason I personally am not a fan of the 6 week build season is that it gives one the idea that we stop. Been doing this long enough to know that FIRST teams rarely stop at 6 weeks. I am a people leader at my job (it's part of my duty) and if someone on my team with the crazy hours we work took 6 weeks of their time to do this every possible non-work/non-sleep hour and then more and more time outside of that I would ask them to think over the impact this quasi-deadline is having on them.

However there is a learning issue at work here and after a good long time I am making efforts to decouple it. I can't teach a really motivated programmer or CNC machinist (that's right I am treating these young adults as young professionals with a skill) a large amount of what I could teach them in a mere 6 weeks. MORT (FRC11) does MORT-U between September and just before Thanksgiving 2 nights a week. Even that is not enough. It's not merely a MORT thing, or a MAR thing or even an FRC thing. They have the same issue at NextFAB and that has little to do with FIRST at all. Also that commitment of 6 weeks every night is really hard for me at a personal level considering the scale of my responsibilities (I work in Manhattan and Mount Olive is 2.5 hours each way).

So I am slowly gathering machine tools light enough to be mobile and FRC parts to make it possible to decouple from MORT the programming and CNC efforts. Then, even in the summer when we have limited access, we always have a shop and access to robots. Still on the fence on where we will work but everything is mobile and 115VAC so where ever it is we will make do. Plus this decouples from the charitable corporation and the school so if I decide to help out some other venture with the tools I am free to do so.

If the learning opportunities are not interrupted by demotivating factors I really think the 6 week build season is ample if you have enough people to share the load which does often directly work against new teams. I have rarely seen a new team that came into FIRST with all of the required skills to compete with the veterans, mind you, many learn impressively fast but the playing field is hardly level. It has taken me 20 years to decide to commit what amounts to $15k to building tooling that doesn't actually serve my business purposes (I can do my job and run my businesses with a cheap printer, laptop and Internet). Now I just need to make it finally happen and see how many students commit their time to this opportunity.

[Jon Stratis]

Personally, I'm rather swayed by the international team argument - if we remove bag day, it automatically puts those teams at a disadvantage, as they have to be hands off the competition robot while it ships. Having had teams from Hawaii or China at my events before, I don't want to see them decide to just to local events so they have that extra week or two to work on the robot. We'd miss having them and the different experiences they bring to the event!

Also, having the 6 week deadline directly amirrors how things go for me at work as a software engineer. You spend a lot of time working on a release, with a known target date. You meet that date and package up your "dot-zero" release. Then you turn around and start working on the "dot-one" release, fixing everything you didn't have time to fix within your schedule, or addressing bugs that were found late in the process. There's a lead time between finishing the release and going live, and as a result your under time pressure to finish the "dot-one" release so you go live with that instead of the "dot-zero". Then it goes live and your customers find all sorts of stuff you missed. So you go back and start working on fixing those in a "dot-two" release, again under a time crunch because you don't want to tick off your customers for too long.

In FRC, your bagged robot is version 1.0. You keep working on improvements, and practice day at the event you change it to 1.1. Then you see how it does on the field, design other improvements, and address those for version 1.2 at your next event. Take away stop-build, and your short changing that cycle, in my opinion.

[techhelpbb]

Originally Posted by Jon Stratis

Also, having the 6 week deadline directly mirrors how things go for me at work as a software engineer. You spend a lot of time working on a release, with a known target date. You meet that date and package up your "dot-zero" release. Then you turn around and start working on the "dot-one" release, fixing everything you didn't have time to fix within your schedule, or addressing bugs that were found late in the process. There's a lead time between finishing the release and going live, and as a result your under time pressure to finish the "dot-one" release so you go live with that instead of the "dot-zero". Then it goes live and your customers find all sorts of stuff you missed. So you go back and start working on fixing those in a "dot-two" release, again under a time crunch because you don't want to tick off your customers for too long.

So technically I help lead several hundred software developers. A project with a timeline so short it negatively impacts the people doing the work and produces broken product that no one thinks meets any of the expectations is a project not scoped correctly.

I think the 6 week timeline can be met with significant pressure on the people driving it. I also think what comes out from all of the FRC teams is pretty darn impressive and definitely most people can see it being competition worthy.

So I would propose:

1. We should have a deadline that is a longer by just a few weeks.
A. So that the commitment is not every night and weather has less impact which can be dangerous.
B. The teams that get close have a little more time to get to the destination.

2. There should be more study of what makes new teams successful with an eye towards improving that experience.

I know work tends to grow to fill the time you give it. So realistically there will be people who will waste just as much time with more time. However one can always point out the expansion of the technical problem by people who lack the foresight to see the outcome before hand. I am pointing out the actual level of commitment for this challenge is higher than is required from my teams at a professional level and if at a professional level I worked my employees like this I would loose some of them to jobs that pay just as well, produce just as many results and do it by working smarter.

[Nemo]

There is a mistaken impression that 45 days is the traditional build season length, therefore 45 days is the optimal balance of avoiding burnout and producing good results.

We could go shorter OR longer, and people would adapt to make it work. Your team's definition of a sustainable, "sane enough" pace is going to change depending on the length of the build sprint.

We could have any length of build season from 3 days up to a multi-year season. We've seen what RI3D build sprints look like. A team could try to sustain that type of around-the-clock, break-neck pace through 100% of every day of the entire 45 day build season. But they don't.

The longer the time period you look at, the lower the maximum level of average sustained output a human will be able to provide. If people are close to their max over 45 days, that means their level of average sustained output would have to be less over a longer period of time.

Try to imagine the other extreme. If FIRST released the 2020 game after this year's Championship, then this year's 8th graders could start working on their senior year FRC game before they even get to high school. If the system was like that, would everybody automatically start working on it (plus 2019, 2018, 2017 games) for 4+ years running as if it was a long version of the 45 day build sprint? That would cause everyone to get get fired / get divorced / drop out / suffer various health problems / have a mental health breakdown and so on. But really that wouldn't happen. People would adjust their behavior.

1) A longer build season would change some behaviors of FRC teams.
2) If a team tries to sustain a schedule that actually isn't sustainable for them over any length of time, it isn't the rest of the teams' fault for forcing them to do that.