Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   why blame the programmers?? (http://www.chiefdelphi.com/forums/showthread.php?t=84922)

krudeboy51 03-04-2010 20:28

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

davidthefat 03-04-2010 20:34

Re: why blame the programmers??
 
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 03-04-2010 20:42

Re: why blame the programmers??
 
Because it's their fault.

davidthefat 03-04-2010 20:44

Re: why blame the programmers??
 
Quote:

Originally Posted by NorviewsVeteran (Post 947550)
Because it's their fault.

Team Role: Mechanical

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

Al3+ 03-04-2010 20:49

Re: why blame the programmers??
 
The trick is to train the rest of the team to blame electrical instead.

AmoryG 03-04-2010 20:53

Re: why blame the programmers??
 
Quote:

Originally Posted by krudeboy51 (Post 947546)
im wondering, if anything goes wrong with the robot why blame the programmers??(any suggestions, comments or ideas??)
:confused:

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.

tsa256 03-04-2010 20:55

Re: why blame the programmers??
 
Quote:

Originally Posted by Al3+ (Post 947552)
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.

Bongle 03-04-2010 20:56

Re: why blame the programmers??
 
Quote:

Originally Posted by Al3+ (Post 947552)
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.

DarkFlame145 03-04-2010 21:12

Re: why blame the programmers??
 
Quote:

Originally Posted by krudeboy51 (Post 947546)
im wondering, if anything goes wrong with the robot why blame the programmers??(any suggestions, comments or ideas??)
:confused:

Because Mech and Fab can't do anything wrong to make the robot not work =P (I was the welder for my HS team) Plus our programmers did things like buy soldering irons from the dollar store, have to rewire one, and then it blows up while someone is using it. It's always the code =P jkjkjk To be Honest I dont know why people blame programing

synth3tk 03-04-2010 21:14

Re: why blame the programmers??
 
Because most often, it is the programmer's fault.

JewishDan18 03-04-2010 21:24

Re: why blame the programmers??
 
Typically, a program has many more points of failure than a mechanical or electrical system.

Radical Pi 03-04-2010 21:25

Re: why blame the programmers??
 
Perhaps my favorite quote from the season: "The programmer's taking responsibility for the problem. It must be mechanical then!"

It's simply a black box problem. Almost anyone on a team can understand how a mechanical system works. Electrical causes much more confusion than mechancial, but it is still understandable to many. Programming is the least understood, so everyone automatically jumps to it. Programmers (on our team at least) understand almost everything on the robot, and can therefore pinpoint exactly where the problem is. Since the programmers usually figure out the problem, guess who is yelled at every time?

Oh, and my favorite error of the season was when mechanical drilled through some wire on the robot and caused everything to fail.

kstl99 03-04-2010 21:26

Re: why blame the programmers??
 
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 03-04-2010 21:38

Re: why blame the programmers??
 
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. :P

EricH 03-04-2010 21:42

Re: why blame the programmers??
 
Because, with 5 weeks to plan and get ready (and presumably knowing all the ratios between where their encoder is and where the wheel is that it's tracking), they STILL complain when they only get a week to test the robot and implement the minor tweaking that should take 3 days at most.

Oh, and if a mechanical guy makes a minor error, the robot can still work. If a programmer makes a minor error in the wrong place, the robot doesn't work...

(Mechanical guy joking about good reasons not to take the blame)

Oh, and Bongle--
Quote:

If both sub-teams can work together rather than fighting over whose bug it is, then you should have a more successful robot.
I'm sorry, but the mechanical bugs immediately get squashed by the nearest flyswatter. The programming team is therefore the only team that has bugs...:p But yes, in principle it is best to work together to find the problem and eliminate it.

Chris is me 03-04-2010 21:47

Re: why blame the programmers??
 
The programmers are the last people to touch the robot and because the mechanical teams drop the ball, they have extremely little test time. That's why programmers get blamed all the time.

Nick Lawrence 03-04-2010 21:55

Re: why blame the programmers??
 
Quote:

Originally Posted by Chris is me (Post 947583)
The programmers are the last people to touch the robot and because the mechanical teams drop the ball, they have extremely little test time. That's why programmers get blamed all the time.

So true.

SOLUTION: Build a practice bot.

-Nick

Akash Rastogi 03-04-2010 22:00

Re: why blame the programmers??
 
Quote:

Originally Posted by Nick Lawrence (Post 947586)
So true.

SOLUTION: Build a practice bot.

-Nick

Practice bots get stuff done.

True fact.

Andrew Schreiber 03-04-2010 22:15

Re: why blame the programmers??
 
Quote:

Originally Posted by Chris is me (Post 947583)
The programmers are the last people to touch the robot and because the mechanical teams drop the ball, they have extremely little test time. That's why programmers get blamed all the time.

Thems fighting words Chris.

No, really the reason is because programming is not always understood. My standard debugging practice: Reproduce the error 2 times in the pit, mech/elec check sensors/motors while prog checks the code for those inputs.

Programmers, the LAST thing you should do is say it isn't the code.

Uberbots 03-04-2010 22:27

Re: why blame the programmers??
 
They blame the programmers because, sadly, most of the time is is the software. Furthermore, when a problem arises that could be fixed in either software or hardware, typically it is simpler (depending on the programmer) to just rewrite a couple lines of code.

Also, the programmer should be by no means the last one to test their product. Throughout the design process of the robot the programmers should have access to a simple prototyping system to at least verify if the code runs, and hopefully use some of the outputs of the test system to determine at least valid output. By the time the mechanical team (finally) finishes their part, all the software team should have to do is tune a few parameters or change a couple lines.

In my opinion if you don't have running code by the time the robot is ready for it, or you have a broken interface (e.g. programmers say left motor is pwm01, but electrical says its pwm03) then your design process is broke.

obviously how far along the code is when the robot is ready varies from team to team, but there is no excuse for having untested or incompatible code at that point.

rsisk 03-04-2010 22:34

Re: why blame the programmers??
 
If blame is being passed around, then the person doing the blaming probably has no idea what the problem is, otherwise they would be pointing out what the problem is and getting it fixed.

Therefore, it doesn't matter if the programmer is getting the blame because by my definition above, the person doing the blaming is ignorant and should be ignored anyway.

ideasrule 03-04-2010 22:35

Re: why blame the programmers??
 
Quote:

Originally Posted by Andrew Schreiber (Post 947598)
Thems fighting words Chris.

No, really the reason is because programming is not always understood. My standard debugging practice: Reproduce the error 2 times in the pit, mech/elec check sensors/motors while prog checks the code for those inputs.

Programmers, the LAST thing you should do is say it isn't the code.

I've said a few times that I was sure the problem wasn't the code. Every time, it turned out not to be in the code. A programmer should at least be able to tell if something definitely ISN'T a code issue, when it definitely IS a code issue, and when he should keep quiet because the cause isn't certain.

cpeister 03-04-2010 22:40

Re: why blame the programmers??
 
We had a driving chassis this year to test code on. It was a 6WD where our competition robot had 4, but it still worked reasonably well to test drive code. When it came to programming the attachment, we had to write hypothetical code and test how well it worked by attaching servos and limit switches and encoders to the test robot, and running the drive motors in place of the attachment motors. We were able to do some testing, but never had a complete robot before ship. Afterwards, our arm was completely redesigned and included in our withholding allowance.

We still had many errors that were blamed on programming, some of which were our fault, but many weren't :p I guess we are first to blame because they don't know exactly what our code is doing, and because they can't see any obvious problems with the mechanical or electrical. My favourite error of the year, we had next to nothing working on the robot, except for one servo that ran when a jag should have. Programming was blamed immediately, but it turned out that the sidecars were plugged into the wrong ports, so the command for 4,6 was going to 6,6.

Andrew Schreiber 03-04-2010 22:41

Re: why blame the programmers??
 
Quote:

Originally Posted by ideasrule (Post 947607)
I've said a few times that I was sure the problem wasn't the code. Every time, it turned out not to be in the code. A programmer should at least be able to tell if something definitely ISN'T a code issue, when it definitely IS a code issue, and when he should keep quiet because the cause isn't certain.

The programmer should not rule out a code issue in any circumstances that they cannot back up that with definitive proof. No, "Because I wrote it" is not proof.

delsaner 03-04-2010 22:43

Re: why blame the programmers??
 
Quote:

Originally Posted by Chris is me (Post 947583)
The programmers are the last people to touch the robot and because the mechanical teams drop the ball, they have extremely little test time. That's why programmers get blamed all the time.

Even when our robot is shipped, the programmers still meet to work on codes and autonomous modes. There the last ones to touch the robot, which is the legitimate reason. (The fun reason varies with each team you talk to, IF they have a fun reason to blame them ;))

wireties 03-04-2010 22:54

Re: why blame the programmers??
 
Because the mechanical guys always finish late and give electrical and software guys the last 3 days to make it magically work o;).

