I have no evidence, but it seems like as a community people significantly underestimate the challenges of hardware development.
I'm not sure whether it's because the community thinks "Oh, hardware is so much easier than software! This will be a snap!" or if it is the more subtle "We haven't done this before, so we aren't aware of the pitfalls"
> Oh, hardware is so much easier than software! This will be a snap!
I've literally never heard anything say or think that. Myself included, nearly every software developer I know is intimidated by how hard hardware seems.
Whew! it's not just me then! I've been picking at a bluetooth/arduino 9 degree of freedom accelerometer for about 6 months now. It's terribly difficult to deal with. All the wires, the voltages, the heat and power, the damn bluetooth, letting all the magic smoke out, etc. All the physical details that aren't 'documented' like with a language or other programming project, mostly because...physics ...isn't well documented. I love, it don't get em wrong, but yes, hardware/software interfacing is like pulling teeth. I think the main issue is that you don't even know what to ask Google, let alone anyone else. It's hard just to formulate the right questions, let alone get answers.
Maybe it's just because we approach it from different sides of the fence, but I always found accelerometers very easy to use in hardware but impossible to use in software!
I'm not good enough at DSP to isolate the signal from the noise.
Bingo! I2C is just 4 wires, but getting that data out is the trick. You have hiccups in the transmission, some bit flips, and then the actual data to contend with.
Signal to noise is actually pretty easy, just have a Fourier transform to pick out the differences between a background you set before. Typical applications are pretty immune and the ratios are very high usually.
See, I have no trouble reliably getting the data out of the sensor and into a variable. But I can't implement the fft() in C for the life of me, and even if I could, my little itty-bitty microcontrollers probably don't have that level of number crunching.
Ahhh! Yes, I do all the post processing off the chip. You could play with a ...oh geeze, its Friday, what are they called...? The things that configure themselves to be a circuit and can only be configured once. Jeeze, sorry on the name here. JFET maybe? I'm sorry. Try arduino as a good intro. I think they have some fft libraries.
I used to hear it frequently when I rubbed elbows with more software guys. Maybe not in exactly those words, but you can tell, when a software guy budgets 1 month to design the hardware and 11 months to "do the majority of the work" (aka write the software)
E.g. at one company the engineering VP was a quintessential hardware guy. He understood hardware complexity; he knew little about software. He never could understand that software could also be hard to do.
I didn't mind, I was a hardware guy. But the software people were definitely sucking hind tit.
I'm not sure how people could think this. Hardware is a much less forgiving medium than software:
- If your web application requires three times the resources you thought it would, you can easily add more servers. But a device that needs to fit in a USB key has hard limitations on size, memory, power dissipation, etc. You can't ask people to carry around a briefcase-sized device (or even another phone-sized device) to hold their passwords.
- If your web application has a horrible bug, you can wake up your developers and have them fix it at 3:00 AM. If you find a bug in your embedded software after you ship, it can only be fixed by getting all your users to upgrade their software (assuming your embedded software is in flash memory, not in ROM). If you find a bug in your hardware after you ship, you need to send everyone a new device.
Planning fallacy is planning fallacy. Perhaps it's more exaggerated in hardware, but doesn't negate the fact that it will always exist and planning is hard.
I'm not sure whether it's because the community thinks "Oh, hardware is so much easier than software! This will be a snap!" or if it is the more subtle "We haven't done this before, so we aren't aware of the pitfalls"