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.

  • Hardware is always faulty. Your software must be faultresistant.
    – user1249
    Commented Mar 11, 2011 at 14:40
  • Good luck with that. How do you resist bsod's?
    – reuscam
    Commented Mar 11, 2011 at 14:53
  • BSOD's indicate driver issues. Is this not the driver you are working on?
    – user1249
    Commented Mar 11, 2011 at 15:12
  • No, drivers are the responsibility of the "hardware" group. They provide the hardware, and the drivers and dll's to interface it. I write the application to sit on top of it.
    – reuscam
    Commented Mar 11, 2011 at 16:13
  • in that case you have my sympathy and I agree that this should be fixed elsewhere. If your boss disagrees, there are greener pastures.
    – user1249
    Commented Mar 11, 2011 at 18:31

3 Answers 3


I would look at it this way. Which adds more value to the company from the view of management. They probably don't care if the code is bloated or if it's not 100% perfect they want to do the least amount of work to make money. Fixing hardware is usually way more expensive then changing code. If you can by making your change make it good enough to sell with out massive amounts of cost in support then they will want the change on your side. If you change is not going to make it good enough to make money, you should bring this up and say we need to fix the hardware.

  • 3
    I agree. In the long run, though, if your company is not committed to producing a high-quality product, and that is important to you, you should think about moving to a company where quality is taken seriously. There are many. Commented Mar 11, 2011 at 15:20
  • Companies don't care about the "support" cost when evaluating if a hack should be implemented. The cost is only theoretical and in the future so they ignore it. Commented Mar 11, 2011 at 15:42
  • I actually make changes all the time that bring down the cost of support. However I don't now work for a software company I write software for a company which is different.
    – Erin
    Commented Mar 11, 2011 at 16:11

To use an automobile manufacturer analogy: Volvo, Mercedes, BMW and Lexus would probably fix the hardware. Other's may say, patch it now and fix the hardware before the next batch/model. The rest will just fix the software because it is good enough by their low standards.

This is why a company needs to establish an identity so everyone can make decisions inline with that goal. "We will have the best engineered product in our industry." versus "Just make it work."

Base you recommendation in the context of what the company is trying to be.


Your job as a developer is to supply solutions, and provide technical knowledge. If multiple possible solutions are possible, assess the costs, benefits and risks of each, and present your assessments to the product owner. To decide which solution to implement is the product owner's job. You have some room to play in how you present the facts and estimations, but don't try to bend the rules too far.

Of course we all would like to implement "perfect" solutions - from our point of view. Learning to take into account the business' and users' point of view is an important skill for programmers, which helps us deliver better solutions to our customers.

Sometimes (in fact usually) the product owner is aware of factors we aren't. As others noted, a hardware solution may be way more costly than a software patch. Or it may be totally out of question due to some (political or technical) issue with the hardware manufacturer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.