Breaking News
Comments
Newest First | Oldest First | Threaded View
<<   <   Page 2 / 3   >   >>
J Kosin
User Rank
Rookie
re: It always worked before, so you broke it
J Kosin   5/27/2011 2:38:59 PM
NO RATINGS
Yes, sometimes it is both. But we mustnot start pointing fingers before exploring the problem and what the cause is. I recently spent two days troubleshooting a problem and have worked with the HW engineer to try and determine the cause. So far, we have elimiated SW as being a possible cause to the issue.

J Kosin
User Rank
Rookie
re: It always worked before, so you broke it
J Kosin   5/27/2011 2:35:47 PM
NO RATINGS
The software guy looses respect, because he caused the product to be late in the first place. It doesn't matter if it was a HARDWARE problem, we get the short end of the stick; because we fixed the problem after everyone said the product was ready to ship.

GarySXT
User Rank
Freelancer
re: It always worked before, so you broke it
GarySXT   5/26/2011 5:51:42 PM
NO RATINGS
In the groups I manage, when there is a bug both hardware and software are considered guilty until proven innocent. Hardware and software engineers are expected to work as a team. As mentioned above software often fixes hardware problems. Also hardware debugging techniques are sometimes helpful in tracking down a software bug. Management should not allow the different disciplines to blame each other.

cdhmanning
User Rank
Rookie
re: It always worked before, so you broke it
cdhmanning   5/23/2011 6:48:51 PM
NO RATINGS
Why should the software guys lose respect? Make sure that it does not get framed that way. Make sure that the software guys get the credit for turning around a multi-million dollar loss. If you want recognition in a company then the best way to do that is to make an association between what you do and the performance of the company. Demonstrate **value**. In your performance review, point out the value of what you did.

Bob Lacovara
User Rank
Rookie
re: It always worked before, so you broke it
Bob Lacovara   5/23/2011 5:27:14 PM
NO RATINGS
Mr. Fyock, welcome to the monkey house. Your best strategy would have been to quit, although for sure that is not always a feasible solution. Since idiotic management and moronic sales types have a tendency to butt into engineering (software and hardware) you might want to consider this advice that I was once offered: "the time to start looking for a job is the day you land your new one." Sounds cynical? Wait until you've been in the field for, let's see, 11 minus 74, ah, 37 years, and consider it again. Well, in any event, we've all been there...

DutchUncle
User Rank
Rookie
re: It always worked before, so you broke it
DutchUncle   5/23/2011 12:41:41 PM
NO RATINGS
The trouble is, when you find a software WORKAROUND (emphasis important) to a hardware PROBLEM, and all that people remember is "we had to rev the software to fix it", the software side loses respect - including at review time.

cdhmanning
User Rank
Rookie
re: It always worked before, so you broke it
cdhmanning   5/23/2011 3:14:40 AM
NO RATINGS
There are two reasons for that: 1) It is relatively easy to see how hardware works and much harder to see how software works. That means people will always tend to believe the problem is where they can't see it (ie. in the software). 2) It is also a matter of hope. Software errors can be fixed on short deadlines, but not hardware errors. Thus management/sales people always hope it is a software problem. When a product is on stop ship they will readily believe anything that gives them hope that a solution is at hand. Even if it is not really a software problem, there is often a software solution. Whenever this happens it becomes a software problem. I once had to fix a lubrication problem in software. Without that, many idetms would have had to be recalled and scrapped costing the company a few hundred thousand dollars. On another occasion a mechanical stop was repositioned. This could have cost approx $100k and 4 months to fix mechanically meaning the company would have lost a few million in sales. I fiddled for a day and found a software solution. At the end of the day, all that matters is that a solution is found. The customer doesn't care what is broken or who's fault it is. Just work together to find a solution. Everyone is trying to earn money for the same company.

WKetel
User Rank
Rookie
re: It always worked before, so you broke it
WKetel   5/21/2011 12:40:48 AM
NO RATINGS
Nobody has an exclusive right to make the mistakes, that is for certain. The problems arise when either the product definition is fuzzy, or the designer makes a mistake, or the builders don't follow the drawings. The funniest one that I experienced was a fairly simple circuit that I had designed and then built. I carefully selected the resistors to all be in the middle of where they needed to be. But when the production model was built, it was miles out of specifications. The problem eventually was traced to the arrogant detailers who did the circuit drawing. They corrected the "Mistake" made by "That dumb engineer", and added the "K" that I had neglected to put on several low value resistors. So instead of 22 ohms and 470 ohms there was 22,000 ohms and 470,000 ohms. The shortcoming of my designs are that they don't work as intended unless they are built as designed. This was reported to my manager at my next performance review, when the problem with that product was brought up. The response was "OH".

Alan60
User Rank
Rookie
re: It always worked before, so you broke it
Alan60   5/20/2011 9:29:31 PM
NO RATINGS
Been there, done it, got the company golf shirt. Years ago we had a hydraulic problem, excess pressure when braking. The redesign fix was messy, even for hydraulics. The $1M machine was down and people were not happy. I suggested a SW workaround to control deceleration, which we did and were soon back up running. However, word got around that I had to fix the SW to get the machine running. Unfortunately now I have to think twice before helping others.

DutchUncle
User Rank
Rookie
re: It always worked before, so you broke it
DutchUncle   5/20/2011 8:10:24 PM
NO RATINGS
Sometimes this is all in the software domain. Reviewing DOS driver code while writing new interface code on an ISA plug-in board, I found some code that seemed to have a race condition and asked about it. Since this had been written by one of the original product group, now a technical leader, and had been working for years, my question was disdained and dismissed out of hand. A mere few months later, intractable customer problems were blamed on my interface code. I finally traced it back the the same DOS driver code. Turned out this was the first customer PC system we had seen at whatever speed it was (500 MHz?) and it was the first time that the PC was fast enough to catch the race condition. Now it was still my fault for not having pushed harder when I found the problem before.

<<   <   Page 2 / 3   >   >>


EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

Aging Brass: Cow Poop vs. Horse Doo-Doo
Max Maxfield
9 comments
As you may recall, one of the things I want to do with the brass panels I'm using in my Inamorata Prognostication Engine is to make them look really old. Since everything is being mounted ...

EDN Staff

11 Summer Vacation Spots for Engineers
EDN Staff
11 comments
This collection of places from technology history, museums, and modern marvels is a roadmap for an engineering adventure that will take you around the world. Here are just a few spots ...

Glen Chenier

Engineers Solve Analog/Digital Problem, Invent Creative Expletives
Glen Chenier
11 comments
- An analog engineer and a digital engineer join forces, use their respective skills, and pull a few bunnies out of a hat to troubleshoot a system with which they are completely ...

Larry Desjardin

Engineers Should Study Finance: 5 Reasons Why
Larry Desjardin
45 comments
I'm a big proponent of engineers learning financial basics. Why? Because engineers are making decisions all the time, in multiple ways. Having a good financial understanding guides these ...

Flash Poll
Top Comments of the Week
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)