I previously worked in a company where the main product was an IP camera. Most of the team was building a windows client to interface with the camera and I was

I previously worked in a company where the main product was an IP camera. Most of the team was building a windows client to interface with the camera and I was a one man army to handle the software onboard. I'd say that most software people don't know what is hard with hardware (no pun intended, seriously). Most of your time is spent around finding libraries that can be compiled for your board or fixing device drivers because of that slight board modification the hardware guys did. You also have to figure out how the proprietary hardware encoders work and make them work properly. If the documentation doesn't fit the implementation? Well you have this contact under nda agreement that will eventually say "I don't know either, have you asked in the forums?" after 2 weeks of back and forth. Also sometimes your device would just reboot and you'll spend time arguing with the hardware guys that linux don't just reboot for no reason. Did I mention having to worry about how your 64mb of ram get allocated and in which DSP pool? Eventually, you'll find time to write code that will cause your device to do something meaningful. Writing software for hardware is much harder than it seems, because you have to worry about all those things you take for granted when working with a x86 desktop. You can't upgrade often after shipping, so testing focuses on critical bugs instead of usability. I do agree than spending more resources would make sense, but consider this : Hiring a DSP specialist to get an H264 encoder to work would cost 80k$ in Montreal in 2007. This is something that is now free with newer chips, but just getting the hardware to work used to drain a lot of resources. Larger companies could have more money for that, but I do not know how they work internally so I can't speak for them.