![]() |
why blame the programmers??
im wondering, if anything goes wrong with the robot why blame the programmers??(any suggestions, comments or ideas??)
:confused: |
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... |
Re: why blame the programmers??
Because it's their fault.
|
Re: why blame the programmers??
Quote:
:rolleyes: Typical, most complaining about software was from either mechanical or electrical guys... |
Re: why blame the programmers??
The trick is to train the rest of the team to blame electrical instead.
|
Re: why blame the programmers??
Quote:
|
Re: why blame the programmers??
Quote:
|
Re: why blame the programmers??
Quote:
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. |
Re: why blame the programmers??
Quote:
|
Re: why blame the programmers??
Because most often, it is the programmer's fault.
|
Re: why blame the programmers??
Typically, a program has many more points of failure than a mechanical or electrical system.
|
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. |
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.
|
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 |
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:
|
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.
|
Re: why blame the programmers??
Quote:
SOLUTION: Build a practice bot. -Nick |
Re: why blame the programmers??
Quote:
True fact. |
Re: why blame the programmers??
Quote:
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. |
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. |
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. |
Re: why blame the programmers??
Quote:
|
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. |
Re: why blame the programmers??
Quote:
|
Re: why blame the programmers??
Quote:
|
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! |
Re: why blame the programmers??
Quote:
|
Re: why blame the programmers??
Quote:
|
Re: why blame the programmers??
We blame electrical :]
|
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
|
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. |
Re: why blame the programmers??
Quote:
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 |
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 |
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. |
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 |
Re: why blame the programmers??
Quote:
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... |
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! |
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.
|
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. |
Re: why blame the programmers??
Quote:
|
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.
|
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 |
Re: why blame the programmers??
Quote:
Quote:
|
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.
|
Re: why blame the programmers??
Quote:
Quote:
I'm just lightheartedly expressing how often it seems that programmers investigate an issue only to discover an underlying electrical problem. |
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. |
Re: why blame the programmers??
Quote:
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. |
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! |
Re: why blame the programmers??
Quote:
|
Re: why blame the programmers??
Quote:
|
Re: why blame the programmers??
Quote:
|
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). |
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. |
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.
|
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.
|
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. |
Re: why blame the programmers??
Quote:
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. |
Re: why blame the programmers??
Quote:
|
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. ;) |
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. :)
|
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. |
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. |
Re: why blame the programmers??
Quote:
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. |
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)
|
Re: why blame the programmers??
Quote:
Turns out someone was working on the electricals and unplugged a solenoid... |
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);Code:
Solenoid kicka = new Solenoid(1); |
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. |
Re: why blame the programmers??
Quote:
|
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
|
Re: why blame the programmers??
Ahh, ok. Thanks for the explanation.
|
Re: why blame the programmers??
Quote:
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. |
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. |
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 :(
|
Re: why blame the programmers??
To go with what other posters are saying:
|
Re: why blame the programmers??
Quote:
|
Re: why blame the programmers??
but programmers got the power!!!!!!!!!!!!!! :yikes:
|
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.
|
Re: why blame the programmers??
Quote:
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. |
Re: why blame the programmers??
Quote:
|
Re: why blame the programmers??
Quote:
|
Re: why blame the programmers??
It's not aways their fault and most of the time it's not.
|
Re: why blame the programmers??
Why? Because as part of the mechanical team, we can't possibly blame ourselves.
|
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 |
Re: why blame the programmers??
Quote:
|
Re: why blame the programmers??
Quote:
Code:
void myfunction (void)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. |
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