Breaking News
Engineering Investigations

It always worked before, so you broke it

TFCSD
5/18/2011 05:22 PM EDT

 28 comments   post a comment
NO RATINGS
View Comments: Oldest First | Newest First | Threaded View
<<   <   Page 3 / 3
t.alex
User Rank
Author
re: It always worked before, so you broke it
t.alex   5/29/2011 1:07:22 PM
NO RATINGS
Isn't it true most of the time the sw guy do the test and debugging instead of the hardware?

zeeglen
User Rank
Author
re: It always worked before, so you broke it
zeeglen   5/29/2011 4:53:51 PM
NO RATINGS
Depends on what is being tested and debugged.

jsandjs
User Rank
Author
re: It always worked before, so you broke it
jsandjs   6/9/2011 11:03:27 PM
NO RATINGS
This is the second story about the hardware induced noise I read here. Since noise mixed in a signal is so common and most of the time it is random, problems happen here and there somehow give a hint, even not strong and clear. A specific software in general will hardly produce random troubles here and there.

DutchUncle
User Rank
Author
re: It always worked before, so you broke it
DutchUncle   6/10/2011 12:29:50 PM
NO RATINGS
Fresh real-life example: A few weeks ago I released code that worked exactly as expected on prototype hardware. When used on the next board-spin of prototypes, it didn't work, which of course meant it was a software fault. Yesterday it was proven that not only was the circuit changed, but a wrong part had been used on the dozen proto builds, so it wasn't even the proper changed circuit. Put in the right part, and the software works again. Gee, what a concept.

oster
User Rank
Author
re: It always worked before, so you broke it
oster   11/3/2012 12:35:08 AM
NO RATINGS
The solution seems to be that SW guys need to learn more HW skills and vice versa. It's the ones that are at ease straddling disciplines that bridge the divide and I've certainly seen this in action.

The Gen
User Rank
Author
re: It always worked before, so you broke it
The Gen   6/16/2013 8:28:11 AM
NO RATINGS
I worked for a company for 12 years designing a range of fibre optic switches. (check out the spelling of fibre!) My bit was the opto-mechanics. I can sympathise deeply with the sentiments in these posts. Guys, I feel your pain. One of the posts earlier mentioned that it is obvious when mechanics isn't working, but not so software and electronics. In the fibre switch, the mechanics was small and delicate, and small mechanical disturbances (thermal, vibration, electrical noise) could make a difference but it wasn't obvious by observation. When there was a problem the blame was assigned thus:- 1. it's a mechanical problem, the mirror is in the wrong place (it was once many years previously but not on the five plus subsequent problems) 2. Right, the mechanics is OK, must be an electrical problem 3. Right the electrics is OK, must be a software problem Usually the 'head in charge would decide on what the root cause was and waste time and money trying to fix something that wasn't broken. The three disciplines had enough respect for each other to get on and sort the problem (eventually when the management "help" had evaporated when the solution was looking intractable) Oh, and I relate to the story above about the saw project that was estimated to take 2 months scheduled to be done in one month and quoted to the customer as 2 weeks. I don't work for that company any more :-)

TFCSD
User Rank
Author
It always worked before, so you broke it: 2015 Update
TFCSD   10/25/2015 4:40:32 AM
NO RATINGS
Sweet. Ten years later after I worked for a certain solution “froward” company that my EEtimes story was based. In a recent 2015 interview one of those special people, who is no longer with said company, told an interviewer something that was strange and likely not true, if what was said was really said and not redacted. I asked for clarification from the interviewer about what was said or if they even had the right person and the interviewers are being tight lipped about who spewed. Just goes to show that if you do the right thing for an employer and they ultimately benefited, the ex-sycophants still years later whine that their obtuse behinds which they roasted in the fire for years was scorched and was my fault because I came by and pointed out they may be happier turning around. Makes me wonder how many other of my interviews/jobs these people have ruined over ten years.

perl_geek
User Rank
Author
Extended understanding
perl_geek   10/26/2015 3:23:10 PM
NO RATINGS
Most of us work in some sort of chain, (or tower, if you prefer), producing work that depends on others, and is in turn depended on. (E.g. business or functional logic encoded in software that depends on hardware to work. I've always felt it desirable to have at least an outline understanding of the neighbouring fields. Hardware people need to know something about physics and chemistry on one side, and software on the other. Similarly, software types need to know a bit of hardware and some business, and so it goes on.

<<   <   Page 3 / 3

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed