Policy for Working Around Device Errors, Quirks, and Limitations

[Bob Denny]

Occasionally I get asked why ACP doesn't try to gracefully recover from, or in some way work around, device problems that result in errors being sent to ACP, freezes, timeouts, or failures to complete requested operations with no errors. The fundamental rule for layered systems is "Do it right or raise an error." It has to be this way. Every week some new device comes out, new firmware for existing devices, new uses for those devices which produce new patterns and timing of commands. If I were to go on a mission of working around all of the problems that can arise in all of the various pieces of astronomical equipment that may be used with ACP, I would simply turn DC-3 Dreams into a "software victory over hardware" company. That would consume me beyond my capacity and doom me to failure because most of the problems cannot be worked around anyway!

Even more importantly, if I take responsibility for compensating for a problem in someone else's device, I become responsible for the operation of the device. How can I do my job? The device is someone else's product about which I know nothing and over which I have no control. Furthermore, it opens the door to people continuing to deliver devices with problems by removing an important market force. This is a big problem in Astronomy, though it is improving rapidly these days. The days of garage shop tinkerers are pretty much ending now, thank goodness.

My success over 20 years is largely due to my pushing device problems back at the companies to whom my customers paid for the device. I am quite willing to do the diagnosis work to determine whether a problem is mine (ACP logic) or a device issue, then if the latter, supply the evidence to the device maker. If the problem is mine, I'll fix it.