why blame the programmers??

[krudeboy51]

im wondering, if anything goes wrong with the robot why blame the programmers??(any suggestions, comments or ideas??)

[davidthefat]

You can't see software, people have a tendency to blame the unseeable (e.g. software, attitude/mind, God... ect)


Seriously, I sick of it, 90% of the time, it was hardware problems, but people blame software 90% of the time...

[NorviewsVeteran]

Because it's their fault.

[davidthefat]

Originally Posted by NorviewsVeteran

Because it's their fault.

Team Role: Mechanical

Typical, most complaining about software was from either mechanical or electrical guys...

[Al3+]

The trick is to train the rest of the team to blame electrical instead.

[tsa256]

Originally Posted by Al3+

The trick is to train the rest of the team to blame electrical instead.

That would work great except, I currently hold head programmer, and electrical. So you can imagine I get all the blame.

[DSST\neal.ian]

Originally Posted by tsa256

That would work great except, I currently hold head programmer, and electrical. So you can imagine I get all the blame.

At least you're not alone! I'm in the same boat. OH, AND troubleshooting. If something doesn't work, it doesn't matter what it is, it's my job to figure out what the problem is and figure out how to fix it.

[Lightfoot26]

Originally Posted by tsa256

That would work great except, I currently hold head programmer, and electrical. So you can imagine I get all the blame.

The same goes for me....

[thefro526]

If I may make a suggestion for some of those that are on either side of the Programming vs. Mechanical Blame Game:

Communication is key, especially with something like Mechanical and Programming. A large portion of Programming can be done without a Robot in front of you, I'd estimate something like 80%-90%. Mechanical should communicate the design to the Programmers as early as possible so that the Programmers can begin writing code, so that once the robot is completed it's just a matter of tuning the code and making minor changes.

This year, once our Design was settled, I went to the head programmer and outlined all of the robots functionality, I told him the number of motors, how they would be driven (relay vs. speed controller), planned sensor feedback, autonomous Strategy, Pneumatic Layout, etc etc. This gives he and his team a solid two to three weeks to code, if not longer, which should help keep them from being stressed out once the robot is done because the bulk of the code should already be written. I'd suggest teams that haven't done this should do it soon.

That doesn't mean I'm going to stop blaming the programmers when things go wrong though...

[George Nishimura]

Originally Posted by tsa256

That would work great except, I currently hold head programmer, and electrical. So you can imagine I get all the blame.

Ditto. It's so much easier to combine the two.

Although 60% of the time it is electrical, so I can't really complain too much.

[Bongle]

Originally Posted by Al3+

The trick is to train the rest of the team to blame electrical instead.

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.

[synth3tk]

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

[JewishDan18]

Typically, a program has many more points of failure than a mechanical or electrical system.

[kstl99]

Wow, I hope there is lots of joking in this thread. As someone who has programmed PLCs for machinery I am impressed that these programmers can get so much functionality in so little time. They are the last people who can test there work. They are the only ones that can work after the 6 week build but unless you have the luxury of a test robot they cannot test their code until the competition. The worst part is that their errors can be the most noticible, dead robot, erratic behavior,etc.

[ttldomination]

This can be a touchy topic because programmers can be semi-defensive, but I'd like to believe that mechanical can be a really visual thing, where as programming can be a mental jumble.

And we never "single out" the programming department. If something isn't working, all of the guys dive in and see if its their department. Just so happens that programming has the error.