[Kevin Leonard]

This year, 20 had it's best programming team yet. And they were a team, for once, whereas in previous years we often had one person who did most of the programming on the robot.
We had most functions during teleop that were automated, and advanced controls on our elevator , forks, and drive, and it was exceptional to see them take a less-than-ideal mechanical design and optimize it the way they did.

However, I wish we chose a simpler mechanical design, because there was only so much they could do to fix the robot before returns started to diminish.

I'm generally a fan of making the mechanical design support the programming. Making the programming the easy part. Making the programming be "When the driver presses the button, shoot", and not "When the driver presses the button, activate the aiming system, then shoot".

For example, 20's 2013 robot was built to be as simple a floor loader as possible. We shot from one position on the field, and that was right in front of the pyramid. We had some limit switches hooked up so that when the robot was in position, they would cause some lights to light up, and our drivers knew they were locked in and shot.

However, if your team has more programming resources, they could persue a design with a higher ceiling due to programming, like 195's 2013 robot.

They were a full-court shooter, and they went to Connecticut with a very good full court shooter and won the event with Team 20. At champs, they were faster, more accurate, and could shoot from more places. At IRI, they had perfected their bag of tricks to include shots through the opponent's pyramid and from anywhere on the field.

There is definitely a place in FRC for more complex, elegant programming, but it's not necessary to succeed. Complex programming is a resource, in the same way that sponsorships, machinery, and CAD knowledge is a resource. If you're able to use that resource, that's fantastic for you and your team, you have more options en route to success. If you don't have that resource, you have a limited set of options for success.
I know that in 2016, 20 is likely to lean more heavily on our programming team than ever before, because we know they're extremely capable, but in 2017 we might not.