And because the mechanical guys can't get it through their head that the robot itself is part of the servo feedback. The software can't be fully tested w/o working hardware - the gyro does not work while the robot is shaking itself apart - etc, etc, etc Classic comment: It works perfectly on the stand but not on the ground!! It has to be a software problem. Hehehe...

Just kidding (mostly) - I appreciate those mechanical guys!

sashboy226 03-04-2010 23:06

Re: why blame the programmers??
 
Quote:

Originally Posted by Al3+ (Post 947552)
The trick is to train the rest of the team to blame electrical instead.

Thats what we do. When we get metal shavings in the jags, its always electricals fault, they dont watch us close enough

davidthefat 03-04-2010 23:09

Re: why blame the programmers??
 
Quote:

Originally Posted by wireties (Post 947621)
Because the mechanical guys always finish late and give electrical and software guys the last 3 days to make it magically work o;).

And because the mechanical guys can't get it through their head that the robot itself is part of the servo feedback. The software can't be fully tested w/o working hardware - the gyro does not work while the robot is shaking itself apart - etc, etc, etc Classic comment: It works perfectly on the stand but not on the ground!! It has to be a software problem. Hehehe...

Just kidding (mostly) - I appreciate those mechanical guys!

Just have the electrical guys put together all the stuff before mechanical so programmers can test on it

ALTrammell818 03-04-2010 23:18

Re: why blame the programmers??
 
We blame electrical :]

CMSD 03-04-2010 23:31

Re: why blame the programmers??
 
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 :D

Burmeister #279 04-04-2010 01:42

Re: why blame the programmers??
 
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 04-04-2010 02:18

Re: why blame the programmers??
 
Quote:

Originally Posted by CMSD (Post 947641)
.... the code was automatically blamed, and later proved to be completely flawless :D


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 :p

Andy L 04-04-2010 02:35

Re: why blame the programmers??
 
"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 :P

JBotAlan 04-04-2010 02:46

Re: why blame the programmers??
 
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. :p

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 04-04-2010 02:51

why blame the programmers??
 
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 :o

EricH 04-04-2010 02:56

Re: why blame the programmers??
 
Quote:

Originally Posted by ChrisH (Post 947691)
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 :p

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 04-04-2010 03:32

