When should I decline to make a requested change?
- by reuscam
I work on the software side of a company that provides custom hardware with software running on top of it. Often times the hardware is not engineered well. In those cases, I am often asked first to troubleshoot the problem - of course the symptom is always "your software crashed" or something along those lines.
Just recently we had another one of these incidents where power on a USB line is not reliable, and it causes a USB device to fail. This causes a usability problem in one of our applications. I have been asked by upper management to handle this better - continually monitor the USB device, and if it disappears, then reboot, or try to reset it. Doing either of these is not guaranteed to fix anything.
Ultimately, the real fix is to correct the reliability of the device from the hardware side. I could improve performance, but not to 100%, and of course I would be using my already limited time to bloat code and add yet another device monitoring thread.
So with all that said, how do I make a good decision about when to say that this needs to be a hardware fix, and only a hardware fix? Can I approach this quantitatively, and come up with some sort of definitive yes/no test? I'm sure its not that easy.
