why blame the programmers??

[CMSD]

Since it's usually the guys and gals on mechanical and electrical, one simple reason. The alternative is blaming themselves. Almost every problem we had at our two regionals was mechanical, but of course, the code was automatically blamed, and later proved to be completely flawless

[Burmeister #279]

I wrote an essay worth of response to this and then realized it was just a rant out one of my mentors and is now saved in my /rant folder. Here's the tl;dr version:
Its always the programmers fault.
I usually don't mind it but it can get frustrating.
As for the reason its usually the programmer's fault, it's probably because its the least understood by anyone who's not a programmer. Most programmers can diagnose problems and judge whether its the program's fault and even if we don't think its the program's fault we usually are willing to go back through our code and check for errors.

[JBotAlan]

So, this season 2586 had a straightforward 4wd drivetrain, with an AndyMark Toughbox on each side. It worked wonderfully after the mechanicals put it together, all the way through practice.

However, by the end of Traverse City, our driver was complaining every other match that the drivetrain was "lagging". Being that we couldn't reproduce anything similar in practice, we dismissed it as an unknown problem that hopefully wouldn't come back. Just in case, when we got back to the shop, we replaced all of the gray Jags with black ones and stress-tested; all seemed to be well.

Flash forward to Troy. Two or three matches into the competition, we are making a terrible grinding noise. We got it back into the pit and found that one of the gearboxes was frozen. Taking it apart, a pile of metal shavings fell out. What the driver described as "lagging" was actually chunks of gears floating around inside the gear boxes.

Why did this happen in the first place? Well, as it turns out, greasing your gear boxes is highly recommended.

Moral of the story: even if it seems like a programming problem, it can easily still be a mechanical issue.

Other moral: don't dismiss what your driver is reporting. He knows how the thing is supposed to feel, and when he's articulating that it feels "weird", even if he can't describe it, there's very likely something wrong.

[Jack Jones]

Originally Posted by JBotAlan

So, this season 2586 had a straightforward 4wd drivetrain, with an AndyMark Toughbox on each side. It worked wonderfully after the mechanicals put it together, all the way through practice.

However, by the end of Traverse City, our driver was complaining every other match that the drivetrain was "lagging". Being that we couldn't reproduce anything similar in practice, we dismissed it as an unknown problem that hopefully wouldn't come back. Just in case, when we got back to the shop, we replaced all of the gray Jags with black ones and stress-tested; all seemed to be well.

Flash forward to Troy. Two or three matches into the competition, we are making a terrible grinding noise. We got it back into the pit and found that one of the gearboxes was frozen. Taking it apart, a pile of metal shavings fell out. What the driver described as "lagging" was actually chunks of gears floating around inside the gear boxes.

Why did this happen in the first place? Well, as it turns out, greasing your gear boxes is highly recommended.

Moral of the story: even if it seems like a programming problem, it can easily still be a mechanical issue.

Other moral: don't dismiss what your driver is reporting. He knows how the thing is supposed to feel, and when he's articulating that it feels "weird", even if he can't describe it, there's very likely something wrong.

There's the problem!! The #1 reason to blame the programmers: They always forget to grease their code.

[ChrisH]

Originally Posted by CMSD

.... the code was automatically blamed, and later proved to be completely flawless

I find this very hard to believe. Flawless code would violate the First Law of Programing. There must be a flaw, you just haven't found it yet

[EricH]

Originally Posted by ChrisH

I find this very hard to believe. Flawless code would violate the First Law of Programing. There must be a flaw, you just haven't found it yet

Yep. I thought I had a good program for doing something (not involving a robot).

Then I went to test it, and it wouldn't load a file in correctly. Fixed that.

Then it's not catching some things it should. Fixed that.

Now it's really going haywire, but I know where the problem is. I *only* have to rewrite a couple of functions or so...

[ideasrule]

This year, the only time something went wrong in teleop that WAS a programming issue, programmers didn't get blamed! During the Rochester regional the drivers were experiencing massive lag with the robot, but blamed the FMS and never told the programmers about it. At the end of the day, I finally overheard them talking about the lag and fixed the problem within several minutes.

Moral of the story: better communication!

[Foster]

Great,what did you do to fix the lag? We had a lag problem at FLR and ended up pulling the vision code.

[Tom Ore]

It looks to me that we should address the very notion of "blame." This is a team sport and the team sinks or swims together. When there is an issue the team needs to find the best way to handle it. It can put incredible stress on one or two people if the rest of the team starts to lean on them for a solution. Instead, be supportive of the group (mechanical, electrical, softwre...) trying to solve the issue.

After the season is over, there is plenty of time for a "lessons learned' meeting to talk about what when right and what went wrong. This will help next season go more smoothly.

[ideasrule]

Originally Posted by Foster

Great,what did you do to fix the lag? We had a lag problem at FLR and ended up pulling the vision code.

That lag problem was because the code was, contrary to my expectations, saving files to the cRIO. The cRIO filled up and the robot became extremely laggy.

Another lag problem we had at the Waterloo regionals was because we used a pool noddle to fix the camera in place, and the pool noddle was pushing against the camera's reset button.

[billbo911]

Three thoughts:

1) Without good mechanics, programming doesn't mean squat.

2) Without decent programming, even incredible mechanics means nothing.

3) Why fix blame? Find the problem and work together on a solution!

[NorviewsVeteran]

Originally Posted by billbo911

3) Why fix blame? Find the problem and work together on a solution!

We would, but the programmers have to fix the code first.

[Yoel2630]

I think many times code is uploaded without the necessary adjustments.
So most of the time it's programmers blaming electrical connections, but because the electric team is usually done before the programmers, the problem is due to code! and then when they fix all the "mistakes" in code, such as i/o addresses or sending the opposite signal (1 instead of -1, which of course can be also solved by switching wires ), any other problem that may come up is really easy to pin on them

Excuse me for using the wrong terms or being unclear. My native language is Hebrew

[kylelanman]

We don't generally have to many problems with programming errors on our team but the programmers get blamed for everything and the mechanical team takes the credit when everything works.

The best one was when our battery came disconnected. The programmers say the mechanical team should have zip tied the connector together....which they should have. The mechanical team says the programmers shouldn't have run and hit the wall full speed during autonomous mode in Lunacy causing the battery to fly out of the robot and the human player at the middle station to crap his pants (slight exaggeration but half the balls in the hopper went over the wall and hit him)......okay maybe that one was a programming error.