[GeeTwo]

I'll admit that I've just skimmed the responses, so I'm probably going to repeat a few points:

• Selection Bias: Most of the posts of code on CD are either code that is not working, and the writer doesn't know why, or software that the coder believes is well written (often justifiably so), and is being posted in a GP spirit. I'll wager that neither is typical FRC code!
• Excepting mentor coders, an average FRC coder's experience is probably better measured in months than years. Many high schools (including Slidell High) do not offer a single programming class. We don't despair at how clumsily the bear dances, but marvel that it dances at all.
• Most robot designs don't settle down in time for the coders to have a chance to really test the code. This is true at the rookie end, where the robot gets bagged before it's working, and at the powerhouse end, where the robot is redesigned at least twice between stop build and CMP, and at most points in between.
• How many posts have we seen lamenting that six weeks and three days is not enough time to build a robot? Guess which department gets the shortest part of that too-short stick? Anyone?
• Except in mandatory high-reliability environments (e.g. medical, space, perhaps automotive), code that works 95% of the time delivered by the deadline is "better" than code that works 99.999% of the time but comes along a few months too late. FRC is NOT a high-reliability environment that grants enough time to "get it right".
• Git is great when you have access to the internet, when the head programmer has the training and discipline to manage forks and when every programmer has the discipline to sync up after every couple of hours of coding. High school students at competitions typically meet none of these requirements.
• Test code on the practice field? Don't make me laugh! We can't get enough time to test mechanical systems on a field that doesn't properly simulate the competition field.
• While we don't have a general rule of "don't fix code unless it's broken", a basic risk/reward analysis frequently results in code lock down during competition.