Re: why blame the programmers??
 
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 04-04-2010 07:13

Re: why blame the programmers??
 
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 04-04-2010 07:57

Re: why blame the programmers??
 
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 04-04-2010 08:17

Re: why blame the programmers??
 
Quote:

Originally Posted by JBotAlan (Post 947693)
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. :p

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. :rolleyes:

Dkt01 04-04-2010 12:15

Re: why blame the programmers??
 
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 04-04-2010 12:27

Re: why blame the programmers??
 
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 04-04-2010 12:41

Re: why blame the programmers??
 
Quote:

Originally Posted by synth3tk (Post 947566)
Because most often, it is the programmer's fault.

Quote:

Originally Posted by AmoryG (Post 947555)
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 04-04-2010 14:43

Re: why blame the programmers??
 
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+ 04-04-2010 14:54

Re: why blame the programmers??
 
Quote:

Originally Posted by Tanner (Post 947781)
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.

Quote:

Originally Posted by Bongle (Post 947558)
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.

Egg 3141592654 04-04-2010 14:57

Re: why blame the programmers??
 
I, being the ONE programmer on our team, know your pain. There are three main reasons why people love to pick off programmers.
1. Code isn't physical, aka nobody can see you fix it, and nobody except for programmers can fix it.
2. Unknown Logic, Many non-programmers think that programming is VERY simple so when something goes wrong, they think that it is "just an easy fix" (probably not)
3. Strength in numbers, It is easy to blame 1 or 2 people then a whole mechanical section, or electrical section.

It is really too bad programmers are placed in this situation, i mean, they're just as important as any other section of a team.

ideasrule 04-04-2010 15:43

Re: why blame the programmers??
 
Quote:

Originally Posted by Foster (Post 947708)
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 04-04-2010 16:34

Re: why blame the programmers??
 
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 04-04-2010 18:22

Re: why blame the programmers??
 
Quote:

Originally Posted by billbo911 (Post 947879)
3) Why fix blame? Find the problem and work together on a solution!

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

davidthefat 04-04-2010 21:51

Re: why blame the programmers??
 
Quote:

Originally Posted by Egg 3141592654 (Post 947842)
2. Unknown Logic, Many non-programmers think that programming is VERY simple so when something goes wrong, they think that it is "just an easy fix" (probably not)

Seriously, I showed up to a meeting late and the 2 other programmers tried to get the solenoid working for 3 hours... I only took 3 minutes to get that working... :confused: Sometimes I feel like I am the only programmer...

ideasrule 04-04-2010 21:53

Re: why blame the programmers??
 
Quote:

Originally Posted by davidthefat (Post 948064)
Seriously, I showed up to a meeting late and the 2 other programmers tried to get the solenoid working for 3 hours... I only took 3 minutes to get that working... :confused: Sometimes I feel like I am the only programmer...

Yeah, programming anything in teleop is really simple. The hard part is always autonomous, especially if you're planning to use vision.

RandomStyuff 05-04-2010 07:46

Re: why blame the programmers??
 
I guess I'm lucky then. In my team there is full understanding by all teams of the other teams. The mechanical is easy to understand, and the programmers understand the mechanical. A quick course on the electrical was given by me to all team members just before the start of the season (electrical is in programming team's turf here, although it's pretty much a cooperative thing).

The thing that makes my team slightly special is the understanding of programming: my school is called Aleh High School of Sciences, and as you can guess from the name, it's a pretty geeky school, where around half the students study computer science. As weird as it may seem, this year all of the 12th graders in my team except for one (our connectivity manager) major in Advanced Computer Science which includes in it a couple of university level courses. Next year, the two leaders of the Mechanical team are also Advanced Computer Science students, and the management will again be made up of almost exclusively Advanced CS students, with the only blacksheep being a girl who is doing the normal Computer Science course (cause she couldn't fit the advanced one into her schedule without taking out Chemistry or Physics)

The end result is a team which not only understands what code is, but can actually read it. This year when both my number two and I were gone for a few days during the season, a 12th grader from the Mechanical team came and took over temporarily in making sure the code is done. Our Mechanical manager even sat with me and helped me debug some code during a free hour once.

That doesn't always help though: we have a running joke that I'm probably to blame for (seeing as at the start of the season I was sure our programming team could do anything we wanted (which isn't too far from truth, we got the Innovation in Control award for some pretty awesome algorithms we implemented with our camera and and other impressive things like rewriting half of the WPI-libs stuff, including the low-level, and writing our own accumulator, to be able to get 3 gyros working on the robot.)). Every problem that comes up our Mechanical team's manager shouts "They'll fix it in software."
The climax came three hours before the shipping, when we discovered our scale was mis-calibrated, and that we were 7 kg overweight. Our mechanical team manager again shouted that we'll fix it in software :D (technically, if you write all the unused 0s into 1s there needs to be a positive charge, therefore the electrons leave for the battery, saving you the weight of an electron for each one.... sadly, the maximum you'd be able to save is about as equal to 1/10,000th of an atom... some bored kid did the math).

efoote868 05-04-2010 09:36

Re: why blame the programmers??
 
[sarcasm]The key to success is knowing who to blame for your failures.[/sarcasm]



If its the first time after the programmers touched the robot, it very well could be the programmer's fault.

If its the first time after the programmers touched the robot and its the first regional competition, it probably is the "programmer's fault", but its also the "team's fault" for not letting the programmers have access to a fully completed robot during the build season.

If its during the tenth match at competition and everything was working fine for all the other matches, and if the code didn't change between then, there is a high probability that it is NOT a programming fault, and it is electrical / mechanical.


I remember back in 2008 we had a solenoid that wouldn't work properly. We went from both ends of the spectrum - mechanical (replacing the solenoid) and programming (printf's in code to verify everything was as expected), followed the wires and met in the middle. Seating PWM cables in spikes are a real pain, this one jiggled out so it was only contacting two pins out of three. The spike would blink green-orange, but never go red.

