Why Can't You Just Add Logic to Your Program to Compensate For My Device's Problem?

Periodically, the developers of astronomy software (planetariums, imaging software, automation software, etc.) are asked to add logic to their software to "correct for" a problem in some device like a telescope mount. This usually creates tension between the program's user and its developer because the developer will almost always refuse to do it. Why?

Consider what the program's developer faces: He's responsible for controlling many different devices, and he's depending on the ASCOM driver-client architecture to avoid having to program special code for each device. If he routinely adds special code to compensate for problems, his program will become littered with code for various device problems, making it less reliable and far more difficult to maintain (and breaking the driver-client model).

Now, what happens when some change to a device or its driver corrects the problem? Now the application contains code that (at best) is useless and possibly creates a new error. Multiply this by a dozen or more different devices of a given type and you can see that the software developer will need to make frequent releases just to manage the hacks he has for device problems.

Furthermore, how do you correct for a given problem? And can you correct for it? The application developer has no knowledge of the internals of the device or its driver. In order to test his hack, he needs to have one of the devices in his lab. How many different types of devices do you expect an application developer to buy and keep around just for hack testing? And what about devices that are out of production? Oh, and what about devices that have multiple firmware versions? Must the developer test with a bunch of different firmware releases, and maybe alter the hack for each one? Can he detect the firmware version in use?

Finally, consider that every astronomy software program that uses a problematic device will have to contain its own hack to correct for the problem(s). Imagine five planetariums, three automation systems, a couple of guiding programs, all needing to contain hacks for some problem in a particular telescope mount. WIll each of those developers "correct" the problem the same way? WIll all of their "solutions" work reliably? Now what happens when one program's hack works better than another's? The users will beat up on the developer whose hack isn't as reliable, and the hapless developer has no control over the problem at all. He's fired a "shot in the dark" to try to correct it and failed to hit the bulls eye. How much does that divert the developer's attention away from his program's primary purpose?

Again, multiply this by a number of devices of a given type (e.g., mounts) and by a number of programs that use each type of device, and you can quickly appreciate the impossibility of the situation for astronomy application developers. Imagine every program that can print, each containing hacks for hundreds of printers that "have problems".

How it Must Work

In order to deliver reliable (and maintainable) astronomy software, an application developer must be able to depend on a contract between him and the device/driver makers. It's very simple but very powerful:

Do it correctly or signal an error

This simple rule has subtleties that ordinary users shouldn't have to understand. Unless you're a developer, all you need to know is that the device and its driver must honor the above basic principle. If not, your only reasonable recourse is with the device maker or the driver developer (and if you're lucky, they will be the same entity!).