If you've been in electronics for any time at all, it is easy to see a pattern develop between hardware and firmware/software engineers. As soon as a problem crops up, it is instantly clear to the hardware team that it is the code that needs fixing. However when asking the software engineers, they confidently state that the hardware is at fault. When pressed for details, both sides will end up saying something like, “Well, I don't know what is wrong, but I know it can't be related to my part of the design because of _______.”
How is it that these assumptions are being made time and time again about the source of the problem coming from the other side? Much of it probably stems from human nature's inclination to toss any problem over the wall and hope someone else fixes it. This is likely strengthened by an engineer's confidence in a design they have spent untold hours creating. But another source is likely rooted in a lack of understanding how the other side of hardware/software works.
How can we prevent this unproductive riff raff? It might help to have anyone involved in electronics (either the hardware or software side) take at least one course in microcontroller design to show the connections (and problems) that occur between hardware and software. Any piece of circuitry will eventually need to be controlled or communicate with software, and software usually involves the real world at some point. The most remarkable A/D circuit is useless if the communication bus that the digital signal must pass over does not have the required bandwidth. Similarly, a beautiful chunk of code written to control an RGB LED matrix won't work if the hardware isn't designed to supply the required amount of power. A course that forces the engineer to face problems on both sides can be humbling; for example a hardware engineer might spend hours troubleshooting his or her code only to find that the motor was connected to the wrong power rail.
An example of such a course, ECE4760, taught by Prof. Batten at Cornell University is now available on YouTube and offers a wealth of information that would greatly help anyone designing in the Electrical Engineering space. It could be replicated at home thanks to the $10 MSP430 Launchpad and the free development tools. And while an outside observer won't be able to benefit from in-person instruction, they will be able to easily engage the communities like Element14's MSP430 group or TI's E2E forum. The best part is that the course is project based, giving students an opportunity to learn the difference between 'This should work' and 'This does work.'
Of course this is just one suggestion to give each side a glimpse of the other. After 5 years in the field any lessons of humility will be mostly forgotten. Have you noticed the “it's their problem” exchange before? What do you think would help with it? Please share your thoughts in the comments. In the end, we're all on the same team!