Mrs.Drake343 05-04-2010 10:02

Re: why blame the programmers??
 
Our programmers have issues with always trying to make it better. We have threatened to duct tape their arms to their sides once the code is in and working properly...so they can't tweak it any more.

exprg:melonhead 05-04-2010 10:42

Re: why blame the programmers??
 
programmers get blamed only because it's so easy to say that what you are working on is flawless. for me, the first to blame is electronics whether it's right or wrong! if you don't understand it, it's easy to believe there is something wrong with it. simple as that.

thefro526 05-04-2010 10:47

Re: why blame the programmers??
 
People tend to blame things they don't understand... Most non-programmers don't understand programming, therefore they blame it for any problems they can't solve.

Strangely enough, I don't think enough people thank programmers... Without them, your robot wouldn't even move.

Mark McLeod 05-04-2010 10:56

Re: why blame the programmers??
 
Quote:

Originally Posted by Mrs.Drake343 (Post 948355)
Our programmers have issues with always trying to make it better. We have threatened to duct tape their arms to their sides once the code is in and working properly...so they can't tweak it any more.

I assume you do the same to your mechanical crew of course?
I'm firmly of the opinion that mechanical engineers and build crew should be shot at the end of week 5...:yikes:
Only pit crew should touch the robot for maintenance purposes after that...

That never happens though.

exprg:melonhead 05-04-2010 11:00

Re: why blame the programmers??
 
Quote:

Originally Posted by thefro526 (Post 948373)
Strangely enough, I don't think enough people thank programmers... Without them, your robot wouldn't even move.

thank you Fro! it amazes me that things that happen behind the curtain of building the robot can be taken for granted. my team just assumes that the robot will function properly. if they push the joystick forward, they expect the robot to move in that direction. i personally believe that the code is half of the robot. like you say, without it, you can't move. but to go from the other end, i take the electrical and mechanics for granted as well. generally, if we have the idea, i expect them to build it, and as soon as they do, i code it before we run the bot again. so i guess i'm kinda inversely guilty

FRC4ME 05-04-2010 11:01

Re: why blame the programmers??
 
Well, the programmers get blamed more often because, objectively, code error are responsible for more problems than mechanical errors.

But that's not really the programmers' faults. A recurring theme I've heard (and experienced) is that the builders will spend five weeks, six days, and twenty-three hours building the robot, then turn it over to the programmers and say: "alright, now download the code. What do you mean it doesn't work? You had six weeks to work on it!"

Unfortunately it doesn't quite work that way. ;)

PingPongPerson 05-04-2010 11:40

Re: why blame the programmers??
 
At least on my team, it's becuase when the programmers are testing the drive, they usually smash the robot into a wall at least 5 times. :)

Tom Line 05-04-2010 11:51

Re: why blame the programmers??
 
You say "Why blame the programmers?"

I say, why is any blame allowed on your team? Aren't you all working in the same direction, for the same goal, and doing your best? If so, then it's up to both the students and the mentors to very quickly correct the problem and explain to anyone who wants to perpetuate 'blaming' someone else that you are ONE team. Not a bunch of sub teams.

I had an emotional event with one of our students earlier this year when he said "xxxxx broke. As always." Now that he's gotten a little more involved with the TEAM I'd be shocked if I ever heard it again.

Remember. There is no controls team, no mechanical team, and no business team without The Team.

kamocat 05-04-2010 13:28

Re: why blame the programmers??
 
Here's some simple stuff:
Code doesn't break.
If the robot used to function, and now it doesn't, though the software hasn't been changed, then something in the hardware changed.
The code still works, but for a different setup.

Allowing the whole team to participate in troubleshooting requires two things:
  • clear communication
  • isolation of errors
It's generally true that singular components of the robot changed, not the robot as a whole. Clear communication is required to determine what was deliberately changed since the robot last worked, and what might have failed.

Of course, you're not actually done troubleshooting until the problem is fixed, and you know WHY it's fixed.

krudeboy51 05-04-2010 15:00

Re: why blame the programmers??
 
Quote:

Originally Posted by Tom Line (Post 948423)
You say "Why blame the programmers?"

I say, why is any blame allowed on your team? Aren't you all working in the same direction, for the same goal, and doing your best? If so, then it's up to both the students and the mentors to very quickly correct the problem and explain to anyone who wants to perpetuate 'blaming' someone else that you are ONE team. Not a bunch of sub teams.

I had an emotional event with one of our students earlier this year when he said "xxxxx broke. As always." Now that he's gotten a little more involved with the TEAM I'd be shocked if I ever heard it again.

Remember. There is no controls team, no mechanical team, and no business team without The Team.

i didn`t say it was happening on my team, i just thought it happens alot on other teams and wondered why!!!

GaryVoshol 05-04-2010 15:55

Re: why blame the programmers??
 
Arthur C Clarke's third law: "Any sufficiently advanced technology is indistinguishable from magic."

Since only the programmers understand the program, it is magic to the rest of the team. And since magic doesn't exist, the fault must be the programmers who created the magic. ;)

Code doesn't break. It reacts exactly the same time every time. When something new happens that never happened before, it's because the mechanicals, electricals or drivers gave the code some new stimulus that wasn't tested before. So it's the other teams' fault for not supplying enough test cases.

MikeE 05-04-2010 16:46

Re: why blame the programmers??
 
There are exactly* 3 reasons:

1) Intellectual. Software is conceptual not physical and therefore harder to understand than mechanics. As so many have said above, it's easy to blame something you don't understand and may be slightly frightened of.

2) Number and complexity of interfaces. There is far more to the software than just the code a typical team's programmers write. All of these other software components have bugs, undocumented assumptions, edge cases etc. and are not well documented.
The mechanics just interacts with itself, the carpet, a ball and maybe other robots.

3) Mentoring. Many teams have a no software engineers amongst the mentors, so students don't get advice on reliable design, robust coding practices, or understand how to manage the central strength/curse of software: it's flexibility (e.g. through configuration management).

* rhetorical license #MA32145

Yoel2630 05-04-2010 17:34

Re: why blame the programmers??
 
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 :p ), any other problem that may come up is really easy to pin on them :P

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

LukeS 05-04-2010 18:41

Re: why blame the programmers??
 
Quote:

Originally Posted by synth3tk (Post 947566)
Because most often, it is the programmer's fault.

I'm sorry our program cannot handle hardware failure as well as you would like. I'm sorry it can't detect that the kicker hit & broke the drive encoder. I'm sorry it can't detect that the latch is broken (as in holds, but for less than 1 sec) and that the loader arm needs to stay extended.

In seriousness though, it programming's fault 3 times.
1) I accidentally commented out `break;' in a series of 1-line cases. (dumb---- attack)
2) Andrew accidentally commented out `break;' in a (different) series of 1-line cases. (legit reason, was making changes on the fly at comp.)
3) We had a ``real'' bug. The code worked most the time, but failed to handle a fringe-case with censor input. I wish I could remember exactly what it was. I wrote this part of the code

stipulation: If a hardware change is made that necessitates a code change, but the programmers are not informed of this, it is not programming's fault.
stipulation: If the programmers were not correctly informed of what the code should make the hardware do, yes you can maybe blame programming a bit. But it is not a `code problem'. The code is perfect. It does what we tell it to. Any incorrect behavior is because we told it to do the wrong thing. We have 2 exceptions to this. If we told the code to do the wrong thing it is probably because physical told us the wrong thing. We have one exception to this.

Quote:

Originally Posted by AmoryG (Post 947555)
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.

Yes, but:
1) we haven't changed the code since yesterday, when it was working.
2) when we did change the code before that, it had nothing to do with what broke
3) no, there is no chance that it no longer has code on it. It went out and ran, didn't it?
Therefore, the sensor broke, the wire came out, or you burnt out the motor.

ideasrule 05-04-2010 18:48

Re: why blame the programmers??
 
There IS one possible coding problem if the robot suddenly breaks after working for 10 matches: race conditions. It's hard to have a race condition with robot code, but it's one thing to keep in mind when coding or debugging.

cheesepuffgd 05-04-2010 19:07

Re: why blame the programmers??
 
since the the code is invisible to mechies and electrical, they blame programming because programming is easy to blame
:mad: :mad: :mad: :mad: :mad:

dag0620 05-04-2010 19:30

Re: why blame the programmers??
 
The same problem arose at CT.

It was the practice rounds. Our Autonomus program (the part of the code I was responsible for this year) has a limit switch rigged up to some mechanics, which when the robot approaches the lined up balls, has the kicker kick (obviously more to it then that). But for some reason it wasnt working.

Obviusly to some degree there was pointing of fingers, but it was more or less everyones theories, as no one really was denying it could be there fault. So as the mechanical team checked mechanics and Electrical, my partner in Crime and I checked over our work. After cooperation with the members of both areas, we found a metal chip in the wiring, which was causing the problem.

So yes we had the pointing issue, but we did work together and fixed what the problem.

LukeS 05-04-2010 21:22

Re: why blame the programmers??
 
Quote:

Originally Posted by ChrisH (Post 947691)
Quote:

Originally Posted by CMSD (Post 947641)
...of course, the code was automatically blamed, and later proved to be completely flawless :D

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 :p

Well, of course: performance issues. Fortunately, we are dealing with an RTS, which means it doesn't need to perform well, just `well enough'.

Seriously though, missing features. We made this code work, so we didn't get to the [x cool feature] (camera, gyros, accelerometers)

There will always be flaws, however, it is a skill to control where they are. What he means is that the relevant portion of the code was flawless.

Quote:

Originally Posted by Andrew Schreiber (Post 947615)
The programmer should not rule out a code issue in any circumstances that they cannot back up that with definitive proof. No, "Because I wrote it" is not proof.

