Mythical Six Week Build Season

[GreyingJay]

I would be in favour of a slightly longer build season. 8 weeks maybe?

A few posts back someone said that a team that doesn't have its act together will produce the same so-so robot in 12 weeks as it would have in 6 weeks. That sounds like a derogatory comment, but it's probably true, and I would take the viewpoint of "well in that case, why not?" If not for a better quality robot then for better mental sanity for all the students and mentors and parents involved. A longer build season would be a little bit less stress and that might actually mean the difference between giving up at the 11th hour and just slapping it together, or having the ability to say "ok, let's take a break, rest, and look at it again tomorrow".

I have worked on software projects that "required" a lot of overtime due to overly aggressive schedules, and everyone who has been in this position knows that the work you produce at 11pm on a Sunday night is not the same quality as the work you produce during the regular weekday.

Having a slightly longer build season would also be a little more forgiving for those teams that don't "have their act together". The team I was on last year had a good pedigree but was hobbled because of (a) some design churn and (b) one of their manufacturing sponsors promised to make some parts and were two weeks late getting them. That resulted in everything "sliding to the right". It happens to the best of us. I like that there IS a stop build day, though, because you do need to deal with this in the real world.

[marshall]

Originally Posted by Jon Stratis

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.

I think it is worth mentioning that many software development shops are moving to continuous integration and software release cadence is being shortened. I live in the DevOps world (mostly on the Ops side but I speak the language of both camps) and it's an interesting analogy to what we (my team) go through with building two robots in FRC.

[techhelpbb]

Originally Posted by marshall

I think it is worth mentioning that many software development shops are moving to continuous integration and software release cadence is being shortened. I live in the DevOps world (mostly on the Ops side but I speak the language of both camps) and it's an interesting analogy to what we (my team) go through with building two robots in FRC.

Agreed. The team I lead is a DevOps team in an environment shifting towards our model:

The trick is that merely releasing frequently is pointless if the quality control feedback is not there. One needs to recognize that a 2 week scrum in an agile workflow is a soft deadline. One is supposed to evolve scheduling that matches the feedback from the working results. It's not unusual that major corporations merely setup 2 week scrums and make hard unyielding deadlines like it's a health check and then they realize that 'done' is not 'done'.

To make CI/CD work you have to work like a manufacturer. You have to adapt at each checkpoint changing direction to yield the best result with the resources you have. It's not just continuous deployment and integration it is also continuous improvement. I can't not express how many times that 'continuous improvement' part is totally lost on the people who think tossing Jenkins in will fix all their issues.

With just 6 weeks there is really a limit to what can really be delivered. It's a soft deadline that building 2 robots does change but at the cost of 2 robots. It's like forking a software development project because you know you are going to come up short.

[Collin Fultz]

I did an informal poll at last year's IRI, walking around the pits asking teams if they had a practice robot.

I don't still have my notes. If I remember correctly, 3 teams there had not built a practice robot. Two were in district areas and felt that they no longer needed to with the unbag time. One was from a regional area.

The remainder of teams at this event had a practice robot.

[MrForbes]

If we had a 6 week build season, and at around week 5 it was then extended to an 8 week build season, then I think the extra time would help many teams. But if we know that we have 8 weeks, we'll try to do more, and still not get it done in time.

[marshall]

Originally Posted by techhelpbb

I can't not express how many times that continuous improvement part is totally lost on the people who think tossing Jenkins in will fix all their issues.

Yes! It's a lot like picking out a wrench and saying "I'm ready to build a robot now!" when in reality you need multiple wrenches, other tools, training, and a team who has bought into the idea of building the robot in the same way! I feel your pain, trust me.

[techhelpbb]

Originally Posted by MrForbes

If we had a 6 week build season, and at around week 5 it was then extended to an 8 week build season, then I think the extra time would help many teams. But if we know that we have 8 weeks, we'll try to do more, and still not get it done in time.

