![]() |
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. |
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:
Of course, you're not actually done troubleshooting until the problem is fixed, and you know WHY it's fixed. |
Re: why blame the programmers??
Quote:
|
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. |
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 |
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 :) |
Re: why blame the programmers??
Quote:
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:
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. |
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.
|
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: |
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. |
Re: why blame the programmers??
Quote:
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:
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. |
Re: why blame the programmers??
Quote:
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 |
Re: why blame the programmers??
Quote:
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. |
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. |
Re: why blame the programmers??
Quote:
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. |
| 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