When I say this, it is said in good humor, although it usually ends up being true. And, even while I say it, I am usually running though the code, checking out if it could be a code issue. (It's even become sort of a good humored routine to blame programmers, then for us to retort).

What bothers me is when we know it can't be code for whatever reason (see the 2nd part of my above post), and people still insist it is. When I say, ``Look, trust me, I have considered this. It's not code.'' please trust me. I know what I'm talking about. Sure I'll check it again, but that's not going to be it, so don't waste both of our time, have someone else be checking other stuff too. Don't make them move so I can prove to you that it is not code.

FRC4ME 06-04-2010 00:17

Re: why blame the programmers??
 
Quote:

Originally Posted by LukeS (Post 948823)
What bothers me is when we know it can't be code for whatever reason (see the 2nd part of my above post), and people still insist it is. When I say, ``Look, trust me, I have considered this. It's not code.'' please trust me. I know what I'm talking about. Sure I'll check it again, but that's not going to be it, so don't waste both of our time, have someone else be checking other stuff too. Don't make them move so I can prove to you that it is not code.

Lol. Earlier this year the programmers experienced this on my team. One of the drivers insisted that the left joystick of the tank steering was causing both sides of the tank drive to spin, rather than just the left side. So three programmers set out to prove it wasn't a coding issue: two lifted the robot off the ground while one moved the left joystick forward and back. Sure enough, only the left side moved. They then said, "see? mechanical problem," put the robot down, and went back to work. :D

Although I remember the time on 339 when a Victor burst into flames. All of the programmers (myself included) turned to the lead mechanical mentor and said, with confidence, "hardware problem!" It was rather funny at the time. :p

EDIT - Oh, and I saw this once:
Me: "The left motor needs to be reversed, but other than that, everything works well."
Electrical: "We can fix that in hardware!"
Programming: "We can fix that in software!"

<five minutes later>

Me: "Umm...the left motor is still reversed."
Electrical: "We fixed that!"
Programming: "We fixed that!"
Me: <facepalm>

:p

Al3+ 06-04-2010 01:27

Re: why blame the programmers??
 
Quote:

Originally Posted by FRC4ME (Post 948975)
EDIT - Oh, and I saw this once:
Me: "The left motor needs to be reversed, but other than that, everything works well."
Electrical: "We can fix that in hardware!"
Programming: "We can fix that in software!"

<five minutes later>

Me: "Umm...the left motor is still reversed."
Electrical: "We fixed that!"
Programming: "We fixed that!"
Me: <facepalm>

:p

Happened to our team too. Actually it was more complex. We had two independently driven motors on each side, and just one motor out of four was reversed. Not realizing this, we flipped the entire side, so the other one on that side was now reversed. Then the electronics changed the wiring on the first one, making the whole side reversed.

Also the drivers once went into a match with the joysticks backward. He mentioned to me afterward the confusion this caused, and I almost went to fix the direction until he clarified that it wasn't the drive that was reversed.

demosthenes2k8 07-04-2010 00:15

Re: why blame the programmers??
 
Sadly, this happened a LOT on our team this year. Software received the robot Thursday before ship, and had what little time remained to get the code working on it. It worked (mostly) for unveiling, but mechanical kept changing how things were going to work throughout build season.

And then came competition-GSR.

One particular example of software getting unfairly blamed was when we went to go into a practice match, with a robot that we had JUST been running in the pit, and spent all ten minutes trying to get communications. After we left without getting anything done, the mechanical lead looked like he was ready to kill the software lead (me). I found out after I left for lunch that they had unplugged the camera and plugged the special practice gaming adapter into its port. Not software, they shouldn't even have been touching that wire!

I agree that software gets blamed because software doesn't really have anything concrete to show, unlike the other subteams. However, I think that a bit more mutual respect would be a good idea. It's rather annoying to have subteams blaming each other for everything instead of working, and always assuming that it's never their fault. Especially when it IS their fault that software doesn't get the robot until really late.

FRC4ME 07-04-2010 00:31

Re: why blame the programmers??
 
Quote:

Originally Posted by Al3+ (Post 949022)
Also the drivers once went into a match with the joysticks backward. He mentioned to me afterward the confusion this caused, and I almost went to fix the direction until he clarified that it wasn't the drive that was reversed.

As I recall, when I first joined 619, their programmer showed me a feedback loop from a while back that involved a total of seven reversals: the joystick inputs were reversed in the getters and at the point of use, the motor outputs were reversed in the setters and at the point of use, the feedback was reversed in the getter and at the point of use, and an intermediate calculation was multiplied by -1.

Since then we've made sure to define conventions - gyro spinning clockwise should be positive, motor going forward should be positive - and ensure step-by-step that all of the hardware code follows them.

Alan Anderson 07-04-2010 00:44

Re: why blame the programmers??
 
For any of you programmers musing about the invisibility of software, here's a concrete suggestion to make it easier for the non-programmers to relate: give your software a way to show itself. You should at minimum be able to show the value of each sensor on either the Dashboard or the Driver Station "LCD screen" display. Any internal states should similarly be exposed for diagnostic purposes.

Consider it "defensive programming" -- done properly, you can quickly see if any sensors are not behaving properly, and tell the electrical team where to focus their attention before they start pointing fingers at the software.

jmanela 07-04-2010 23:19

Re: why blame the programmers??
 
Quote:

For any of you programmers musing about the invisibility of software, here's a concrete suggestion to make it easier for the non-programmers to relate: give your software a way to show itself. You should at minimum be able to show the value of each sensor on either the Dashboard or the Driver Station "LCD screen" display. Any internal states should similarly be exposed for diagnostic purposes.

Consider it "defensive programming" -- done properly, you can quickly see if any sensors are not behaving properly, and tell the electrical team where to focus their attention before they start pointing fingers at the software.
And if they still don't believe you, what i would do is show the non-programmers an example of example code that should be proven to work. (assuming you use LV, i'm not sure if they give examples for other languages, but you could always look on CD :rolleyes: ). This is another great way to test out sensors and say, hey if this doesn't work, then something else is messed up.

Also, utilize those blinking lights on the C-RIO. For example, when we I was programming the kicker function (our kicker uses two solenoids and a latch to give a pressurized kick), and tested it, it worked the first few times. However, eventually it stopped working. If you look on the solenoid module on the c-rio, there is a set of lights for the solenoids and they light up when they are activated by the program. I showed everyone else (non-programming) that when the kicker worked, or did not, the lights would light up in the same pattern with the same timing. It turned out to be a mechanical problem.

bassoondude 07-04-2010 23:28