This is an obvious concern that people will not exercise good foresight. The less you really know about the competition and the hardware the more likely this will happen.

In DevOps we fix this with a checkpoint. Show your work and tell us how you will reach the end in 2 more weeks. It serves the same purpose without replicating the robot which is cost ineffective. Perhaps teams could be required to show their work to their peers in the area. I mean we ask for documentation which, in theory, should show the plan.

The way FIRST works now is very waterfall. We give you 6 weeks. Then judge how complete you are at the hard stop at the first competition you show up to. However some teams manage to slip a little more time in by taking it out of the time they have between the 2: stop build and competition. I am pretty sure we can all tell if you have no drive train at all by the end of 6 weeks you are in trouble.

[the programmer]

A lot of people are saying that eliminating build season will benefit low resource teams. I think the exact opposite would happen.

Right now, even if you do build a practice robot, it's a clone of your bagged robot that you use for driver practice and to test modifications. By eliminating stop build day, you don't stop teams from building a second robot, but you make that second robot a completely new iteration on the first.

High level teams have already proven that they have the time and money for this but the majority of the FRC community does not.

What this means is that instead of getting some advantage out of building a second robot, which some high level teams (610 if I'm not mistaken) have foregone, it now becomes almost impossible to compete at a high level without building a second robot.

My former team has built two robots since 2011 and my current team will start building a second robot this year. However, even with building two robots, the end of build season brings the intensity of our schedule way down.

Do, while I sympathize with the teams who don't have time to practice in the six week window, know that by eliminating the six week build season, low resource teams would have an even harder time keeping up and to be competitive, a build season intensity schedule would be required all the way through champs.

[Michael Corsetto]

Originally Posted by the programmer

Do, while I sympathize with the teams who don't have time to practice in the six week window, know that by eliminating the six week build season, low resource teams would have an even harder time keeping up and to be competitive, a build season intensity schedule would be required all the way through champs.

We are going to build three robots (1 comp and 2 practice) for 2016.

Why?

The competition season is longer than the build season.

We will do more development and iteration during the competition season than the build season.

We want two robots to iterate faster during the competition season.

I think its clear that the gap is wide between us and low resource teams because we have the money to buy 3x of robot parts, and get to play with two robots post-stop build, and low resource teams get to play with zero robots post-stop build.

You make the call if the gap shrinks when low-resource teams get to play with their one and only robot while we're playing with our two or three robots.

We meet 4 days a week.

-Mike

[Jon Stratis]

Originally Posted by techhelpbb

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.

So you've never found a bug in your production code? Never had a customer ask for a change to a feature you just released? Never asked any of your employees to work late or spend a little time on the weekend to get something out the door on the scheduled date? Honestly, that sounds like fantasy to me. There are always bugs. There's always stuff your customers are going to want done differently. And there's always stuff that won't go quite as planned, requiring either extra time or dropped features to hit your deadline (which, sometimes, is imposed on you by forces outside your control).

[Drivencrazy]

Originally Posted by the programmer

... a build season intensity schedule would be required all the way through champs.

Required? Absolutely not. There's nothing that says every team HAS to compete at the same level. As Mike so clearly states, right now the best teams do keep up the intensity, and most likely ramp up as more information becomes available on other teams and new strategies, during the competition season. As you said, your team brings the intensity down after the build season. Those are choices that every team makes and every team can continue to make if there is no bag day. The difference would be how effective your time can be during the competition season. If you don't meet at all now, you could continue to not meet and play with the same robot you start the comp season with. If you do meet and currently build two robots, you could potentially drop it down to one robot and still perform the same functions. If you meet and build three robots now maybe you can get away with two and maintain efficiency. Nothing is ever going to completely level the playing field and I don't necessarily think we should try. But this will help teams who want to be competitive and have the drive but not the resources compete at a higher level.

[Jon Stratis]

Originally Posted by techhelpbb

Agreed. The team I lead is a DevOps team in an environment shifting towards our model:

The trick is that merely releasing frequently is pointless if the quality control feedback is not there. One needs to recognize that a 2 week scrum in an agile workflow is a soft deadline. One is supposed to evolve scheduling that matches the feedback from the working results. It's not unusual that major corporations merely setup 2 week scrums and make hard unyielding deadlines like it's a health check and then they realize that 'done' is not 'done'.

To make CI/CD work you have to work like a manufacturer. You have to adapt at each checkpoint changing direction to yield the best result with the resources you have. It's not just continuous deployment and integration it is also continuous improvement. I can't not express how many times that 'continuous improvement' part is totally lost on the people who think tossing Jenkins in will fix all their issues.

With just 6 weeks there is really a limit to what can really be delivered. It's a soft deadline that building 2 robots does change but at the cost of 2 robots. It's like forking a software development project because you know you are going to come up short.

Comparing the build season to agile development is a seriously flawed comparison. Stop build day is not the last day of a single sprint - it's the last day of the entire release, which was composed of many sprints (for my team 6, one sprint per week, which is a little shorter than most agile shops).

[techhelpbb]

Originally Posted by Jon Stratis

So you've never found a bug in your production code? Never had a customer ask for a change to a feature you just released? Never asked any of your employees to work late or spend a little time on the weekend to get something out the door on the scheduled date? Honestly, that sounds like fantasy to me. There are always bugs. There's always stuff your customers are going to want done differently. And there's always stuff that won't go quite as planned, requiring either extra time or dropped features to hit your deadline (which, sometimes, is imposed on you by forces outside your control).

In about the last 10 months I've worked about 1,000 hours of time over a 8 hour work day specifically because someone scoped a project with too little time to make the core delivery. Bugs or not.

That's not a little over time. That's basically 70 hours a week. All because someone didn't actually think about the scope, or did not understand the scope, of the core deliverable.

There's a great big difference between mostly there and off by a mile. In some cases you build a massive piece of computing infrastructure at break neck and break your necks doing it. In others you build a robot that has to accomplish 2 tasks: compete and educate. A lot of people compete but we should be honest: how many can claim that with a little more time they wouldn't have been able to educate better?

Originally Posted by Jon Stratis

Comparing the build season to agile development is a seriously flawed comparison. Stop build day is not the last day of a single sprint - it's the last day of the entire release, which was composed of many sprints (for my team 6, one sprint per week, which is a little shorter than most agile shops).

Correct it's a hard stop that, because of the way it's done, is not a real hard stop.
You can literally buy yourself more time by buying parts for more robots.
My point was it should be a soft stop: we should checkpoint at the 6 week mark such that we close the loophole.

[Jon Stratis]

Originally Posted by techhelpbb

In about the last 10 months I've worked about 1,000 hours of time over a 8 hour work day specifically because someone scoped a project with too little time to make the core delivery. Bugs or not.

That's not a little over time. That's basically 70 hours a week. All because someone didn't actually think about the scope, or did not understand the scope, of the core deliverable.

There's a great big difference between mostly there and off by one mile.

And how does that compare to the 6 week build season? In my experience, it is entirely possible to build a successful robot in 6 weeks. It's also possible to blow your own schedule and not meet the deadline. Figuring out how to deal with that, the importance of checkpoints and adjustments along the way is a crucial part of engineering.

[Kevin Leonard]

For most teams, I think removing the stop build day is a positive thing. It will make teams able to be more competitive and remove the need to build expensive practice robots.

However, teams who have to travel long distances to compete are at a disadvantage with the removal of stop build. If I have to ship my robot out a week in advance of an event, I lose that week of time to build and iterate. If you're a team that plans on attending a week 2 and 4 regional, for example, you lose out on week 1 and week 3 that your opponents have to iterate.


I would prefer one of the compromises illustrated earlier in the thread here, but given the choice between having a stop build day and not having a stop build day, I'd prefer not having it.