Breaking News
Comments
Newest First | Oldest First | Threaded View
Page 1 / 3   >   >>
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.

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.

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

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.

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.

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.

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.

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?

t.alex
User Rank
Author
re: It always worked before, so you broke it
t.alex   5/29/2011 1:06:15 PM
NO RATINGS
It is important the sw guy pick up some hardware debugging to prove themselves 'innocent' :)

LiketoBike
User Rank
Author
re: It always worked before, so you broke it
LiketoBike   5/27/2011 6:26:01 PM
NO RATINGS
Software and hardware are often trained by management to blame each other :-) (As in: when the "real" mission to create and ship and SUCCEED [as a team] is derailed into the "fake" mission to grab credit and avoid fault, this blame-game usually results...)

Page 1 / 3   >   >>


Radio
LATEST ARCHIVED BROADCAST

What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.

Brought to you by:

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Like Us on Facebook
Special Video Section
With design sizes expected to increase by 5X through 2020, ...
01:48
Linear Technology’s LT8330 and LT8331, two Low Quiescent ...
The quality and reliability of Mill-Max's two-piece ...
LED lighting is an important feature in today’s and future ...
05:27
The LT8602 has two high voltage buck regulators with an ...
05:18
Silego Technology’s highly versatile Mixed-signal GreenPAK ...
The quality and reliability of Mill-Max's two-piece ...
01:34
Why the multicopter? It has every thing in it. 58 of ...
Security is important in all parts of the IoT chain, ...
Infineon explains their philosophy and why the multicopter ...
The LTC4282 Hot SwapTM controller allows a board to be ...
This video highlights the Zynq® UltraScale+™ MPSoC, and sho...
Homeowners may soon be able to store the energy generated ...
The LTC®6363 is a low power, low noise, fully differential ...
See the Virtex® UltraScale+™ FPGA with 32.75G backplane ...
Vincent Ching, applications engineer at Avago Technologies, ...
The LT®6375 is a unity-gain difference amplifier which ...
The LTC®4015 is a complete synchronous buck controller/ ...
10:35
The LTC®2983 measures a wide variety of temperature sensors ...
The LTC®3886 is a dual PolyPhase DC/DC synchronous ...