Everybody blames the software when something goes wrong. Are software engineers just put-upon? Turns out, they deserve it.

Everybody always blames the software. The phones go out? Software glitch. Your clock can't keep up with Daylight Savings Time (as I outlined in an earlier column)? Software needs to be updated. I can't get my PDA to talk to my laptop over the Bluetooth link? Software profiles are to blame.

Pity the poor code developer. It's always his fault. Those hardware designers always seem to get off easy.

Unfortunately, I've run up against yet another problem where the software took the blame. If you're a user of XM Satellite Radio, like I am, you may have received this same e-mail from the company, which states (slightly paraphrased):

"As many of you know, XM customers have experienced service outages or significantly degraded service. We quickly identified the problem and are working hard to return to our normal levels of service. The problem occurred during the loading of software to a critical component of our satellite broadcast system, which resulted in a loss of signal from one of our satellites."

Is my perception of the software usually being the culprit based on fact, or is it simply the quick and easy response? Keep in mind that I come from a hardware background. Generally, whenever we found an issue in the board design (Note the term "issue." We never had hardware "problems."), we simply threw it over the wall and had the software guys write a work-around. That's a free fix, right?

To get a perspective from someone who makes a living on the "other" side of the wall, I contacted our respected columnist Dan Saks. I asked Dan whether my perception of the software always being at fault was accurate. Much to my surprise (and delight), Dan agreed with my assessment.

In Dan's view, the software has become so complex, that it usually is an issue with the software that causes a problem. Generally, by the time you get your product out in the field, the hardware has been tested, tested, and tested again. You certainly don't want to do a hardware fix after you've released the product to manufacture.

But a software fix (or update) is something that can take place almost any time. That phenomenon is even easier thanks to the increased use of flash memory. If the system is built properly, like most handsets for example, the vendor can ship the product with software that's "almost 100%." Then they simply send down a fix over the network.

In my eyes, it sounds like cheating. What's your opinion?

Richard Nass is editor in chief of Embedded Systems Design magazine. He can be reached at rnass@cmp.com.

Reader Response

Just once, I'd like to see hardware guys develop a medium complexity 21st century project without the firmware part.

Use transistors, relays, gears, I don't care. Just make something like a cell phone but no microprocessor.

It will be big and expensive guaranteed. That's not the purpose of the test.

I just want to see the number of bugs in a hardware-only solution.

-John Davies
President
Montrose Hill Systems, Inc.
Pittsburgh, PA

I don't think it's the software developers' fault as much as management's. There is pressure early-on to get hardware the software guys can use. Then as soon as the hardware is ready, Management and Sales are forcing (unrealistic, usually) ship dates. The "The Budget" requires that it ship on a particular date, they cut corners on the to-be-completed items, which usually is "software/integration testing."

It's extremely frustrating and is a major reason for me to be looking elsewhere.

-Andy Kunz
Sr. Firmware Engr
Transistor Devices, Inc.
Hackettstown, NJ

Richard,

I agree with you both. Because of hardware lead times. Because of Flash memory. Because of changing hardware in the field. Because of software complexity. From a biz sense, have software "fix" the problem. In designing a system, you need to not only design for the requirements but also changes that could and will occur. When an issue is found, you need to quickly find the problem, come up with a solution and get it to your customers. All this is dependant on how well you designed your system (hardware & software) in the first place

-Mark Meyer
Real-time Embedded Software Engineer
Differential Designs Inc.
Commerce, MI

Yes, always the software engineer had to face the problems definitely because the software guy brain is working as fast as restless as the clock cycles of the hardware.

-Vijaykumar Thota
Software Engineer
Siemens
Babenhausen, Germany

It's always easy to look at the things that can be worked out without lot of pain.

Whenever it comes to software there is always scope to look at workaround for those things that are improper in hardware. Let's take the example of fixed point processor every one like to see the performance comparable to floating point precision by developing algorithms or by any means.

Precisely, software can change the way things are happening and whenever these ways are not 100% everything's come back to guys who are responsible. So, off course software .....:)

-Suresh Kurmi
software engineer
STMicroelectronics
Noida, India

The conversation continues . . .