Re: why blame the programmers??
 
This is why my team doesnt have subteams of any sort. while not all of us are programmers (actually, most of us arent) we all work on just about every other part of the bot, so we never lay blame on anyone or any group of people. If we seriously cant find a problem, we then blame our programmer, who usually finds the lose wire or faulty circuit breaker that was the real cause of the problem. Moral of the story: ITS NEVER THE PROGRAMMERS FAULT! (unless it is)

TD912 08-04-2010 00:25

Re: why blame the programmers??
 
Quote:

Originally Posted by jmanela (Post 949797)
Also, utilize those blinking lights on the C-RIO.

We went to the practice field, and our pneumatic kicker didn't work when the joystick trigger was pressed. I start getting blamed for changing something in the code. I quickly looked at the lights on slot 8 of the cRIO, where the pneumatics bumper plugs in. Pressing the trigger caused them to turn on.

Turns out someone was working on the electricals and unplugged a solenoid...

Robototes2412 08-04-2010 00:58

Re: why blame the programmers??
 
yeah, solenoids are a [pain],

make sure you call them formally as such:
Code:

Solenoid kicka = new Solenoid(8,1);
and not informally, or as such:
Code:

Solenoid kicka = new Solenoid(1);
Don't let the cRIO program for you, its a dumb terminal, it wont do stuff right.

timothyb89 08-04-2010 02:31

Re: why blame the programmers??
 
I'd have to agree with something that's been said here a ton: The hardware guys don't see/understand the code most of the time, they're quicker to blame the thing they don't understand.

It naturally happened a lot this year for us and essentially it came down to a 50/50 split between being the code or not. Eventually the team learned to put up with it and the hardware guys got to be pros at checking wire conductivity when a motor/solenoid/sensor/whatever stopped working and we eventually were able to work out a good debugging processes between the mechanical and programming team.

But I think the most awesome thing that happened (cooperation-wise) was that (a week or two ago) a few people from the mechanical/drive team came to ask the programmers for coding lessons. Essentially, they had wanted to understand the code so they could figure out whether it was a mechanical or programming issue without jumping to conclusions.

As the programmers do most of the electrical work as well, I think most of our team understands what the others are doing. Short of teaching the non-programmers how to code, we've historically tried to make sure to explain important info about how the code workd to the mechanical team. At the very least we want to make sure everyone understands (and agrees!) with our reasoning when we say "it isn't the code!".

The communication really helps though. I know I'm probably wrong about half the time (*cough*), and running my reasoning by someone else- programmer or not- is a great way to see weed out logic problems and fix issues faster.

synth3tk 08-04-2010 11:52

Re: why blame the programmers??
 
Quote:

Originally Posted by Robototes2412 (Post 949833)
and not informally, or as such:
Code:

Solenoid kicka = new Solenoid(1);
Don't let the cRIO program for you, its a dumb terminal, it wont do stuff right.

Worked fine for us. Is there any performance-hindrance reason not to use this call?

Radical Pi 08-04-2010 12:22

Re: why blame the programmers??
 
There isn't really any performance issues with that, it just re-calls the function with the slot explicitly defined. I think the point was that you are assumming the library has it right

synth3tk 08-04-2010 12:45

Re: why blame the programmers??
 
Ahh, ok. Thanks for the explanation.

Jason Law 08-04-2010 23:34

Re: why blame the programmers??
 
Quote:

Originally Posted by jmanela (Post 949797)
And if they still don't believe you, what i would do is show the non-programmers an example of example code that should be proven to work. (assuming you use LV, i'm not sure if they give examples for other languages, but you could always look on CD :rolleyes: ). This is another great way to test out sensors and say, hey if this doesn't work, then something else is messed up.

Also, utilize those blinking lights on the C-RIO. For example, when we I was programming the kicker function (our kicker uses two solenoids and a latch to give a pressurized kick), and tested it, it worked the first few times. However, eventually it stopped working. If you look on the solenoid module on the c-rio, there is a set of lights for the solenoids and they light up when they are activated by the program. I showed everyone else (non-programming) that when the kicker worked, or did not, the lights would light up in the same pattern with the same timing. It turned out to be a mechanical problem.

except when the example code doesn't work... Hn... Compressor code with solenoid week 4?! It's alright Josh, youlearned for next time.

Agreed the kicker was definitely programmed correctly. Notice how nobody blamed you? We found out quickly that it actually was an electrical, pneumatic, mechanical problem. So I took 99% blame and fixed all 3 areas.

Also, from my limited experience, everything goes a lot smoother If the lines between subteams are very small. For example, I am on the mechanical team, but I can adequately do all of the eletrical and pneumatics too. I even managed to figure out how to inverse things and call different joystick inputs and stuff in labview. When our much needed programmer was gone for the night, I "magically" rearranged some things in the program (yes I did know what I was doing). Of course, our programmer checked it first thing when he came back. Having a person who knows how to do multiple areas can avoid for a 10 minute battle of this subteam did it, etc.

And, no. If someone gave me a blank VI to program the robot, I would just look at them, laugh, and call Josh. Lastly, our team values oUr programmers. Without them, our robot would never work very well.

Andrew Y. 08-04-2010 23:45

Re: why blame the programmers??
 
from a mentors point of view:

(WARNING...im a mechanical type of guy)

we usually hated on electrical...until we found out they could put pretty lights that flash on our robot...so now programmers are to blame for all things.

Robototes2412 08-04-2010 23:58

Re: why blame the programmers??
 
i remember making lights flash on and off on my team's robot, controlled by a button. I claimed they activate when an error occurs, i had a lot of programming bugs, and had to take the lights off :(

