why blame the programmers??

[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.

[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

[Andy L]

"because when it's mechanical, something falls off. When it's electrical, smoke appears."

someone on our team said this last year, and last year it was programmings fault

[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.

[biojae]

I tend to agree with the others above, though the only times that the programmers were blamed on my team (That I am aware of anyway...) were electrical issues.

Once last year, the driver complained that he couldn't drive. The joystick was plugged into the wrong port on the DS because of a hurried dash to replace a broken DS. (Dang ethernet ports!)

The only other error was a missing fuse, it was taken out while some debugging was performed, but forgot to be replaced

[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.

[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.

[Dkt01]

I just love how anything bad is the programmer's fault, but anything good is accredited to mechanical. I have been on both teams, but I like software because we get to make things work.

[Tanner]

I always find it interesting when someone blames the code as it just leads me to find something I didn't think about when coding the code. Plus I also get to blame someone else later, though I don't do that too often.

I just wish I could find some way of blaming the mechanical team after the robot went backwards in autonomous at Peachtree...

-Tanner

[kgzak]

Originally Posted by synth3tk

Because most often, it is the programmer's fault.

Originally Posted by AmoryG

Because if hardware broke as easy as code does, no team could afford to build a robot. If we were playing a match and suddenly our robot did something it was not supposed to, I would suspect that either the code or a sensor was not working as it should. Code breaks easy, and if our robot suddenly started malfunctioning, I would load up the most basic code that works beyond a doubt to confirm whether it was us programmers we should have blamed.

Most of the time, on our team, it was the hardware. Our main code wise was motors running backwards, but that was because a day before competition the build team decided to turn the motors 180 degrees. We also had watchdog errors, but that was because our WGA was bad. I don't remember any other problems with code/electrical.

[iblis432]

I get very irritated at this also. If it's even remotely possible that programming was actually the issue, i'll check it, but when we run the code, it works fine, nobody has even touched the labtop between matches, then something messes up the next time around, i find it very hard to believe its my fault. I've sat through lectures before about how its my fault when it was electrical or mechanical. I'm not afraid to say i messed up, but i wish i wasn't the only one like that on our team. If they would at least inspect the robot before blaming me i'd be happy, even if they didn't see the issue the first time.

[Al3+]

Originally Posted by Tanner

I just wish I could find some way of blaming the mechanical team after the robot went backwards in autonomous at Peachtree...

Obviously the wheels were mounted in reverse.

Originally Posted by Bongle

The trick is for each sub-component of a team (programming, electrical, mechanical) to listen to the other people's proposals for what is wrong, and investigate it to the best of their abilities. If the programmers say that a limit switch might have a short while the hardware guys say that the program isn't checking the switch often enough, both teams should double-check both of their components as best they can.

Quite often the programmers can direct the hardware guys to a potential source of a short or disconnected wire, while the hardware guys can tell the programmers if they're operating some system outside of its design limits. If both sub-teams can work together rather than fighting over whose bug it is, then you should have a more successful robot.

My comment wasn't completely serious. I'm not in favor of automatically denying that a problem is a code error unless it's glaringly evident that it's not a code error. (For example, the signal light wasn't blinking correctly. Nothing in the code deals with the signal light at all.)

I'm just lightheartedly expressing how often it seems that programmers investigate an issue only to discover an underlying electrical problem.