BigJ 09-04-2010 00:03

Re: why blame the programmers??
 
To go with what other posters are saying:
  • Program defensively. Make sure you can put your numbers where your mouth is.
  • Make an effort to understand exactly what your code is doing so that you are usually not in a situation where you go "Oh... I never thought of that."
  • Make an effort to understand exactly what the intended mechanics/pneumatics/etc are supposed to be doing. Sometimes you can meet them in the middle way easier than making them do it over. Remember, mechanical are your friends, no matter what lack of hours they let you have on the robot.
  • Never assume it isn't the code. I can't tell you how many times it WAS the code. *sigh*...
  • Always strive to improve your methods. Come up with a good documentation and output setup so that new programmers can be easily integrated into your team's development. That way when mechanical asks the rookie programmer something, they don't always have to point at you. :)

jmanela 09-04-2010 09:09

Re: why blame the programmers??
 
Quote:

Originally Posted by Jason Law (Post 950567)
except when the example code doesn't work...

Solenoid Test Vi was just a freak of nature...

BACONDUDE1902 09-04-2010 09:32

Re: why blame the programmers??
 
but programmers got the power!!!!!!!!!!!!!! :yikes:

Racer26 09-04-2010 09:42

Re: why blame the programmers??
 
The one I always find happens with me, is the robot code works flawlessly for 4 or 5 matches, then spontaneously STOPS working properly. I get told to check the code, and my response is invariably "code doesn't change on its own, if it worked before, then one of its inputs has changed, or ceased functioning" Its often that an encoder has died, or something along those lines.

gvarndell 09-04-2010 10:55

Re: why blame the programmers??
 
Quote:

Originally Posted by krudeboy51 (Post 947546)
im wondering, if anything goes wrong with the robot why blame the programmers??(any suggestions, comments or ideas??)
:confused:

If you intend to become an embedded systems software developer, then you either get really good at proving it's not the software or you're doomed to forever be a whipping post for the hardware folks. :o
Defensive coding and stellar debugging skills will prevent wasting years of your career in the finger pointing game and will make you quite valuable to boot.

Racer26 09-04-2010 14:08

Re: why blame the programmers??
 
Quote:

Originally Posted by gvarndell (Post 950747)
If you intend to become an embedded systems software developer, then you either get really good at proving it's not the software or you're doomed to forever be a whipping post for the hardware folks. :o
Defensive coding and stellar debugging skills will prevent wasting years of your career in the finger pointing game and will make you quite valuable to boot.

QFT. I graduated my FRC team, went on to get a Bachelor of IT, and now work for a company doing PC and embedded software. I regularly get blamed when it breaks.

cheesepuffgd 09-05-2010 23:28

Re: why blame the programmers??
 
Quote:

At least on my team, it's becuase when the programmers are testing the drive, they usually smash the robot into a wall at least 5 times.
that was one time!!!!

TStark115 20-01-2011 16:05

Re: why blame the programmers??
 
It's not aways their fault and most of the time it's not.

billbo911 20-01-2011 16:47

Re: why blame the programmers??
 
Why? Because as part of the mechanical team, we can't possibly blame ourselves.

dag0620 20-01-2011 17:33

Re: why blame the programmers??
 
Ohhh I was dreading the comeback of this thread!

I've come to the conclusion, it's the age old story, and every team has it, and no-one will ever win it.

But I will admit, as a programmer, we mostly do the bidding of the Design and Mech Teams. I think outside of the Control Board and Autonomous, we have no creative control.

One day the code will be written first, and then a robot built around it :P

davidalln 20-01-2011 18:07

Re: why blame the programmers??
 
Quote:

Originally Posted by Andrew Y. (Post 950573)
from a mentors point of view:

(WARNING...im a mechanical type of guy)

we usually hated on electrical...until we found out they could put pretty lights that flash on our robot...so now programmers are to blame for all things.

Your programmer made those pretty light pulsate over time during the match. Continue blaming electrical.

PAR_WIG1350 20-01-2011 19:42

Re: why blame the programmers??
 
Quote:

Originally Posted by davidalln (Post 1004494)
Your programmer made those pretty light pulsate over time during the match. Continue blaming electrical.

Unless a 555 was involved. But honestly, I find that problems are evenly distributed throughout the robot. However, Magic smoke, the smell of melting stuff, a chain that has come off its sprocket, and binding gears are really obvious. A sign error, or a missing increment/decrement operator, on the other hand, can be difficult to track down, and those are just simple, easily solved problems. more complex errors, such as accidentally causing a function to fail to execute by making the conditions it would normally execute under impossible (such as
Code:

void myfunction (void)
int main()
{
    int nvar=0;
    if nvar>1
    { 
        myfunction ();
        nvar=0;
      }
      else
      {
      }
      //...
}

and elsewhere you had a function in which an error increments nvar by 1 such that every 2nd error triggers myfunction, but you removed that section of the code, now whatever crucial task myfunction does to fix the error never occurs, and the errors just continue on to oblivion. But just by looking at the code, it would be hard to diagnose that.

Thus, the programmer's aren't blamed more often, they just have to do more work to find the problem before thy can even begin to fix it, thus it seems like they are always getting asked to fix things, since they are always working.

davidthefat 20-01-2011 20:05

Re: why blame the programmers??
 
Honestly, it only takes one integer or one symbol to make your robot go hay wire. But that only takes a second to fix. If it is mechanical failure, it is harder to fix. So people are being optimistic and blaming the one that is easier to fix. That is what I have learned from my experiences in the club.


All times are GMT -5. The time now is 13:36.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi